I'm sure this has come up before but I'm a bit late to the USD party here

So what's the concences on doing animations that would normally be done in /obj level?

Think assembly type animations with a lot of moving parts, tweaking animation curves and keyfranes to get a nice flow.

Workflows so far:

A) Simpy using a scene import node. Works but this quickly bogs down since it will re-import everything each frame and triggering recooks downstream. Scrubbing the time line feels like it's 1999 again.

B) Importing a static scene and using transform nodes after that, preferably somewhere near the end of the USD network to minimize downstream updates. It's faster but a bit cumbersome and not all the animation features work (pressing 'K' does not set keys for example) It's also not as performant as the /obj context so it can be hard to judge animation flow properly.

C) Import static scene, do the animation in /obj and use a bit of python to reference those transform values into USD transform nodes that are automatically added into the stage for all /obj level nodes that have a keyframed transform. This allows for animating in the fast and comfortable /obj context yet having a relatively fast USD stage. Downside is that it requires some automated housekeeping and gets messy with complex hierarchies and such.

D) Caching things out. Fast playback but it quickly becomes a drag when doing lots of iterations etc.

E) Don't go into USD until all animation is completed. Sound like a plan but also when doing lookdev/lighting it's annoying when scrubbing is a bit slow.

Are there any other/better ways of getting max performance from USD in relatively simple scenes?

Option C) should not require any Python. It's what USD was built to do out-of-the-box. You can bring your static model into Solaris for lookdev, and then bring the animation in as a separate layer that you can just overlay on the static model.

Something like this (you'll see the animation layer comes in with no geometry - just transform info):
https://www.youtube.com/watch?v=cFqUBPFU07E [www.youtube.com]

eikonoklastes
Option C) should not require any Python. It's what USD was built to do out-of-the-box. You can bring your static model into Solaris for lookdev, and then bring the animation in as a separate layer that you can just overlay on the static model.

Something like this (you'll see the animation layer comes in with no geometry - just transform info):
https://www.youtube.com/watch?v=cFqUBPFU07E [www.youtube.com]

Ok, good to know and it helps a bit, If I import the transforms only using the "sceneimport1" set to not import geo/materials and sublayer that onto a frozen, "timeshift1" set to frame 0, stage it goes from around 3 to 15fps. (Houdini GL/flat shaded viewport)

Just the frozen layer plays back at +120 fps, so that's not causing any performance drops, the xform-only "sceneimport1" does 19fps and when combining those using the "sublayer1" I see the animation working fine but at a measly 15fps. Even when I just inport the xform of a single object.

We're talking less to 100 lowres objects here, not even 20 are animated. And when I simply use a USD transform node after the timeshift I can animate a few prims and get +-35..30 fps, not great either.

For reference, the /obj context does everything at +100 easily.

Jonathan de Blok
We're talking less to 100 lowres objects here, not even 20 are animated. And when I simply use a USD transform node after the timeshift I can animate a few prims and get +-35..30 fps, not great either.

For reference, the /obj context does everything at +100 easily.

What FPS do you get if you export a USD, rather than using Scene Import?

Curious if you've found any other solutions since the last post. We're looking to move toward Karma XPU from Octane and this FPS issue seems like a bit of a hassle.

futoryan
Curious if you've found any other solutions since the last post. We're looking to move toward Karma XPU from Octane and this FPS issue seems like a bit of a hassle.

Anything converting a ton of geometry from Sops to Lops is gonna slow down the viewport playback quite a bit. You are always better off precaching anything to USD before bringing it into Lops to not have to author any timesamples on the stage (the little green clock icon). Although this is really just a big problem when you have a lot of animated point data.

There are some smart workarounds you can do for animating non deforming geo that will increase performance, like just extracting the point xforms and doing a "Transform by SOP points" and applying those to a usd asset, you just have to match the prim and point paths. For deforming skinned geo using USDSkel massively increases performance vs just sopimporting the animated geometry to the stage, but this is more complicated and documentation is not as robust as it should be to get it to work (you have to a do a lot of shenanigans with agents and scene graph restructuring)

I'd just start by precaching all your stuff to USD to avoid that conversion from sops to lops and also making sure you are not authoring timesamples where you don't have to and you should see massive performance boosts.