Hi everybody,
I'm doing a Houdini course but I'm struggling to understand the workflow for lighting setups beyond the typical 3-4 canonical, theatrical lights for a shot.
Specifically, let's think for a moment about all the lights in a car, or in a building.
In a software like Maya I'd simply model the subject and at some point along that process I'd place lights where they belong, i.e. within windows, or where the headlights of the car are located. This can be quite efficient as I can, say, duplicate a floor and all the lights get duplicated with it.
In Houdini however the car or the building are modelled within the geometry context, but the lights are placed in the object context. Which brings up the question: how do I connect the lights at object level to the features at geometry level?
I am aware of the geometry lights, which currently seem to generate very noisy renderings and are best avoided. (?)
I understand one option is using rivet nodes as parents for each light. This is intuitive enough, but wouldn't scale well if a model has many lights and each rivet had to be set manually. Perhaps there are tools to semi-automate this? Also, it doesn't help if the underlying model is procedural: every time something changes more lights might be needed or existing lights might need deleting.
Another option is using an instancing node and an Object Merge within it to retrieve the target locations from the geometry context. This way of doing things seems more in line with the way Houdini works and would support proceduralism. But I've been struggling with it as sometimes the Instance node mysteriously declines to use the group of points I provided and generates zero instances with no error message in sight.
There's also the added complication of potentially having to store some or many of the lights parameters (say, arealight dimensions) as point attributes and then having to retrieve them object-context-side unless the lights are meant to be all perfectly identical.
I can see how I could create a small "Geometry-Side Arealight" HDA. This would provide some kind of interface to arealight parameters, it would store all the values on a point within it and it would add that point to a group that can be retrieved by the instance node. I could then position and edit copies of this HDA wherever I need an arealight.
It just seem all a bit convoluted and I'm wondering if this is just the typical workflow or if I'm missing something easier.
Kind regards,
Manu
Houdini Lighting Workflow
1947 2 1-
- manu3d
- Member
- 39 posts
- Joined: Dec. 2018
- Offline
-
- mestela
- Member
- 1850 posts
- Joined: May 2006
- Offline
A large part of what you're talking about is why solaris exists. 
While sops is very procedrual and lets you do all sorts of neat tricks, /obj definitely isn't, and drops you back into somewhat clunky manual copy/paste workflows, and the interchange with rops and sops can get quite confusing.
Solaris and lops is many things, but a key thing is that it allows proceduralism and more interesting node based workflows to lights/cameras/materials/rendering. There's still not a lot of reading material on it as its fairly new to houdini, and you have to sometimes fight through a lot of the USD terminology, but most of what you're after exists in lops.

While sops is very procedrual and lets you do all sorts of neat tricks, /obj definitely isn't, and drops you back into somewhat clunky manual copy/paste workflows, and the interchange with rops and sops can get quite confusing.
Solaris and lops is many things, but a key thing is that it allows proceduralism and more interesting node based workflows to lights/cameras/materials/rendering. There's still not a lot of reading material on it as its fairly new to houdini, and you have to sometimes fight through a lot of the USD terminology, but most of what you're after exists in lops.
-
- manu3d
- Member
- 39 posts
- Joined: Dec. 2018
- Offline
-
- Quick Links