The main bottleneck in our current project is Physx preparation/baking tasks. Sometimes we absolutely need to recalculate a mesh collider or move a bunch of static colliders. Both those operations are expensive.
We have succesfully moved most of our heavy lifting code into separate processes, so our code runs very efficiently and is well scheduled.
How can we achieve the same with Physx tasks? Why can’t PhysX send off the mesh data to be calculated to a separate thread and then send it back when the calculation is done? We do it for a bunch of pretty advanced things and surely Unity/nVidia should be able to make that work as well?
Is there anything we can do to achieve this now, or is our only recourse to pester Unity to make this happen?
I doubt the physics engine could do any part of the simulation async. Recalculating a mesh and moving static colliders are not expensive because of the operations themselves, it’s expensive because the engine needs to figure out if any new collisions has happened, and because the engine has to recalculate a bunch of internal optimizations. Before all of that is done, the physics engine can’t return, and you can’t have the physics engine do anything else in the meantime as that would invalidate those calculations.
If you have leftover memory, it might be faster to swap objects instead of moving them. If you have some more detailed explanation of specific problems, there might be people in the community that has an idea about how to fix that.
Sorry, but I do not agree, and respectfully think you are wrong.
The collider mesh recalculation is expensive exactly because it is rebuilding the collision tree, which then allows the engine to quickly find any potential collisions in realtime. The recalculation step could perfectly well happen in a separate thread, having the old collision lookup structure intact until it can be replaced by the newly calculated one.
Moving static colliders is basically the same, but perhaps more tricky. In our case we are moving them a great distance and want to omit any collisions that may result. Unity however is (again) recalculating the collision lookup structure, and that could happen in a separate thread.
Thanks for the reply, but I get the feeling you are guessing rather than speaking from knowledge?
Also, as far as I can tell from the PhysX documentation (the nvidia one, not the Unity docs) PhysX is supporting multithreading. It would seem as if it is Unitys implementation that is not fully multithreaded.
That would mean this is a PhysX feature that’s just not implemented :(. Since the physics engine is under the hood, your only hope is the (hopefully useless) suggestion box.
I think it is a matter of how and where the bake functions in Physx are called. Looking at the profiler, the culprit is Mesh.Bake.PhysX CollisionData and it does seem to take up lots of time on the main thread. It may be that parts of that call is in fact sent off to another trhead, but the call should be more performant if so one would think.
I really, really wish Unity would speed the announced migration towards more available source code. I would love to be able to peek under the hood.
Anyway, I was hoping someone at Unity would see this and explain the inner workings. Fingers crossed.
I wonder if it’s possible to set a flag, so that it doesn’t do a check with everything, so you can pick when, and handle the response, assuming that’s possible.