[HOU-4225] Light parented in a class primitive is still visible when it shouldn't

Hi,
I’m trying to use the class prim system to instance a light under some asset, the light is correctly being instanced over all the instances of this class, but for some reason the light from the class itself is still emitting when it shouldn’t (as the class is not getting rendered), is it the expected result in the current state of V-Ray, and if so is there a way to work around it?

Here I provided an example scene to illustrate the issue

V-Ray 6.2.05.22651
Houdini 20.0.506

Thanks,
Marvin

> is it the expected result in the current state of V-Ray

This could be fixed.

> and if so is there a way to work around it?

There is, you could disable light by disabling “Enabled” parameter.

> This could be fixed.

Yep that would be nice with a proper fix!

> There is, you could disable light by disabling “Enabled” parameter.

I didn’t expect this to work but it did!
It’s a bit of an odd behavior though, isn’t everything in the class supposed to be replicated exactly the same way on all it’s instances? So disabling the light would theoretically disable it on all it’s instances?

Either way thanks for the workaround!

-Marvin

> So disabling the light would theoretically disable it on all it’s instances?

No, instancer will enable instanced lights.

Just as an update and a confirmation/additional info:
Disabling the light in the class have different results depending on if the child is instanceable or not, so currently we have these unmatching behaviors:

1. If the prim referencing the class is instanceable, disabling the class light will only disable it on the class, otherwise the class light generates light, and none of the lights referencing that class lights are affected
2. If the prim referencing the class is not an instanceable/is a reference, disabling the light will correctly disable the class light and all the lights in the scene referencing it

For consistency would it be best to replicate the behavior of the second option, which I think is how USD expect classes to work?
I am working with a large layout that has a wide range of different cases and it would help a lot to have a consistent behavior, otherwise I’ll have to make different calls and override depending on how the asset is used

Thanks,
Marvin

Could you please try some recent nightly and check if it works for you?

If it still doesn’t work for you may be you could share a scene showcasing 1 and 2.

Hi Andrei,

Please find a debug scene with sticky notes for each test case in the link below:
https://drive.google.com/file/d/1BURIoKfoMHAaqlwOL\_6biG37R3XL5rHw/view?usp=sharing

This is a bit of an urgent issue, so we appreciate a quick fix for this.

Thanks!

> This is a bit of an urgent issue, so we appreciate a quick fix for this.

Well, I’m not yet sure it’s an issue…
You want disabling source light disable all instances as well?
How you’ll have disabled source light and enabled instanced then?

I think that’s what I would expect to happens yes.. as the instances should inherit everything from the source (light prototype for instancer and the /class/_<yourAsset>/<yourLight> for classes)?
In both cases the source is a prototype and shouldn’t stay enabled, the same way as you don’t see the class mesh appear in the middle of the scene because it’s a class, only the primitive referencing that class/prototype is visible

In the example scene Jacob sent you can see that on the correct behavior, the source light is enabled but doesn’t get rendered, so that’s how I would expect it to behave with instancer/class

This behavior is also a roadblock when having a mix of instanceable and reference prims, if I disable the prototype as you suggested to get rid of the class light manually, then the instanceable prim will have it forced to enabled, and the one that is a reference will have it disabled because it inherit (correctly) from the class, so from the same light source, some of them will be turned on or off if it’s an instance or a reference respectively.

I’ll have to think about it, this won’t be a “quick fix” for sure.

And I’m not sure why cone instances are marked as incorrect, result matched viewport and Karma.

Karma seems to be a bit behind on that feature, so I don’t think it’s possible to compare the behaviors.. I got told it was also working in Renderman, although I can’t test it.
Since this feature seems to be better supported in V-Ray I’m only reporting on the result I’m getting with V-Ray, and it’s currently a different behavior from the logic I would expect from this feature as explained earlier

Hello,

Related to the light instances, is there a way to have light select/Light tags/LPE working with a light instancer?

Thanks,
Marvin

Do you mean it doesn’t work at all for you or you want to have per-instance tags?

It doesn’t seems to work at all :frowning:

> It doesn’t seems to work at all

True… I’ve found the issue and will try to fix it asap.

Hello,
Is there any update on the original issue of this post?

> Is there any update on the original issue of this post?

This is no update.