   Generalizing Verlet Integerator??
  I have my physics engine running using Euler's integerator, works pretty fine for the rigid body stuff. But then I tried Verlet's integeration for the cloth simulation I have. And I was really impressed by the stability and direct sync between acceleration and position. So I thought maybe it's a good idea to use Verlet's integeration for rigid bodies as well, but I had some points:1) In Verlet, the velocity is just the change in position in the last frame, I mean it's not a *real* velocity (v = deltaX), so would this affect the force generators that require velocity in their calculation (like air drag..)?? Or should I calculate the velocity each frame using Verlet Velocity algo?2) The idea of storing two position vectors for each particle (or body), would it waste memory? And if it will, is it worth it??I was thinking to switch to Verlet because I believe it would help in the contacts resolving process, maybe removing vibrations due to the mirco-collisionsI just am not sure if it's a good idea, so let me know you're thoughts...Thanks,Atef Hashem   
Quote:Original post by AHashem1) In Verlet, the velocity is just the change in position in the last frame, I mean it's not a *real* velocity (v = deltaX), so would this affect the force generators that require velocity in their calculation (like air drag..)?? Or should I calculate the velocity each frame using Verlet Velocity algo?The difference between the last and the current position _is_ the "real" velocity.Quote:Original post by AHashem2) The idea of storing two position vectors for each particle (or body), would it waste memory? And if it will, is it worth it??Well, you store that last and the current position, but don't have to store the (linear) velocity. Since storing the velocity takes as much space as storing the last position, you are not wasting any more memory than previously.;  Thanks for your reply, it really clarified things :)So do you think it would be better to switch to Verlet for rigid bodies and particles as well (I use Verlet for constraint systems already)??Also, I think Verlet could be used for angular quantities as well, is that right?   ;Quote:Original post by AHashemSo do you think it would be better to switch to Verlet for rigid bodies and particles as well (I use Verlet for constraint systems already)??I'd definitely go for it for particles, because it's stable and fast. For rigid bodies it really depends on what you want to achieve. Verlet integration might be to crude...Quote:Original post by AHashemAlso, I think Verlet could be used for angular quantities as well, is that right?I don't think there's a good way to extract angular velocity from two orientations. Think of a body that spins 181 degrees in one simulation step. Did it spin 181 degrees in the one direction of 179 in the other one?However, you can do the following to simulate rotating bodies: Use two (or more) bodies and connect them with a hard constraint. This way it will start spinning when appropriate, and you never have to even thing about angular velocity.Works well, but might not be what you're aiming for, I don't know.I hope that helps!   ;  I think there would be some issues with collision response, at least with a simple implementation.Say your object collides perpendicularly with a wall, bouncing off and ending the frame more or less where it started. What's the velocity now, since position and last position are nearly the same?Just a thought...;Quote:Original post by RattenhirnHowever, you can do the following to simulate rotating bodies: Use two (or more) bodies and connect them with a hard constraint. This way it will start spinning when appropriate, and you never have to even thing about angular velocity.Currently the engine supports this aggregation method, but I was thinking if the body is somehow complex, how would I calculate the final transformation matrix/Quat. that would apply to the geometrical model?? Meaning, if I have a cube constructed of eight masses at its eight vertices, I would construct the three local axes by subtracting the right from the center and the up from center, do some crossing of vectors....etc, but what if the masses doesn't form a regular shape (like in a ragdoll or any other complex shape)??Original post by wingman_jSay your object collides perpendicularly with a wall, bouncing off and ending the frame more or less where it started. What's the velocity now, since position and last position are nearly the same?[/qoute]I think since the change in position after resolving the contacts is nearly the same, then there should not be any velocity generated.Thanks for your help!Atef;Quote:Original post by wingman_jI think there would be some issues with collision response, at least with a simple implementation.Say your object collides perpendicularly with a wall, bouncing off and ending the frame more or less where it started. What's the velocity now, since position and last position are nearly the same?Just a thought...That depends on how you implement collision response. If you use pure projection (for the most stable results), it'll just slide down the wall.However, you want to implement bounciness, you can either manipulate the last position as well or appy a force.;Quote:Original post by AHashem1) In Verlet, the velocity is just the change in position in the last frame, I mean it's not a *real* velocity (v = deltaX), so would this affect the force generators that require velocity in their calculation (like air drag..)?? Or should I calculate the velocity each frame using Verlet Velocity algo?Yes, it'll affect the accuracy and can lead to instabilities if those drag terms are really large.  But Euler integration of velocity isn't all that much better anyway.If you can stomach some implicit terms, you might want to google for Beeman's algorithm.  There's also an explicit method that substitutes the implicit acceleration term with the current acceleration, but I can't speak to its strengths/weaknesses.Another (incorrect, but simple) way is to simply scale your velocity term every cycle.  ie: velocity *= 0.95;Quote:2) The idea of storing two position vectors for each particle (or body), would it waste memory? And if it will, is it worth it??Generally speaking it's such a teeny tiny component of the overall memory footprint for any rigid body or particle it just doesn't matter.  If you store two positions, velocities, and accelerations (old and current timestep), you can set up your engine to easily switch between integration schemes and see which ones work best.In the few cases where it does matter (particle systems on the GPU), you'll know it.Quote:I was thinking to switch to Verlet because I believe it would help in the contacts resolving process, maybe removing vibrations due to the mirco-collisionsIf you've read that ubiquitous paper on using verlet to resolve collisions, DON'T do it that way.  It's temptingly simple to implement, but it doesn't take in to account what "proper" collision response is.  It's very easy for collisions to introduce energy into the system (meaning that things explode).  It's also extremely sensitive to your timestep size, and when the collision actually happens during the timestep (that is, it's extremely sensitive to penetration depth).Instead, read Chris Hecker's old physics articles.  Specifically the bit about collision response.   ;  Thanks Numsgil to your great reply!If've read long ago Chris Hecker's articles, they were VERY helpful, actually they were the base of the engine at that time, but then I read more and developed many other things (friction at the contact...).My main concern was rigid bodies at that time, but then when I implemented cloth using Verlet, I was impressed by the stability (especially that I tried it first with Euler and RK4, and it successfully exploded :)) so I was thinking to use Verlet in the entire engine. Guess I'll stick to the old good ways ;)Thanks very muchAtef   ;Quote:Original post by AHashem... but I was thinking if the body is somehow complex, how would I calculate the final transformation matrix/Quat. that would apply to the geometrical model?? Meaning, if I have a cube constructed of eight masses at its eight vertices, I would construct the three local axes by subtracting the right from the center and the up from center, do some crossing of vectors....etc, but what if the masses doesn't form a regular shape (like in a ragdoll or any other complex shape)??You can choose any arbitrary point as your coordinate system origin. In the example of the cube, you could choose any of the 8 corners as the origin (with its axes in any orienation). You'd then specify the other 7 corners relative to this coordinate system, so the origin corner would be located at (0,0,0).Like wise for your graphics. This coordinate system would be the graphical transform, and the vertices specified relative to it. So there'd be a vertex with a local position of (0,0,0).