Simulation position precision

Hey all,

We are doing some orbital simulations using Isaac Sim, and we have large errors, we realized that these errors were due to Isaac Sim truncating the position of the objects.
What’s happening is that an object close to zero is going to have a lot of decimal precision (5-6 numbers). Yet, when the object is far from zero, say in low earth orbit (about 6 771 000m), the simulation is truncating the position precision by 0.5 increments. This would be consistent with the physics in the simulation running on 32bits precision.

Yet for these orbital scenarios we would need more precision. Is there any way to switch to 64bits precision?

Thanks in advance, regards,

Antoine

Hi,
unfortunately the underlaying PhysX SDK is single precision only, so the simulation will for now always run with 32bits precision.
We do plan at some point to add support for large worlds through tiling and origin shifting. However no real plans are yet done.

Sorry about that, regards,
Ales

Thanks for the answer! So this method (shiftOrigin) is not exposed inside Isaac?
https://nvidia-omniverse.github.io/PhysX/physx/5.1.2/_build/physx/latest/class_px_scene.html?highlight=floating%20point%20precision#_CPPv4N7PxScene11shiftOriginERK6PxVec3

Another related question: Could I use another physics engine? (like bullet?)
I think I had seen something like that, but I can’t remember where.

Thanks again,

Antoine

Yes shift origin is not yet exposed, we are in the process of gathering requirements for how to solve large worlds with our single precision simulation.

I am not aware of another physics engine integrated into OV, there is certainly an interest in that, but I have not heard of any ongoing work yet.

Regards,
Ales

Alright, thanks a lot for your answers!

Have a nice day,

Antoine

Just out of curiosity, physX cannot be made float64 (or 128) compatible when running on CPU?
I understand that this is a proprietary engine, so you cannot give a proper answer to that, but adding origin shifting will likely not be sufficient for orbital scenarios.
For context, one of the main issues with orbital dynamics is also the speed of the objects.
Typical velocities are within the 7km/s range. This means that in a couple seconds we blow the float 32 precision range. So we would need to dynamically adjust the scene center every couple seconds. Which is possible, but not very convenient.
Another issue is that only the objects close to the shifted simulation origin will be simulated properly.
Or one would need to use an external solver for the objects outside the float32 precision range.

Its very unlikely that PhysX SDK will start to support float64, as you said this would be pretty much only possible for the CPU simulation. Which is also a problem because most of the new PhysX SDK features like deformables or SDF collisions are GPU only features.
Recently we added 64bit math types into PhysX SDK, but thats pretty much it. Note that almost all the lowlevel code is in SIMD so even those types and math would have to change.
The situation might change quickly if there is strong demand for double precision simulation, but it would not be something that we can easily achieve.
I understand that for your usecase this is a big problem on the other hand I think Kerbal Space Program used PhysX SDK and they somehow managed in the end.
Anyway we are aware of this and plan to have some solution for large worlds, however as said no concrete plans, though its surely something that we need to resolve.
Sorry that we are not really helpful now, we will try to improve in the future, but I cant promise you anything at this point.

Regards,
Ales

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.