Physx 4 Aerodynamic simulation stability (diverging)

I’m developing a simulation software for flight simulation.
I have problems with solver stability.

I have a rigidbody subject to gravity and aerodynamic forces. My timestep is fixed to 0.01s and lift and drag forces are computed at timestep n using body linear and angular velocity. (I compute AoA and relative speed body/fluid in wing coordinate system) and apply to the actor with simply functions: AddForceAtLocalPosition for example.
after few timesteps (200/300) the simulation diverge and velocities goes to infinite. If I lower the timestep obviously the instability come up at a later moment.

I’ve tried to use function as:
ComputeVelocityDeltaFromImpulse and use velocity at timestep n+1 to compute forces in order to try an “implicit method” but this not improve the simulation stability.

I understood that Physx solver use semi implicit integrator method but i don’t if i can modify some parameters about the solver.

Any method to improve solver stability without reducing the timestep too much in this case? There a lot of simulator and i can’t figure out how they deal such stability problems for realtime simulations?

Thank you,

Hi Gianluca,

the “semi implicit integrator” in PhysX is only with regard to constraint forces (contacts, joints, friction, etc). External forces are only able to be integrated explicitly. Therefore if the external force field that you are integrating through is ‘stiff’, the issues you are seeing are expected. External force fields are integrated with simple explicit Euler steps.



Hello Adam, thank you very much for your answer. As you said my model is a “stiff” problem. You think I can change the integrator method and implement a different method?
What you think the best/easy way to improve the stability in physx?
For example an explicit Runge Kutta 4th order? Or implement an implicit method using function as PxRigidBodyExt::computeVelocityDeltaFromImpulse?

Thanyou very much

We can’t just add a better integrator without changing the PhysX API is because in the current API the user only provides a single force value at time = “now”. To e.g. implement RK-4 I would need to be able to ask the user to e.g. give me a callback function that I can use to sample the force field at arbitrary points in time. Also, with GPU based simulation being a focus, callback functions to CPU code are problematic. For the GPU use case a parameterized field that can be evaluated on the GPU would be more convenient. But its likely not going to cover your use case.

Finally, you are the first person since 2001 to ask for this feature (clearly realistic aerodynamics hasn’t been a topic for many people so far) so this combined with the other issues makes me disinclined to prioritize this on our side.

But, since PhysX 4 is open source on github, and since the code to update with external forces is very straight forward in the CPU code, my suggestion would be for you to experiment if you can do an e.g. RK-4 style update and see how much that helps.

Thank you Adam, i’wasn’t asking for a new integrator your side, obviously is a major feature to deal with, i was only asking it in order to understand really where is my problem and how i can improve it.
Your advices are really useful to me!

Only one last question: for me the solver was semi implicit because velocities are integrated directly from timestep n to n+1 but position are integrated backway using velocity at n+1

v(n+1) = v(n) + F(n)/inertia*deltaT
x(n+1) = x(n) + v(n+1)*deltaT

is it correct?

Yes, the main benefit in integration comes from setting up the constraint equations such that the constraints will be exactly satisfied at the end of the time step rather than at the beginning. So the solver knows what exact value the integrated position and velocity will have at the end of the time step and it makes sure that this value will exactly satisfy the constraint. This is the reason you can’t just change the integrator to something else without also changing the solver. Because the solver has to be able to anticipate the work of the integrator.

This is in contrast to naively satisfying the constraints “now” and then just taking an arbitrary integration step from here to a future where the constraint is no longer satisfied.