Please consider allowing more types of "guide" in the purpose attribute

[koen-v]

Hello Pixar,

I very much appreciate the option to mark geometry as render, guide or proxy in usd. Especially since most applications support this, it is a very easy way to add simple filtering to the viewport. Usually toggling these on and off is much faster than operations which cause the stage to re-compose.

When converting one of our game levels to usd, we have a lot of annotations in the scene that should not render. I mark these as guide and it works. An issue with this approach is that in many game levels, the amount of non-render geometry can be huge and vary a lot by use case. For example, we add boxes as "volumes" to define lighting settings, or post-effects ( color correction etc) per area. Other use cases are volumes to define areas with particular sounds properties. One very common use is collision geometry, where the entire world is represented in a simplified way to aid in collision calculations ( often even a few different ones for different needs).

All this makes the guide geometry pretty overwhelming when turned on. Since the use cases are quite different ( imagine a lighting artist vs and audio artist) it would be great to have some "sub-categories" in the purpose, much like the "kind" has.

Please let me know if that makes sense or if there is anything I should elaborate on.

Thanks, Koen

[sunyab]

Filed as internal issue #USD-7885

[spiffmon]

Thanks for filing, @koen-v ! I don't think we can do "sub-categories", based on my understanding of how Hydra dispatches visibility based on kind, which is that each object can only belong to a single "collection", and a "reflectionVolume" purpose that is a "kind of" guide purpose would naturally belong to two collections. We'll dig into this question when we can pursue this ticket, but I wanted to ask if you'd still have a good workflow if all of your "extension purposes" were unrelated to any other purpose?

[koen-v]

Hello Spiff,

Make sense that a prim can only belong to a single collection. My fear with creating independent purposes, is that applications without full support would not be able to show/hide these at all.

In an ideal world, a "reflectionVolume" is a subclass of guide, so that tools which know how to deal with all these derived types can present them to the user, but for all the tools that dont support this (yet), the reflectionVolume would be demoted to just be a regular "guide" and we have the same behavior we have now.

Ideally (although this would not fit nicely with other usd designs, it's just to illustrate the idea) a purpose could be guide.lighting or guide/lighting, where it's up to the tools to support the second part.