We have been diligently observing the advice found at assets/docs/asset-structure-guidelines.md at main · usd-wg/assets · GitHub Basically for each model geo prim, maintain a separate child render and proxy scope for each respective hierarchy. This general prim scaffold seems to appear in just about all working USD examples you’re likely to come across.
As our pipeline matures we’re identifying a workflow weakness when it comes to Xforms which have some common expectations between proxy and render purposes. (layout artists making incorrect choices, or viewport selections, based on which purpose their viewport is set to - its not always obvious)
We’ve discussed a few pipeline strategies we could use to keep these in sync (And check when theyre not) but in truth there are quite a lot of potential workflows to ensure we maintain this sync.
Instead of those various systems, Im considering now maybe breaking away from the standard convention of: /apple (xform) ← Component Kind /geo (scope) /proxy (scope) ← Purpose: proxy★ /render (scope) ← Purpose: render★ /mtl (scope)
Feels like embracing this hierarchy, with xforms that sit above the renderable stuff, would simplify a few workflow things - but curious if anyone else out there has come across this issue and what solutions have worked for you.
This is perfectly valid. At my previous job, we had a structure where a component asset could have multiple subcomponents which could be transformed and animated without needing to be rigged.
If you have a fence around a house, it could have a subcomponent for the gate at the entrance and this can be opened, closed or animated by the layout artists without having to go through rigging.
However, we prefer to build all our assets with the same structure. At my current job, since we work on simpler projects, we decided this would not happen often enough to justify another level of hierarchy in all assets. We might revisit that decision in the future.
Appreciate the response! Always the way, think of a problem for weeks - post a question about it, but then it all kind of “clicks” in the minutes immediately after posintg..
I do think the sub-component hierarchy is the answer here. What this means for our modelling workflows is the challenge for me - and determining what should fall as a sub-component xform prim, and what should just be an inherent prim of the model. But in terms of downstream expectations and tightening those workflows, it makes the most sense. So yeah like you I think we’ll be having conversations now about the trade off between workflow-complexity and pipeline-capabilities.
A limitation of this organization (which we sometimes also use) is that it only allows for common modification of the affine transformation of both the proxy/render geometry (well, plus visibility, primvar inheritance, material binding). If there are geometric or other more specialized edits needed, in the future, OpenExec will allow for set-driven keys and much more to live on the subcomponent prim and individually drive proxy and render representations as needed, if needed.
A workflow issue that was the reason for the (not much used, I think) proxyPrim relationship on UsdGeomImageable is that if you select geometry in the viewport to direct manip or populate an inspector, you often (e.g. likely modally) want to redirect to the subcomponent that has the controls you need to edit. We hope that ratifying something like this proposal for PickAPI moves us in that direction.