There are several lights that appear both on the shelf and via the TAB menu. However, when you look closer, you will immediately notice alot of these are just setting parms differently on the same node types.
- Caustic Light,Indirect Light, and GI Light are all of type indirectlight
- Ambient Light is of type ambient
- Environment Light is of type envlight (so is half of Portal Light and Skylight – explanation below)
- Light Template is of type light
- Light, Point, Spot, Area, and Distant are of type hlight ( half of Sky Light is an light too)
Below the various light are examined closer and in terms of how they affect viewport matching…
light template (light)
Light templates are basic stripped down version of light and according to the docs intended for building up a new light type without having to strip down a light (hlight type) instance.
three_point_light is a great included HDA for a 3-point setup with all the widgets for control. The key, fill, rim and bounce light inside the three_point_light setup are all Light instances and type hlight. Each light in the setup will therefore match properly. However, looking through a three_point_light, is the same as looking through its key light. This is important to note as scripts that use this function should take into account that this difference cannot be discerned.
indirect and ambient lights
Since we are comparing the transform of the light to that of the viewport, we are going to want to check against lights that have controls to position it. indirectlight and ambient types lack these controls. This is logical, as they are indirect, having the ability to absolutely position them via viewport widgets or parms would benefit little. Likewise, it would not make much sense to look through them in the first place as doing so in practice is usually to aim the light and to view what the light ‘sees’. However, as you are permitted to look through indirectlight, we will build in the ability to match them for completeness, although this will be flagged off by default.
Environment lights only have rotation parms. In the case of a hemisphere this may be particularly useful as well as ” to orient directional illumination.” But, quick use of these unrotated will result in all coming up positive matches, as their transforms will all be identical and in practice it is less than useful to aim the light by looking through them, although the ability is present. Therefore they are flagged off by default and not considered although they can be flagged on.
About Portal and Skylight
Portal Light and Sky Light are special cases of envlight that drop two top level nodes.
Skylight drops a envlight named “skylight” and also an hlight named “sunlight” — the reason for this setup is not %100 clear, but it is what it is, so it needs to be dealt with it the scripts. There’s a viewer widget attached to the hlight that allows the translation of the sun, but not rotation. The rotation comes from the envlights Sky Environment Tab –> Sun Tab –> Rotate Parms. Changing these results in visible changes to the sun widget on the accompanying node. However, selecting the envlight node shows the viewer widget for rotation, but as per normal rotates the envlight dome a previously mentioned. Yikes! Fortunately when left unrotated, false positives are avoided on the dome by leaving envlights flagged off. The rotation of the map will still be taken into account via the channel linking to the “sunlight” hlight node, which to be useful would need to be translated away from the origin,and the combo of these two things should produce a unique transform. As, hlights are considered by default, and “sunlight” is still of type hlight there should be usable results by testing against this nodes transform matrix.
Portal Light as provided by the shelf and TAB menus is basically a shortcut to create an envlight with the portal geometry per-assigned. The geometry then restricts the envlight so that it only passes through the assigned object. We can flag on to consider envlights, but the transform that actually is restricting is that of the objects assigned which is arbitrary, so can’t be considered, and additionally can not be looked through Considering envlight will also consider those used for portal light and may not produce the result expected as the envlight it self, as mentioned is at the origin and not useful to look through.
Hopefully this section provided a good overview of the relationship between the lights as depicted via the shelf/TAB menu and their actual type, as well as the default arg flags as will be used in the narrowed function calling the more general viewportObjectsOfType() to be explained in an upcoming post.
Next, a closer look at cameras and their relationship to the viewport.