Inside a SOP Modify LOP with your USD static asset model feeding in, Capture and rig USD prims directly with a capture+control HDA asset, or; put down a fully rigged HDA including geo of your asset, animate it, and transfer the transforms over to the incoming USD prims?
Post:
To artists familiar with rigging assets for the creation of an animation layer in Solaris.
I'm exploring different ways to rig a model (vehicle, for example) for the purpose of creating animation layers "on top" of a geometry layer of the model in Solaris. Demo scene attached.
Please can you give your thoughts on the two methods, or propose others. Suggest workarounds/solutions for any of the "issues" described below, or generally discuss your preferences for this type of workflow.
In the demo, I've refrained from using actual asset HDAs, and just left what would normally be an HDA for a model or a capture/control rig as SOP nodes. I also haven't implemented the actual layers in Solaris, because the question is about the chosen workflow for getting there, i.e, what bits of the process to do where.
So just assume that in production you'd have an HDA of a finished model, or possibly SOP geometry that is authored directly into a finished USD model asset, where the USD asset is in place of an HDA.
Here are two methods that take you from a static USD geometry asset in LOPS, to a geometry asset with an animation layer for a shot. For each method you would:
- Make a model HDA asset (or just SOPS geo to USD if only using a USD model asset)
- Make a capture and control rig HDA asset
- Use the model asset to author a USD asset in Solaris
1. Green Example - Rig and animate USD prims directly in a SOP Modify LOP. With the USD asset ready to go, pass it into your capture and control rig HDA in a SOP Modify LOP to capture and animate the USD prims or unpacked meshes. Pass the animated prims back to Solaris with a layer break giving you the animation layer data separation. Note: Working directly on packed USD prims like this can be great for simple mechanical models. Lacks flexibility for more complicated stuff.
2. Red Example - Animate a rigged HDA and transfer motion to USD prims in a SOP Modify LOP. Author your static USD model asset from the (rigged?) HDA asset. Again pass your USD asset into a SOP Modify LOP, but instead of feeding it to an HDA that captures it and rigs, you put down your fully rigged HDA for the asset (geometry, capture & control all included) and then do your animation on that. Lastly, transfer the animation transforms and deforms over to the incoming USD prims, unpacking as necessary, being very careful of prim number ordering and all that. Back to LOPS and a new animation layer goes out to disk.
I've tried to demonstrate these two concepts with a very simple sub model, built with a simple SOPS example rig and usd asset in a "setup" area, with the two animation examples to the right in two different coloured network boxes. Inside each SOP Modify LOP is the attempt at showing the two ideas above.
Issues Encountered
Packed prim centroids
I had some issues working with packed prims in the rigs getting the centroids in the right places for axis of rotations. As an aside, perhaps you could also suggest some ways to get better control over preserving the transforms and pivot locations of rigged parts. Or transferring that back to a part after rigging it with an attribute. I tried using get & set packedtransform VEX functions to sort it out in the red Sop Modify > in the red wrangle.
@name
The
@nameprim attribute is used during the capture process to match geometry (packed prims in this case) to the skeleton hierarchy @name point attribute.The
@nameattribute is also used to help arrange the hierarchy of components when authoring the same geometry to USD, but I often find I need a different hierarchy for animation than I do for USD scene graph.I tried using another attribute nameon the capturepackedgeo SOP for rigging capture, e.g.
@rig_name, but the subsequent bonedeform SOP warned @name was missing and didn't work.Check inside the "create_SOP_asset_capture_rig" SOPnet. I've stumbled around this on the pale yellow network box by renaming according to the desired skeleton hierarchy. But it will cause problems later, because now the name attributes don't match the parts. Could be as simple as transferring the original names back after capture? Will the capture still function though...
Transferring motion from rigged HDA to non-rigged USD
Using the
getpackedtransform& setpackedtransformVEX functions in the red wrangle in the red Sop Modify. It will cause problems if the prim numbers are different between the rigged HDA and the USD prims. As described in the @nameissue above, the prim structure for a rig and for a USD asset won't likely be the same.You might want the majority of your packed prims on one root vehicle skeleton join for animation, yet for USD authoring, you want all those (g)prims available separately for a better hierarchy.
I guess you could keep them all separate in the rig too, with extra joints to capture them, but that is extra work. What am I missing?
