What are USD’s thoughts on handling different visibility types, like primary visibility (aka render visibility) and similar attributes?
Right now, each render delegate (RenderMan, V-Ray, Arnold, etc.) has its own terminology and primvars, which makes things inconsistent.
Would it make sense to unify these concepts in USD? Instead of every renderer having its own settings (visible in refraction, cast shadows, affect GI, etc.), a unified schema could help simplify interoperability across renderers and avoid redundant attributes.
Is this something that has been discussed before? I get that we might not be able to reflect every delegate’s specific settings, but having a common baseline for the most widely used ones could be a good starting point.
just my 2c here: as far as I like to standardize as much as possible, I do think that not all renderers have all the same numbers or types of visibility states.
And “visibility” is also one of the trickiest attribute to handle in certain pipeline (VFX for example), where the “final” visibility is actually handled by RenderPasses (and activation and visibility modified for faster viewport/interactive renders, by users, are going to be reset when passes are applied, but all other per-renderer specific attributes are not, with pros/cons).
Having said that, there are probably common ones that could be moved in a more generic schema, or even agree on the actual logic for it
Agreed with @paoloemilioselva that standardization of a rich set of visibility sub-types may be challenging, but I bet we could all agree on camera and shadow, at least, and maybe a unified “secondary” ray…
Even given the observation that render passes are going to change visibility alot, having the means to author refined visibility opinions in the scenegraph, in combination with expression variables, gives you one way to specify/encode render passes.
We have discussed this internally, and one of the things that gets tossed around is whether simple attribute inheritance is fine (like basic visibility), or would you want it to be Collection-based, like LightAPI’s light and shadow linking? The latter gives you more expressivity especially with instancing, but is alot more complicated.
Highly relatedly, we are close to landing a change that could lead in this direction by introducing a visibility:camera attribute on LightAPI, to help renderers deal more consistently (initially) with whether to display a DomeLight’s texture or not. That attribute initially will not inherit, but it could, later, be lofted to a more generic schema, like VisibilityAPI.