Position LCP questions

[smaker]

Hello, I've got some questions about position correction mathod called pseudovelocities or position LCP method.
In Erin Catto's blog there was a note about correction methods and there was quite short description about several methods to improve joint stability. I've implemented pseudovelocities method but instead of stability improvement I've recieved total failure: objects in stack of 25 boxes with displacement in XZ plane fails as if there is no friction at all.
Here is description of how I've implemented this algo:

1] form joint groups (or "islands" in other words);
2] calculate jacobians for joints, but without any position correction (as I tested it only on contact joints - constraint force was set to zero, instead of Baumgarte's penetration depth value);
3] call iterative PGS LCP solver for every joint group [15 iterations], use warmstarting from previous frame;
4] after solving, update cache for next frame;
5] integrate using result from velocity solver;
6] recalculate jacobians using new positions, velocities, etc. (in this case, I set constraint function back to Baumgarte-like penetration depth value);
7] call actually the same LCP solver, but with initial guess 0, and do not touch cache at all (neither recieve cache, nor update it), and only with 5 iterations;
8] integrate using result, bypassing velocities update, updating only position and orientation of bodies;

And as a result, I recieve worse stability. I even tried to set friction limits to infinite in jacobians in step 6 (where jacobians for position LCP is calculated). I must say that with 15 iterations, 25-boxes stack quickly become stable with Baumgarte position correction, and the main goal of implementing pseudovelocities is to split velocity/position solvers so I can make correct restisution coefficients (in case of Baumgarte restitution is influenced by penetration a lot). What am I doing wrong in this scheme?

Thanks in advance.

[Dirk Gregorius]

Strange. This sounds actually correct. You basically solve J*W*JT * lambda = -J*v for the velocties without any position correction. And then you solve J*W*JT * lambda = -beta * C where 0 < beta < 1 (ad even using new Jacobians).

Two guesses:
1) Don't mix post-projection with any kind of Baumgarte
2) Don't divide by the timestep for the position correction


Let me know if this helps. Otherwise maybe post some code (not too much!) of the actual position correction and I have a look if you like.


-Dirk

[fishboy82]

Hi Dirk : as you said

Don't mix post-projection with any kind of Baumgarte

,why couldn't do like this?

[Dirk Gregorius]

You can, but I have seen artifacts from this. Think about it. You add some velocity to correct a position difference and then you correct this difference. Most likely you will get some overshoot.

[smaker]

Dirk, did you mean to solve int this way (solving for velocities):
1) Solve J*W*J^T * lambda = -J * (V + dt * W * Fext), cache.
2) Integrate, update cache.
3) Solve for position correction J*W*J^T * lambda = dC / dt - J * (V + dt * W * Fext) with recalculated Jacobians, constraint function set to needed correction value and no cache?
4) Integrate only positions using lambdas, this should give an effect of Baumgarte post-stabilisation, but with no influence on momentum.

Or I need to consider only position factor, so that system in step 3 becomes J*W*J^T * lambda = dC / dt? Or even J*W*J^T * lambda = C if you say that i don't need to divide by the timestep? In this case I've got some misunderstanding, why shouldn't I divide.

P.S. If I understand correctly, W is for M^-1?

[Dirk Gregorius]

Just solve J*W*J^T * lambda = -C or maybe J*W*J^T * lambda = -tau * C where 0 < tau < 1. Whatever gives you best results. You need to experiment a bit.

You don't need to divide by dt since you are solving for the position now directly and not a velocity anymore. Note that lambda is basically a "displacement" now and no impulse anymore. This is where the pseudo comes from

Yeap, W = M^-1

-Dirk

[smaker]

Thanks! I'll try it as soon as possible.

[ngbinh]

Sorry if it's OT: I'm wondering if stable box stack is something nice to have?

For example, If I can have a way to simulate stack of hundreds boxes, is it something worth writing about?

[smaker]

Sorry if it's OT: I'm wondering if stable box stack is something nice to have?

Well, generally stack is like show for physics engines, if you have working sleeping system and more or less stable stacks, they're not a problem anymore (they'll fall asleep). And about article - if it is something really new and don't ruin general simulation case (like "shock propagation" - earlier it was not suitable in practice because of its influence on general simulation, lack of plausibility; don't know if now there is kinda fixes on it), you should write about it for sure.

[ngbinh]

Sorry if it's OT: I'm wondering if stable box stack is something nice to have?

Well, generally stack is like show for physics engines, if you have working sleeping system and more or less stable stacks, they're not a problem anymore (they'll fall asleep). And about article - if it is something really new and don't ruin general simulation case (like "shock propagation" - earlier it was not suitable in practice because of its influence on general simulation, lack of plausibility; don't know if now there is kinda fixes on it), you should write about it for sure.

No, they wont sleep. I'm hacking a bit of demo soon to show the idea. It has been there for ages, just no one cared.

[smaker]

No, they wont sleep. I'm hacking a bit of demo soon to show the idea. It has been there for ages, just no one cared.

Well, quite a fearless notion Make a demo, show it and let me know I'm really interested.

[ngbinh]

No, they wont sleep. I'm hacking a bit of demo soon to show the idea. It has been there for ages, just no one cared.

Well, quite a fearless notion Make a demo, show it and let me know I'm really interested.

See here: http://www.bulletphysics.com/Bullet/php ... f=4&t=4101