Hi all
My physics engine used PGS to solve the LCP and use error reduction parameter ,it can run correctly when exist few boxs in physics world ,but when i build a box stack then begin to honrizontal moved and quake.
the box stack that collapseed only in 2 second.
My question is how to correct this error?which correct error tips is used by commerical physics engine?
About correct error and stack stable
-
Dirk Gregorius
- Posts: 861
- Joined: Sun Jul 03, 2005 4:06 pm
- Location: Kirkland, WA
This is a very difficult to say from the information you are providing.
- How many contact points do you generate?
- Do you use SAT or GJK with some kind of manifold like Erwin?
- How do you choose the tangential direction at the contact point / manifold center?
- How many friction constraints do you define per point - two?
- Do you solve for the friction at every contact point or at the center of the manifold like suggested by A. Moravanzky in GPG 4 or Erin Catto at the GDC?
- What is the gravity?
- What is the timestep? Is it constant or fluctuating?
- How many iterations?
Do you have any validation code that measures the constraint error ( that is the relative velocity in direction of the tangents) after running the PGS solver and applying the correcting impulses / forces?
As Erin said in another thread here. You really should make sure that two boxes (1x1x1) with 1kg mass are stable at a gravity of 10 with a constant timestep of 60 Hz at about 10 iterations. This should be stable even without warmstarting from my experience. If this doesn't work it is very likely that you are doing something wrong in either your constraint setup or solving. The best way to validate your solver later is a simple stack of about 5 boxes like e.g. the two stack demos in Erin Cattos 2D engine from the GDC this year...
-Dirk
- How many contact points do you generate?
- Do you use SAT or GJK with some kind of manifold like Erwin?
- How do you choose the tangential direction at the contact point / manifold center?
- How many friction constraints do you define per point - two?
- Do you solve for the friction at every contact point or at the center of the manifold like suggested by A. Moravanzky in GPG 4 or Erin Catto at the GDC?
- What is the gravity?
- What is the timestep? Is it constant or fluctuating?
- How many iterations?
Do you have any validation code that measures the constraint error ( that is the relative velocity in direction of the tangents) after running the PGS solver and applying the correcting impulses / forces?
As Erin said in another thread here. You really should make sure that two boxes (1x1x1) with 1kg mass are stable at a gravity of 10 with a constant timestep of 60 Hz at about 10 iterations. This should be stable even without warmstarting from my experience. If this doesn't work it is very likely that you are doing something wrong in either your constraint setup or solving. The best way to validate your solver later is a simple stack of about 5 boxes like e.g. the two stack demos in Erin Cattos 2D engine from the GDC this year...
-Dirk
Thank you for you reply !
every vertex of box.DonDickieD wrote:- How many contact points do you generate?
Yes.DonDickieD wrote:- Do you use SAT or GJK with some kind of manifold like Erwin?
Contact point.DonDickieD wrote:- How do you choose the tangential direction at the contact point / manifold center?
Yes ,per point have two direction friction constranits.DonDickieD wrote:- How many friction constraints do you define per point - two?
Every contact.DonDickieD wrote:- Do you solve for the friction at every contact point or at the center of the manifold like suggested by A. Moravanzky in GPG 4 or Erin Catto at the GDC?
-9.8DonDickieD wrote:- What is the gravity?
Fluctuating.DonDickieD wrote:- What is the timestep? Is it constant or fluctuating?
8DonDickieD wrote:- How many iterations?
-
Dirk Gregorius
- Posts: 861
- Joined: Sun Jul 03, 2005 4:06 pm
- Location: Kirkland, WA
- How do you choose the tangential direction at the contact point / manifold center?
I meant if you choose an arbitrary direction or align the first tangential direction with the raltive tangential velocity. This might give you better results...
Try a fixed timestep of 60 hz at 10 iterations if you warmstart and tell me if this works. One thing I came across but actually never looked into more sorrowly is that is might be better to solve the friction constraints at the end of the loop. So you might want to try to order your constraints like this:
- Joints
- Contacts
- Friction
Let me know if you get different results with other ordering...
-Dirk
I meant if you choose an arbitrary direction or align the first tangential direction with the raltive tangential velocity. This might give you better results...
Try a fixed timestep of 60 hz at 10 iterations if you warmstart and tell me if this works. One thing I came across but actually never looked into more sorrowly is that is might be better to solve the friction constraints at the end of the loop. So you might want to try to order your constraints like this:
- Joints
- Contacts
- Friction
Let me know if you get different results with other ordering...
-Dirk
remiss of i not to read your post carefully,sorry for my mistake.DonDickieD wrote:-I meant if you choose an arbitrary direction or align the first tangential direction with the raltive tangential velocity. This might give you better results...
yes,i used raltive tangential velocity direction as my first tangent direction,these box slick and slide behaved well.but,after boxs had stopped for a few seconds these boxs begain to sliding ......
To my thinking,numerical error creeps leads to this undesired sliding.
I had try to use fixed time step and 100 iterations ,the boxs stack is more stable as before,but the begain sliding when after boxs stopped for a few seconds is also happened...
We had a similar drift problem. After implementing warm starting ( and contact point caching ) the problem went away.
So you need to keep track of contact points that are the same between frames, and store the constraint force applied at the previous frame. Start your solution vector with those values.
This worked perfectly when no penetration recovery was employed. I had to mess around a bit to get our non-standard penetration recovery to behave properly without upsetting the stack. So make sure your stack exhibits no horizontal drift when you disable penetration recovery( "baumgart" or "post-whatever-stabilization", I think are the terms in use ) first.
So you need to keep track of contact points that are the same between frames, and store the constraint force applied at the previous frame. Start your solution vector with those values.
This worked perfectly when no penetration recovery was employed. I had to mess around a bit to get our non-standard penetration recovery to behave properly without upsetting the stack. So make sure your stack exhibits no horizontal drift when you disable penetration recovery( "baumgart" or "post-whatever-stabilization", I think are the terms in use ) first.
-
Dirk Gregorius
- Posts: 861
- Joined: Sun Jul 03, 2005 4:06 pm
- Location: Kirkland, WA
We effectively teleport our bodies out of penetration. So we change the position without affecting the velocity. Is this non-standard? It wasn't super unstable, but my goal was a linear stack of 8 boxes remaining completely motionless for at least 5 min, that didn't happen with the penetration recovery.
I don't really know what post-stabilization or projection means in this context. Projection of what? Stabilization of who, when? Baumgart, wtf? No wonder physics is still one of the least commonly understood disciplines in game development. Someone needs to make a multi-context glossary available for real-time physics
Apologies for the ranting. 
I guess in defense, graphics has their fair share of confusing acronyms and old-world last names.
I don't really know what post-stabilization or projection means in this context. Projection of what? Stabilization of who, when? Baumgart, wtf? No wonder physics is still one of the least commonly understood disciplines in game development. Someone needs to make a multi-context glossary available for real-time physics
Apologies for the ranting. I guess in defense, graphics has their fair share of confusing acronyms and old-world last names.-
Dirk Gregorius
- Posts: 861
- Joined: Sun Jul 03, 2005 4:06 pm
- Location: Kirkland, WA
Ok, I try my best. In a rigid body simulation you normally have:
dx/dt = v
dv/dt = W * f
Constraints are expressed as algebraic implicit equations (e.g. x^2 - r^2 = 0)
C(x,q) = 0
This builds what is called an differential algebraic system (DAE). The algebraic equations (constraints) "create" forces such that the (position) constraints remain satisfied. E.g. for the a mass point on a circle the algebraic equation results in a force canceling out all "accelerations" not tangential to the circle.
You typically get:
dx/dt = v
dv/dt = W * (f_ext + f_c)
with f_c = JT*lambda
The direction of the force is know because of the gradients (Jacobian) of the constraint equation. In the example the gradient of the circle is normal to the tangent at each location on the circle. So you have to solve the following system:
dx/dt = v
dv/dt = W * (f_ext + JT*lambda)
C(x,q) = 0 where dC/dx = J
The classical approach to solve this DAE of index 2 is to build the second derivative of the constraint equation. Note that a geometric constraint also imposes a velocity and an acceleration constraint onto a system - sometimes refered to as hidden constraints. E.g. for a ball joint you require that the anchor always are on the point in space. It also requires that the relative velocity and acceleration at the anchor are equal. For my knowledge the known physic engines solve on the velocity level and you get the known velocity constraint with the "famous" Jacobian matrix:
dC/dt = dC/dx * dx/dt = J * v = 0
In this form when solving on the velocity level you will get quite some drift - that is the position constraints will not be satisfied which is for example a ball joint drifting apart at the anchor. In order to stabilze this you now put the position constraint equation into the velocity constraint and get
J * v = tau * C(x,q) / dt
This is what is know as Baumgarte stabilization. You find a good explanation of this in the 2005 GDC paper of Erin Catto. The term tau * C(x,q) / dt equals 'c' in ODE terminology.
In this form you add some extra velocity to the persistent momentum of the body which might result in overshoot. A solution to this is to solve two times - first for the velocity error and second for the drift. This is called projection. See ro example the master thesis of Bradley Cline for this...
HTH
-Dirk
dx/dt = v
dv/dt = W * f
Constraints are expressed as algebraic implicit equations (e.g. x^2 - r^2 = 0)
C(x,q) = 0
This builds what is called an differential algebraic system (DAE). The algebraic equations (constraints) "create" forces such that the (position) constraints remain satisfied. E.g. for the a mass point on a circle the algebraic equation results in a force canceling out all "accelerations" not tangential to the circle.
You typically get:
dx/dt = v
dv/dt = W * (f_ext + f_c)
with f_c = JT*lambda
The direction of the force is know because of the gradients (Jacobian) of the constraint equation. In the example the gradient of the circle is normal to the tangent at each location on the circle. So you have to solve the following system:
dx/dt = v
dv/dt = W * (f_ext + JT*lambda)
C(x,q) = 0 where dC/dx = J
The classical approach to solve this DAE of index 2 is to build the second derivative of the constraint equation. Note that a geometric constraint also imposes a velocity and an acceleration constraint onto a system - sometimes refered to as hidden constraints. E.g. for a ball joint you require that the anchor always are on the point in space. It also requires that the relative velocity and acceleration at the anchor are equal. For my knowledge the known physic engines solve on the velocity level and you get the known velocity constraint with the "famous" Jacobian matrix:
dC/dt = dC/dx * dx/dt = J * v = 0
In this form when solving on the velocity level you will get quite some drift - that is the position constraints will not be satisfied which is for example a ball joint drifting apart at the anchor. In order to stabilze this you now put the position constraint equation into the velocity constraint and get
J * v = tau * C(x,q) / dt
This is what is know as Baumgarte stabilization. You find a good explanation of this in the 2005 GDC paper of Erin Catto. The term tau * C(x,q) / dt equals 'c' in ODE terminology.
In this form you add some extra velocity to the persistent momentum of the body which might result in overshoot. A solution to this is to solve two times - first for the velocity error and second for the drift. This is called projection. See ro example the master thesis of Bradley Cline for this...
HTH
-Dirk
Dirk, thanks for the reply.
I took a quick read over the Cline thesis section on stabilization. So the term stabilization and Baumgart comes from DAE/ODE literature. That makes sense now. Thing is, most people doing real-time physics ( in games ) approach the problem from a geometric point of view. Which tends to result in better optimizations/easy-to-understand code. I find it _way_ easier to code up new constraint types using geometry rather than calculus. The principle of virtual work is very simple in a geometric interpretation, so it's not like you are violating anything either.
So we would be using a projection scheme. I think the problem with stability I am seeing is due to the fact that we are applying the drift correction a step late. We are recovering from penetration by modifying the position/rotation of a body ( rather than through velocity ). If we did the penetration recovery step before we solved for constraint forces, that would be an implicit step rather than an explicit one. i.e. solve for constraint forces at the projected position rather than the current one.
I took a quick read over the Cline thesis section on stabilization. So the term stabilization and Baumgart comes from DAE/ODE literature. That makes sense now. Thing is, most people doing real-time physics ( in games ) approach the problem from a geometric point of view. Which tends to result in better optimizations/easy-to-understand code. I find it _way_ easier to code up new constraint types using geometry rather than calculus. The principle of virtual work is very simple in a geometric interpretation, so it's not like you are violating anything either.
So we would be using a projection scheme. I think the problem with stability I am seeing is due to the fact that we are applying the drift correction a step late. We are recovering from penetration by modifying the position/rotation of a body ( rather than through velocity ). If we did the penetration recovery step before we solved for constraint forces, that would be an implicit step rather than an explicit one. i.e. solve for constraint forces at the projected position rather than the current one.