I’m using the new Hydra 2.0 and scene index pipeline for my renderer. But what about Physics primitive like PhysicsScene, UsdPhysicsRigidBodyAPI, and so on. What is the best strategy to handle physics. I think I have 2 solutions, but maybe I’m missing other solutions.
I can either create all the adapters and still use scene index and observer to create the bridge between USD and the underlying Physics system.
Or I can also use the TfNotice::Register on a stage to get all the physics primitive as well as API on prims.
What do you guys think ? Is there anyone here that use a physics system like Jolt, PhysX and a custom renderer ? I’m curious.
We implemented UsdPhysics before sending the stage to Hydra. We just run the simulation and bake the resulting animated transforms into the stage. This was necessary for our purposes because we don’t just want a render. The user needs to be able to modify the results of the simulation and doing simulation at render time is too late. Your situation may be different, of course.
@jerry.huxtable
So you basically traverse the stage to get all the physics information on prims, runs the simulation, and then render the stage ?
How do you notice if a physics prim is dirty between two frames ?
Spotting dirty prims is a problem and we’re basically just using brute force to see if the prims have time samples on relevant attributes or if mesh topology changes. Many things we care about are really cheap and we just update them unconditionally, but when it comes to having to build acceleration structures for collisions it’s really useful to know if something has changed. I don’t have a good solution for that though apart from just comparing attribute values.
If your transport system is listening for UsdNotice::ObjectsChanged notices, it will “hear” all the changes that your physics updater is doing between frames; so if it queues them up, it can process them before making the next render call to ydra. THat said, the authoring itself should be enough to get the next rendered frame to update, because Hydra/usdImaging is already listening for ObjectsChanged notices.
@spiff
Hi, thank you for taking your time to help me. I really appreciate it.
I think I can indeed make it works like this. But is there any plan to make something like the usdImaging library and the scene index ? Something close to a “simulation scene index” ? Hydra 2.0 is still tight to rendering, but it could also be great for physics / simulation or am I totally wrong?
We’d be really thrilled to see what people do in this space, @BaptistePerrin , but it’s not something useful to our work at this time. Similarly perhaps to @jerry.huxtable 's use-case, we need to review and potentially (substantially) polish/refine 100% of the simulation results we get, and therefore we incorporate the results into the scene-data itself.
I’ve been trying to push a SceneIndex plugin to its limit and made a GameEngine, and part of the work there was to integrate a physics engine (I’ve opted for https://www.reactphysics3d.com/ ).
If you are not interested in “recording” what’s happening in the scene, as a USD file, then a SceneIndex implementation is definitely possible (you could still record, but you have to serialize Hydra prims yourself for now): https://x.com/slider1978/status/1817674865245311037
In my GameEngine experimentation as a SceneIndex, I’ve added
The nice thing about making it as a SceneIndex plugin, is that it works in all DCC/hosts that have USD/Hydra supported, but some of those things have been “forced” in a SceneIndex, and frankly, not all should be in a SceneIndex plugin just because it can.
But it really depends on your requirements and expectations (and usecases).
I’ll probably make this project open source before Siggraph… I promised it to too many people now
