I found a usd-interest post from March where @spiff mentioned work just got underway. I wonder if there is an ETA, or if that’s still too early?
Thanks!
Dan
And to add a bit of context: A fair amount of what we do involve fleets of spacecraft. Often, the spacecraft are quite detailed and have elaborate lighting parented under prims in the asset-hierarchy. And often, each type of spacecraft needs to be duplicated multiple/many times for a given shot. For this, instancing is crucial.
Our pre-Hydra pipeline handled the rendertime duplication of lights for instanced models, but as we’re transitioning to Hydra we’re not sure what the best way to go about this is.
I’m curious how others are handling cases like this? Am I missing some trick or going about this the wrong way?
Cheers,
Dan
Just adding the link to that post from usd-interest in case others like me searched for it: https://groups.google.com/g/usd-interest/c/yiH0RHEEZIU/m/bjbse1wYBAAJ
1 Like
Instanced lighting should work; lights that are part of a point instancer prototype, or part of an instanceable reference, should get an instancer id in hydra, and they can use that to determine instance count/per-instance transform, visibility, variation, etc. We’ve implemented this in usdImaging (both UsdImagingDelegate and UsdImagingStageSceneIndex), as well as hdPrman.
Storm doesn’t support instanced lights yet, mostly because we still have a relatively low soft-cap on light count, but it would be straightforward to add: HdStLight is expected to produce a set of GlfSimpleLight objects to add to the lighting uniform buffer, and HdStLight could consult the instancing information (via GetInstancerId, HdRenderIndex::GetInstancer, etc) to produce extra GlfSimpleLight objects.
Hope this helps!
Hi Tom, thanks for your reply. When you say “instanced lighting should work”, I assume this means the work that spiff mentioned was underway has been completed?
I never managed to get instanced lights working (Solaris; any delegate I tried) - I guess this is exclusive to “Hydra 2.0”?
Hi Dan,
Yes, the work Spiff was talking about has been completed. Support for reading instanced lights from USD files was added in 23.08 (i.e. you can have a point instancer prototype or instanceable reference that contains a UsdLux light, and it will show up in hydra as an instanced light). This support extends to UsdImagingDelegate as well as Hydra 2.0. Support for hdPrman correctly evaluating instanced lights was added in 23.11. Note that Storm does not evaluate instanced lights, and I don’t know whether other render delegates such as Karma do.
In order to benefit from light instancing, a USD light that’s instanced is represented in hydra as a prototype light plus a set of instance attributes (primarily transform). Render delegates that don’t evaluate the instance attributes will just draw the prototype once with the prototype transform, which matches the old behavior.
As a transitional step, it should be straightforward to write a scene index filter plugin that de-instances lights; e.g. changes a light instanced 5 times into 5 uninstanced lights. This would work correctly with no change on the part of the render delegate, but would sacrifice performance benefits.
Hope that clarifies things.
Tom
Thanks so much for the detailed information - that’s super helpful.