VPP and multithreading

Question

We are currently supporting ~30 cars and hopefully even more. In the profiler VPP physics simulation is highly perfomant and creates zero memory garbage, so that is really nice.

For me it seems that making the physics simulation async or job based would further improve performance substantially in these use cases when there are many simulated cars in the scene. Do you have any plans in this direction?

Answer 1

Thank you for the information! However there are no plans on this at the moment.

While I may consider porting some of the actual VPP code to jobs, these would still need to be created and scheduled from inside a FixedUpdate call, and must be completed before leaving that same FixedUpdate call. I don't really know the job system so much in order to decide whether that would result in significant advantages, especially in the cases of a single car or a few cars, compared to the current approach.

Ideally, an asynchronous physics would provide some async callbacks I could handle per rigidbody. This way I could use them to process each vehicle as soon as their rigidbody simulation is completed for each physics step, while physics could keep working in the other rigidbodies at the same time. As far as I know PhysX in Unity works in single threaded mode and there are no plans in Unity on exposing any multithreading features of PhysX.

Using ECS/DOTS and Unity Physics or Havok is entirely out of the picture. This technology is effectively a different game engine involving a paradigm shift that would require to re-design and re-implement VPP almost entirely from the ground up, forcing to develop and maintain two separate VPP versions that would be incompatible among them. Not to mention that ECS and Unity Physics are optional packages not part of the Unity core and still in "Preview" state.