Are Euler's equations integrated for a PxRigidDynamic in PxScene::simulate(dt) ?

Based on my tests, I am thinking the answer is no. In other words, the angular velocity vector w only changes when an external torque is applied, either explicitly or during a collision. It would be great to get an independent verification of this. Or perhaps there is something I am missing?
Thanks,
-nuun

Under what circumstance are you testing the angular velocity and finding no change?

Thanks,
Mike

Mike, thanks for your reply.
I create an empty scene, with no gravity and no ground plane. I then create a PxRigidDynamic actor with a single shape, positioned at the world origin. I set angular damping to zero. The shape can be anything except a sphere, because I then give the actor an angular velocity vector that is not along a principle moment of inertia direction. I can do this either by calling PxRigidBody::setAngularVelocity(someRandomVector) or by first rotating the actor to some random orientation and then calling PxRigidBody::setAngularVelocity(PxVec3(0,1,0)), for example. I believe the input parameter to PxRigidBody::setAngularVelocity() is in gloabl coordinates.

I then advance the simulation and inspect the actor’s angular velocity and angular momentum. I use the PxRigidBody::getAngularVelocity() function, the PVD, and I also recalculate the angular velocity by looking at two consecutive PxActor::getGlobalPose() values. What I expect, if the rigid body dynamics are fully integrated, including Euler’s equations, is for the angular velocity in global coordinates to exhibit precession. This will lead to a realistic looking “tumbling” behavior of a non-uniform object. What I see though, is a constant angular velocity vector.

Is this design decision to not implement tumbling rotation? Or is it my misunderstanding of the API? Or perhaps there is a switch to enable this calculation?

Thanks,
-nuun

bump?

Hi,

Sorry for the delay, things were a little irregular over the holidays. Yes, we do cheat a bit in this respect, because the solver leans towards efficiency rather than accuracy, and it can be difficult and expensive to preserve angular momentum while limiting gains in kinetic energy due to numerical error. For the vast majority of game applications this limitation is never noticed. Could you tell me more about the application, what you are attempting to simulate that requires precession?

Thanks,
Mike

Mike,
Thanks much for your reply. I now understand better the reasons for the behavior I was seeing in my applications.
I have several simulations of the flow of gravel-like material, in a micro-gravity environment. As long as all the gravel stays close together, the many collisions dominate the motion of each actor and there is no time to notice inaccuracies in free spin. Only when the actors get more dispersed, and with the low gravity resulting in long, slow motions, the precise tumbling motion can be noticed to be missing. For the most part, I think my applications can accept this limitation. It would be nice to have the more physical behavior simulated, perhaps as a configurable option? If this were on the table for a future release I would add my vote in favor :)
Thanks,
-nuun