Hi guys how i can instance lights inside solaris? when i try to use instancer node don't work

USD does not support rendering of instanced lights at the moment. You can set your instancer to create “References” rather than “point instancer” or “instanceable references”, and you'll get a similar structure, but without any instancing. Which is less efficient, but currently the only approach that works with rendering lights in USD.

мтукер
USD does not support rendering of instanced lights at the moment. You can set your instancer to create "References" rather than "point instancer" or "instanceable references", and you'll get a similar structure, but without any instancing. Which is less efficient, but currently the only approach that works with rendering lights in USD.

can you please make an example - it doesn't work

A light cannot be instanced, from a rendering perspective, but USD allows almost "anything" to be copied by telling Houdini to "reference" the primitive instead of "instance" the primitive.

mtucker
USD does not support rendering of instanced lights at the moment. You can set your instancer to create "References" rather than "point instancer" or "instanceable references", and you'll get a similar structure, but without any instancing. Which is less efficient, but currently the only approach that works with rendering lights in USD.

Does this apply to "nested instancing" as well?

For example, I set up a car with lights scattered throughout using the "reference" method.
Then I want to instance that car around using a point instancer.
I'm finding that I only get a set of lights on one of the instances and not all.

So, is it correct that if there are lights anywhere within the instance hierarchy, it must always use "reference"?

bonjarry
Does this apply to "nested instancing" as well?

For example, I set up a car with lights scattered throughout using the "reference" method.
Then I want to instance that car around using a point instancer.
I'm finding that I only get a set of lights on one of the instances and not all.

I'm having exactly the same issue right now We're looking into using for loops?

You cannot Instance lights - they can be copied/duplicated by using either of the Reference type(s).

I think light instancing/point-instancing works in Houdini 20, when the Hydra delegate supports it. From what I understand Pixar added it in USD 23.08, but it requires implementation on the delegate side to work (reading instance-attributes from each light prototype).

As far as I know, both RenderMan and VRay supports it at this point. Not sure about other renderers.

Dan_Andersen
From what I understand Pixar added it in USD 23.08, but it requires implementation on the delegate side to work

Yep, that's a good summary of the state of things. Karma does not yet support this.

Beyond the renderer, we also have to consider the impact of this as a workflow in Solaris - for example the Light Mixer.

@robp_sidefx - what part is not supported by Karma?

Light Referencing (which in reality is just a copy of a USD Prim), has worked in Karma since Day 1 I believe.

I assume this new USD feature is something beyond that?....

TwinSnakes007
@robp_sidefx - what part is not supported by Karma?
Light Instancing (which in reality is just a copy of a USD Prim), has worked in Karma since Day 1 I believe.

Yes, copying/referencing the prim works. But if you switch the "Method" on that node to "Point Instancer" the lights don't instance. Historically this wasn't supported in Hydra at all but, with 23.08, it is (but the render delegate still needs to do some work to support this).

Thanks for those details.

I'm probably gonna regret asking this but, what distinction is this new part of the USD spec. making?

From a renderer perspective, Lights cannot be "instanced" in the technical sense, and Reference already allows you to basically "copy" any USD Prim.

TwinSnakes007
I'm probably gonna regret asking this but, what distinction is this new part of the USD spec. making?

I'd say it's not strictly a USD thing, but rather a Hydra thing. There's never been anything stopping people from authoring USD that has a PointInstancer with light prototypes, but that's historically never been translated through Hydra such that the renderer sees it. There are a few things with lights like that (i.e., USD that you can author which doesn't translate through Hydra).

From a renderer perspective, Lights cannot be "instanced" in the technical sense...

I'd be tempted to say "depends on the renderer", but I'm not sure it's important either way to what follows.

...and Reference already allows you to basically "copy" any USD Prim.

Yes. And perhaps for the *renderer* that's good enough. For working with the USD Stage, it might not be.

My user-story for this is a nighttime helicopter shot of a busy downtown city with thousands of cars with headlights & tail-lights. There is a noticeable performance difference working with a USD Stage that has 1 PointInstancer prim vs 10000 reference prims.

Ahhhh - thanks for that - well said.

I now can safely say, "I can see the Light!"

robp_sidefx
There are a few things with lights like that (i.e., USD that you can author which doesn't translate through Hydra).

Like spheres and nurbs

jsmack
Like spheres and nurbs

Spheres are coming

Requires use of the Hydra 2.0 StageSceneIndex and a renderer that supports spheres, but the plumbing for this one is already in place: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImaging/sphereAdapter.cpp#L64-L73 [github.com]

robp_sidefx

jsmack
Like spheres and nurbs

Spheres are coming

Requires use of the Hydra 2.0 StageSceneIndex and a renderer that supports spheres, but the plumbing for this one is already in place: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImaging/sphereAdapter.cpp#L64-L73 [github.com]

does there have to be an adapter for every kind of prim for which a renderer may want to have direct access to in the scene?

Edit:
I see cylinder and cube adapters in that repo too, will karma be able to render cylinders directly like mantra then?

jsmack
does there have to be an adapter for every kind of prim for which a renderer may want to have direct access to in the scene?

USD -> Hydra has been built around the concept of "prim adapters" for a long long time and yes there's basically an adapter per USD prim type.

Historically, the SphereAdapter converted USD Sphere prims to tesselated Hydra mesh prims. That previous API still exists, but in parallel there's a new API for the StageSceneIndex which generates Hydra sphere prims.

jsmack
I see cylinder and cube adapters in that repo too, will karma be able to render cylinders directly like mantra then?

This requires both development in Karma itself (to support these implicit types) and a move to the new StageSceneIndex. So I'm afraid I can't offer more than "maybe one day" in reply to that question, sorry

Hello does annyone know if you can get instanced lights with rendered geometry to render without using a separate surface ?

Hello! Is it possible to somehow optimize lights using the active radius? In Mantra, if we instantiated thousands of lights, we could give them an active radius and they would not be sampled in those areas where the light source did not reach. In Karma, the active radius does not help and when trying to copy 1000 lights, the rendering slows down tooooo much.