We are converting a cad model into usd. The cad model is a hierarchy of parts and all geometry is a solid. We are currently converting the parts into payloads. Each part has three prims contained within it, each with a different purpose:
“proxy” for interactive visualization
“render” for high-end rendering and mesh simulation
“sim” for getting back to the parametric surface
Eventually, the sim purpose will contain a usd solid, but for now is a custom prim.
Couple of questions:
We are structuring assets because we don’t want to load the memory of render or solid when visualizing the geometry via things like usdview and OV; we don’t want to load the proxy or solid when doing mesh simulation. Are purposes that are not traversed loaded into memory?
The docs say creating a custom purpose is allowed… is that right? I don’t have a sense of what I am committing to by adding a custom purpose. My intent is to provide clear indications of what memory should be loaded based on the app loading USD knowing its purpose. Is there a better fit for what I am trying to do?
All the prims themselves from all the purposes will be fully composed onto the stage. But neither the stage nor the prim itself pulls any of the property data into memory. Hydra/renderers will likewise”populate” all of the prims into the Hydra scenegraph, but the actual mesh (etc) points, primvars, etc will only be pulled in for the active/selected purposes. Which I think aligns with your needs.
… kind of. Have a look at this Issue, which is related. Nothing stops you from adding a custom/extension purpose, but:
The entrypoint to Hydra is hardcoded currently with the canonical set of core purposes as options, and as a result you can only enable those purposes to be drawn. So AFAIK, you wouldn’t be able to visualize the “sim” purpose prims.
UsdGeomModelAPI.extentsHint machinery relies on knowledge of all the known purposes, so without us adding a plugin/registration of some kind for custom purposes, extentsHints on models may be incorrect/incomplete.
And while I would definitely do your own testing, I believe that regardless of how heavy any mesh/curves property data actually is, if you are using purpose to guard against the renderer-loading of the heavy data, then unless the different representations contain alot of prims, you probably aren’t saving much (and actually introducing some overhead) in putting them into different files so you can have payloads. If the independent files is useful for workflow purposes, don’t sweat it; but if savings is why you’re doing it, it may not be worth it. Assuming of course we’re talking about usdc files!
Amazing. Thanks for the insight, Sebastian. Sounds like purposes are what I need them to be.
Until USD gets a brep solid, the sim purpose is a bit of a conundrum and a workaround. I totally get that certain things won’t know our magical blind data purpose, but I’m hoping that’s okay because the hi-res render mesh is likely what those things would want to use anyway.
If you actually have Boundable custom schemas for your Solids reps, or if they contain some prims that Hydra would image but you don’t want it to, then you could consider setting them to purpose=guide . If Hydra doesn’t know what to do with any of your solid/parametric data, then it doesn’t actually need to be “protected” by purpose at all - it’d be doing the exact same amount of work over them either way.
Thanks. That’s helpful to know. I want a custom purpose for our traversals that need to find the solids. I also have a plan for guides that I am hoping to get around to at some point.