Is Hydra suitable for game/interactive runtimes?

Community Hydra
1

Is Hydra a suitable interface for a game engine renderer?

The typical flow for an interactive application or game would be

loadUSDSceneOntoGPU()
loop:
   inputs = receiveUserInputs()
   world = simulateGameWorld(inputs)
   UpdateDataOnGPU(world)
   Render()

As far as I understand, If I use Hydra, I would have to update the in-memory OpenUSD scene representation every frame so that a Hydra based renderer can consume it.

Is OpenUSD/Hydra designed/optimised for this use case or would it be extremely inefficient in a realtime interactive use case and therefor the wrong tool for the job?

If I dont use the Hydra interface, what is an effective way to extract rendering data such as vertex, indices, materials etc from a USD scene for GPU rendering? Traversing the scene and extracting data seems like a lot of work and my traversal/extraction code would have to understand the USD format. I would be writing a USD parser which is something I was hoping I could avoid.

1 Like
2

After looking through the forum, this may be an unnecessary thread. A bunch of people have asked a similar question.

Usually when I have use this forum system, it searches for similar threads based off the title. Might be worth enabling that?

3

it may not be what you are trying to do, but I’ve been experimenting with the idea of having the whole game-manager/engine described as SceneIndex plugins, so only affecting Hydra prims.

I don’t know how far this can be pushed, I’ve added a simple rigid-body sim and I’m having trouble with lights at the moment (see another thread here).

I wanted to leave USD untouched, as mush as possible, and only driving attributes for tagging primitives, like, the door animates only if it has a “primvars:behaviour:door” which makes it rotate of N degrees based on camera(player) distance.
Basically driving everything via “behaviours” attributes, that the engine can read and decide what to do with the prims tagged.

The input for now is only driving the camera with the joypad in my custom viewer on the left here, the other one on the right is usdview.

describing all in a SceneIndex plugins makes this running without the host needing to drive USD some how…

it’s just a toy, to see how far it can go in Hydra2.0

1 Like
4

That looks pretty cool.

I wanted to leave USD untouched, as mush as possible, and only driving attributes for tagging primitives, like, the door animates only if it has a “primvars:behaviour:door” which makes it rotate of N degrees based on camera(player) distance.
Basically driving everything via “behaviours” attributes, that the engine can read and decide what to do with the prims tagged.

I was hoping to integrate somehow with a data-driven ECS based game engine. Being able tag an entity as a door and then running game logic on all doors is something I would want to do.

Does your renderer implement the hydra interface or are you pulling vertex, index, material etc data from the scene index and handling it manually?

5

those are standard Hydra render delegates, in the left is my custom delegate, on the right is Pixar’s Storm, but it works on any delegate thanks to just being a Hydra Filtering SceneIndex plugin.

Basically, the plugin reads everything that goes through, from USD stage to Hydra, and based on tags, it performs modifications on the hydra-prims, before sending them over to whatever delegate is currently active.

This is a plugin example for a FilteringSceneIndex plugin, and the engine I’m working on is basically started from this.

1 Like