UsdLuxDomeLight, what is the canonical visual representation, and is there a way to designate screen visibility vs lighting contribution independently in a standard way?
Unfortunately I cannot find a description of intent here, and different renderers treat this in their own unique way with their own unique attributes. e.g Storm displays DomeLights as the background whereas Karma and Vray require custom attributes to do so.
If its not specified yet, perhaps it might be worth adding a TfToken attribute like
showBackground to the
UsdDomeLight_1 with the following tokens:
auto: renderer defined to preserve current behaviour
visible: display it
hidden: hidden but still contributes to lighting.
This is more of a schema question so I was putting it in the USD category, but would be curious to hear from Hydra folks too.
Note that Storm has a parameter that you can set re: whether its shown or not.
You can see this at work in usdview:
Display->Show Dome Light Textures
I wish this was exposed in usdrecord - I need to submit a PR…
Rather than introducing a DomeLight-specific visibility flag, I think we’d rather address the more general visibility problem, which I’ll state as “refining which rays an object is visible to”, which in the case described here would be “invisible to camera rays”, which is a thing we often want to do for any kind of light.
The blocking thing here is deciding what types of rays to canonize, and whether this “statement of visibility” is simply an inheritable attribute (as in prman), or more of a “relating one collection of observers to a collection of observed objects”, as it is in the way-back pages of the MaterialX spec. We’ve been not-totally-energized on this one for years now, since it’s largely an issue for us in prman, and we continue to use prman’s own, non-general featureset for our needs.
If there are folks that want to step up to help sort it out, speak up!
If I understand your collection to collections comment, you’re referring to a collection of cameras that can then see the collection of lights? so CameraX might see LightA+B, whereas CameraY might see LightB+C?
One confounding aspect might be that for AR scenes the USD stages don’t include a camera as that’s provided by the renderer so you wouldn’t be able to specify collection sets for it.
I guess the other question is, if something isn’t in the collection is it visible or invisible by default?
There is something nice about the locality of a prim specific attribute rather than a collection set when it comes to composition. But I see the value in both an attribute or collection set method too.
I’m very interested in this, and would propose adding camera and shadow visibility to all light types as part of a UsdLux upgrade.
Going beyond that to other ray types might start to get a bit hairy, but we can see what other renderers think.
But why would you limit it to lights, Anders? Wouldn’t you want those abilities for all scene objects?