After reading a bit, about UsdGeom Purpose in OpenUSD, it feels like guide is being overloaded with responsibilities beyond its original design intent, especially due to recommendations in the UsdPhysics module.
Here’s one of the definition for UsdGeomGuide Purpose which I am using to define the original “intent” (stolen from one of the core guideline docs):
guide indicates scene elements that may be optionally enabled for reference or as hints. For example, a Sphere could be added as a region to avoid in a crowd simulation. guide is not considered a part of the canonical imaging view.
Some other examples for “correct” usage of guide purpose that I can think of:
Conveyor direction for a conveyor asset can be represented by an arrow shape which is set to guide
An explosive prop in a set with an “impact radius” can be represented by a translucent sphere set as guide
Both of these are optional visualization aids that don’t change canonical imaging, but provide context to the scene.
Following the definition above, the UsdPhysics recommendation to set Physics Colliders as guide seems to stretch the original intent of guide, since colliders are not really optional hints, but rather functional components.
This makes it a bit messy to work with guide. Currently, if I enable guide rendering in the viewport it will start rendering actual guide geometry along side with custom physics colliders of different meshes, which is undesirable. So, now I have to filter and remove the GPrims that have CollisionAPI which seems like extra work.
And to be honest, I wonder why physics colliders are marked as guide in the first place, when there’s a Collider schema and invisibility property (for Imageable) that doesn’t deactivate the collision (as it only affects rendering).
I’d love to understand the reasoning behind this choice: was it purely convenience, or was there a deeper design goal?
I cannot speak for the physics case, but in the VFX world, we use the Guide purpose to store anything we don’t want to be rendered (imaged). For example, when working on a creature that has muscle simulation, we need to model the skeleton, the muscles and the skin which are all mesh prims and pass them all to downstream departments in the pipeline, like rigging and animation. Of all those departments, only rigging and creature-fx need to see the skeleton and the muscles to do their work. All the people in all the other departments never need to see them either in the viewport or in the render. So the guide purpose is perfect in that case.
The problem with using visibility for this is that if someone in one department authors an opinion to make the muscles visible and then exports that opinion in their layer, they become visible to everybody downstream unless someone else makes them invisible in a higher layer. It’s not destructive, but it’s much less elegant than relying on purpose which is fool proof.
Thanks for sharing that perspective — it’s helpful to see how guide has been adopted in VFX pipelines.
That said, I still find myself a bit stuck: in your example (muscles/skeletons), the use of guide seems to go beyond the original “optional hints/reference” intent as well, essentially treating guide as a catch-all for “things we don’t want rendered.” To me, that feels very similar to just using visibility, since both can be authored and overridden downstream. I’m not sure I see why purpose is “fool proof” while visibility is not, given that both are layer opinions that can change. I understand that artists may toggle visibility on/off more often than changing purpose, but from a technical perspective both are just attributes introduced by Imageable.
It seems like pipelines adopt guide in ways that are convenient for them, but that flexibility comes at the cost of standardization.
Bringing it back to my original concern: the UsdPhysics recommendation to set colliders as guide feels confusing. Colliders aren’t optional hints, they’re functional elements, so lumping them under the same purpose as arrows/spheres for visualization makes it harder to cleanly separate the concepts.
Do you (or anyone else here) know the reasoning behind why colliders specifically were assigned guide? Was it purely to avoid them showing up in final renders, or was there another design motivation?
Its all a bit subjective really… I think one of your examples also goes beyond being just a hint. The impact-zone sphere presumably could be used to trigger behaviours of other scene elements (e.g characters try to avoid the zone & behave differently when they enter it).
You could argue physics colliders are more critical than some arbitrary behaviour trigger, but someone who doesn’t want to simulate that asset probably doesn’t see either of them as important. So where is the line drawn?
At the end of the day, USD is designed with graphics/rendering in mind, and the purpose is just categorizing geometry:
What really exists in the world
and should usually be rendered (default)
and should be conditionally rendered if resources are limited (render and proxy)
What does not really exist in the world (guide)
The nice thing about using guide for colliders is that you can author them as visible without worrying they will appear in final renders, and you can visualize (or inviz) them in most DCCs without authoring any opinions. Arguably a dedicated physics purpose could do the same, but purpose is not extendable currently.
One thing I’ve found very awkward working with physics assets lately is that you can’t currently “solo” the guides in usdview, and since default + collision geo is usually overlapping, its very hard to actually view the colliders on their own. Its so annoying that I’ve hacked in the feature on a dev branch… when I get time to clean it up I’ll try to PR that.
I think you are correct that guide is probably being used not as directly as it was originally intended, but I agree with everyone else that there is a need for a usage for supplemental geometry and data that isn’t tied to the visibility.
If guide didn’t exist I imagine people would use proxy + visibility and that would be reasonably safe since it would only ever be visible for viewport renderers, but since guide does exist and is the only option, people will use it.
We use it internally for the same thing as Flord ( watertight sim geo, guide curves, etc ).