Hi!

With the new light instancing workflow from H20.5, is it possible to override all the USD attributes from the light? I thought that only the color and the intensity were possible to override but thanks to another user I learned that in theory, other attributes should be possible to override too, like the spread or the exposure, the thing is, if I try to override the "height" or the "width" from a rectangle light, it is not working, maybe I'm missing a custom syntax for those cases? or what can I be missing to do this correctly?



For example, if I change from rectLight to disk, the radius attribute override is not working here either.

Let me know if I'm doing something wrong, thanks!

Just to double-check, if you reopen that scene, or do lots of bypassing and reenabling, does the issue persist? There are some issues with Hydra not handling some of these overrides well, but usually with enough kicking the information will flow through to the renderer. When I open your scene I see variation in the light dimensions.

Hi Rob!

Another user told me that it was working correctly in the daily build 20.5.307 and it works indeed:



So something is already fixed from this between the current production and the daily build .


It is curious that the "radius" attribute affects the Rectangle light right? or also that the width/height affects a Disk light:




The only thing is that I can't still see the instanced lights on Houdini VK (already mentioned on this thread [www.sidefx.com]), it is the same on your side?

In the other hand, I have one more question about the light instancing workflow, for cases where I have multiple lights in one instanced asset, there is a way to control or "map" the overrides? let's say that I want to apply the overrides only on the "arealight1"



Thanks again!

cdordelly
Another user told me that it was working correctly in the daily build 20.5.307 and it works indeed

Happy to hear it. If the overrides stop picking up again, try restarting the renderer (or switch back and forth between Karma CPU & XPU). Sometimes Hydra just needs a little kick.

cdordelly
I can't still see the instanced lights on Houdini VK

I believe this is still WIP.

cdordelly
It is curious that the "radius" attribute affects the Rectangle light right

I've pinged the Karma team about this. I don't know if this is a feature or a bug.

cdordelly
I have one more question about the light instancing workflow, for cases where I have multiple lights in one instanced asset, there is a way to control or "map" the overrides? let's say that I want to apply the overrides only on the "arealight1"

I'm having a bit of trouble lining up the wording of this question with the image you posted. The image looked to me as though you were instancing a mix of rect & disk lights, but only ever one light per point/instance. The wording, however, sounds more like "I want to create many instances of a car that has a bunch of individual lights". Which (if either) is closer to what you're working on?

I'm having a bit of trouble lining up the wording of this question with the image you posted

Sorry for my bad explanation and thanks for your other answers.

Let's use the car as an example (don't pay too much attention that it is a car, let's think about it as an asset with multiple lights)

1 - Let's say that I have the car asset with the geometry and the light, as an individual asset like this:



As you can see, just for a reference purpose, one light is red and the other is blue (*cyan)

2 - If I instance the Car asset, it is correctly instanced:




3 - Now here is my question, right now if do any light overrides, they will be applied the same to every instanced light:



Now here is my question, there is a way to "map" which lights will be affected by the override? let's say that I want to affect only one of my two lights from this "asset" (Remember to don't pay too much attention that this is a car on the example hehe)


I hope my question is now better understood 😅 :P

Let me know,

Thanks!

cdordelly
I hope my question is now better understood 😅

Thank you, yes that clearly explains the workflow to me.

If you're instancing the entire "car", then you'll need a unique primvar for each light. My initial reaction was to reach for light filters and primvar readers here, but I'm having some trouble making this work. If I can get a working test scene, I'll share it here with you.

Great, thanks!

cdordelly
It is curious that the "radius" attribute affects the Rectangle light right

robp_sidefx
I've pinged the Karma team about this. I don't know if this is a feature or a bug.

I believe we're treating this as a bug, and it's been changed in 20.5.312

robp_sidefx

cdordelly
I hope my question is now better understood 😅

Thank you, yes that clearly explains the workflow to me.

If you're instancing the entire "car", then you'll need a unique primvar for each light. My initial reaction was to reach for light filters and primvar readers here, but I'm having some trouble making this work. If I can get a working test scene, I'll share it here with you.

it would be great to have more generic mechanism for these kind of selective overrides rather than having to author unique primvars on lightfilter level
similarly on materials, if 2 object inside of instance have same material (or material with the same graph and primvar names) it would still be good to be able ot override just one material with primvar rather than customizing the materials to use different primvar names

if not on USD level, then at least on Karma level, similar to how Mantra has Stylesheets or I believe Arnold has operators that can handle this

simply patternmatching is important for overrides and LOPs level control seems imited in case of instances
and also overall nodes that aim to help with creating selective overrides beyond primvars, like Assign MAterial LOP or Edit Prototypes bake all the changes in the resulting usd layer making changing of the override rules impossible on the resulting USD file

it sounds like a job for USD procedural or Scene Index plugin or however they call it, simply to be able to author material overrides on resulting scene that would also take into account previously resolved procedurals to be able to selectively override data create by those
while in the USd file they would be authored as a set of rules that is easily editable later or overridable through composition and is taken into account and applied only during procedural evaluation