Variant workflow including lights

   1119   8   2
User Avatar
Member
55 posts
Joined: May 2013
Offline
I'm working on a fairground scene that needs to have a load of instanced lights - the geometry is the same for each one but there are a number of different colours / brightnesses etc and I'm unsure how to go about it.

I did another shot that only had a few bulbs so I just used a pair of duplicate LOPs and assigned different shaders to each one, then edited the light properties for each.

This time though that's not practical. I'm trying to use the component builder and I know how to add material variants but I need for each one of those to adjust the light prim itself and I can't figure it out. Does anyone have any clues?

Thanks for reading
User Avatar
Member
22 posts
Joined: June 2013
Offline
So one "asset" would be a lightbulb geometry + its material + 1 point light?
In that case, I'm not sure you could use the component builder... I might be wrong, but I'd personally do it "by hand".

I attached a sample hip file with how I'd do that. Hope it helps.

Attachments:
test_lights.01.hiplc (549.9 KB)

User Avatar
Member
55 posts
Joined: May 2013
Offline
Thanks very much Alexandru, that's really helpful.

What I did in the end was use the component builder for the geo and shader and instance that then made another instancer for the lights themselves and duplicated the logic to set colour and brightness to match.

Your scene looks like a much more robust way of doing it, I'll try and rebuild my scene with that approach.

Can I just ask is the right way to go about instancing with your method to use an explorevariants LOP and an instancer set to reference method? It seems to work but in case I'm doing something I shouldn't...
User Avatar
Member
55 posts
Joined: May 2013
Offline
Another question if you don't mind...

Is this a bad workflow for making a proxy for the bulb geo ? I tried duplicating the sopcreate to make a very lowres sphere at /ASSET/proxygeo then a pair of configureprimitive LOPs to set purposes - it appears to work, but as before I'm unsure if I'm doing something wrong

Attachments:
proxy_workflow.jpg (117.1 KB)

User Avatar
Member
355 posts
Joined: Nov. 2015
Offline
j00ey
Another question if you don't mind...

Is this a bad workflow for making a proxy for the bulb geo ? I tried duplicating the sopcreate to make a very lowres sphere at /ASSET/proxygeo then a pair of configureprimitive LOPs to set purposes - it appears to work, but as before I'm unsure if I'm doing something wrong

Once it works! though you could use the one sop create and use primitive path attributes to differentiate main geo and proxy.

s@path = ‘geo/render/bulb’;
s@path = ‘geo/proxy/bulb’;

for render and proxy geo respectively, and merge them. USD will import them correctly!
hou.f*ckatdskmaya().forever()
User Avatar
Member
22 posts
Joined: June 2013
Offline
Definitely works with another SOPcreate for proxy and 2 configureprimitives. I don't think it is meant to automatically pick up words like "proxy" and "render" from the paths attribute, but I might be wrong. Either way, I'd still manually set it with configureprimitives, just for my sanity.

Now, about light instancing, I had no idea if you asked for it to be instanceable it wouldn't copy the light as well. I tried (in the attached file) to bring everything as reference and then mark the geometry primitives as instanceable. Ideally, you would want your geometry to keep being instanceable because it should be more efficient.

Attachments:
test_lights.02.hiplc (575.4 KB)

User Avatar
Member
355 posts
Joined: Nov. 2015
Offline
alexandru_p
Definitely works with another SOPcreate for proxy and 2 configureprimitives. I don't think it is meant to automatically pick up words like "proxy" and "render" from the paths attribute, but I might be wrong. Either way, I'd still manually set it with configureprimitives, just for my sanity.

Now, about light instancing, I had no idea if you asked for it to be instanceable it wouldn't copy the light as well. I tried (in the attached file) to bring everything as reference and then mark the geometry primitives as instanceable. Ideally, you would want your geometry to keep being instanceable because it should be more efficient.

Yes, using the path attribute with 'proxy' and 'render' won't do anything in terms of purposes as far as I know, it's just saying where the prim will live in the scene graph, you'd still need to use the configure prim LOPS to setup the purposes, but it saves you needing 2 SOP creates to manage.
hou.f*ckatdskmaya().forever()
User Avatar
Member
55 posts
Joined: May 2013
Offline
Thanks a lot for the input both. I'll look into it properly on Monday when I'm back at my machine.
User Avatar
Member
22 posts
Joined: June 2013
Offline
traileverse
Yes, using the path attribute with 'proxy' and 'render' won't do anything in terms of purposes as far as I know, it's just saying where the prim will live in the scene graph, you'd still need to use the configure prim LOPS to setup the purposes, but it saves you needing 2 SOP creates to manage.

Yes, that's right. I misunderstood what you were saying. I guess it's more of a preference thing here, if you wish to have both proxy and render geometry saved in a single layer (a single usd file), then you could just merge them with the proper paths and use a single sopcreate/sopimport... If you want to have seperate geo files, the use two sopcreates/sopimports...
  • Quick Links