USD and Sops Part 2
Thanks to some poking from Oliver Hotz 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:
/asset /geo /upperdoor /lowerdoor /leftwall /rightwall /material /doorMat
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 expose 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 meters 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, while the sci-fi door was all the pieces under the root prim.
Sops in Houdini is unaware of hierarchies (apart from kinefx). 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 writing USD directly from sops, but if you expect to do further edits in lops that take into account parenting, look out. You'll get the hierarchical transforms applied first, then your baked-to-worldspace transforms in your sop usd edits after and get crazy results. It's similar to the frequent issues people run into with complex maya rigging and double transformations.
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: UsdGuide18 main menu: UsdGuide