Difference between revisions of "UsdGuide17"

From cgwiki
Line 51: Line 51:
If you want that stuff, go into Lops.
If you want that stuff, go into Lops.
prev: [[UsdGuide16]] this: [[UsdGuide17]] next: [[]] <br>
main menu: [[UsdGuide]]

Revision as of 23:55, 2 June 2021

USD and Sops Part 2

Thanks to some poking from Oliver Hots and Thomas Christensen, we uncovered some interesting things in terms of how USD works within sops vs within lops, and thanks to Ben Skinner, we got answers to most of these.

USD sops and hierarchies and layering

One of the earlier examples created a little scene saved to a usd file, then things were moved in lops, and that was saved as a seperate usd file, later both files could be composed together.

Oliver proposed the following; if you can read and write USD from sops, and Lops is still pretty foreign to most users, could you let animators just do their work in vanilla sops and have it compose properly?

The answer is 'sort of'.

Simple sops level overrides

Oliver created a scifi door with materials, geo, names, saved something like this:


This could be loaded in lops, move bits, save work as a new file, which would just contain the edits, not the full work.

It's possible to do the same in sops. The important thing is to ensure you convert the geo correctly in sops. Unpack as 'gprims', which will epose the 4 packed usd prims for the door and wall, animate stuff, save a usd. Back in lops you can append a sublayer or a reference, as long as the names match up, you'll get the appropriate behaviour.

Sops level overrides with hierarchies

Oliver than presented a car. When he tried the same method to rotate the wheels, the combined scene had the wheels scale 1000x, hundreds of meteres below the car. What happened?

The key difference was that the car was saved in hierarchy; tyres parented under wheel arches under wheel transforms under car. The scifi door was all the pieces under the root prim.

Houdini sops is (apart from kinefx) is unaware of hierarchies. You're just treating everything as a bunch of points. When you import usd into sops it stores the hierachy in the @path attribute, but its just a string, eg "/asset/car/wheelbase/wheelFrontRight/hub". The actual position and rotation of each prim is baked into worldspace, parent hierarchies are ignored.

That's fine if you're just going to output geometry in isolation, but will cause issues if you try and overlay this file onto the original usd asset in lops. You'll get the hierarchical transforms applied first, then your baked-to-worldspace transforms in your sop usd edits after, and get crazy results.

The fix makes sense, but needs some thought. You have to cancel out the hierarchical animation, leaving just the changes you made.

Luckily when you import usd to sops, it creates an intrinsic 'usdLocalToWorld', which is the matrix representing all the parent hierarchy transforms. You can copy that to an @xform attribute, then use a 'transform by attribute' sop to apply this with the invert toggle enabled. Now that the parent hierarchies have been removed, you can export your usd file, and when that is appended over in lops, it will behave as expected.

Trim your sop exports

The USD sop rop will export animated caches for all 800 of your usd packed prims, even if only 2 are animating; it has no way to know whats animated or whats not, so it just exports everything. Better to use a split sop early on to only export the stuff you know you'll animate.

Fancy USDisms don't work in sops

The main ones being crowds and point instancers. They're more than can just be represented as straight packed prims or packed USD, so they'll just be ignored.

If you want that stuff, go into Lops.

prev: UsdGuide16 this: UsdGuide17 next: [[]]
main menu: UsdGuide