Blender lighting management skill.
Lighting detail
create_light and set_light_properties cover the basics. These cover the rest:
per-object control and real-world light distribution.
| Tool | Description |
|---|---|
set_light_linking |
Restrict a light to a receiver collection, with an optional blocker collection |
set_light_ies |
Shape a light with an IES photometric profile, or remove one |
Light linking
It is version dependent and does not silently no-op:
- Light linking lives on the object, as
Object.light_linking, not on the light data block. Objects that expose no such property are refused with that reason instead of writing to a property that does not exist. - Both collections are resolved before either is assigned, so a missing collection cannot leave the light half-linked.
- It affects Cycles and EEVEE Next and does not change the light's energy.
IES profiles
set_light_ies attaches a photometric file to a light. Blender has no
Light.ies_file property, so this is not a property assignment: it builds a
ShaderNodeTexIES in the light's shader tree and wires its Fac output to the
emission node's Strength input.
Three things decide whether the profile actually reaches the render, and all three are verified by reading the tree back rather than assumed:
- The node must drive the emission node the renderer reads. A light tree can
hold several emission nodes; only the one feeding
ShaderNodeOutputLightlights anything, so the link is traced back from the output rather than taken from the first match. - The profile file must exist. Blender accepts a path it cannot open and then renders the light unshaped, so the path is checked before it is used and a missing file is refused.
- The
Vectorinput is left unconnected. The renderer resolves the profile direction from the light itself; connecting a geometry direction there mis-aims the beam.
Version handling is explicit, not a hasattr guess: a build below the supported
baseline, or one that cannot create the node type, is refused with that reason
instead of reporting success.
The 4.5 floor is the adapter's support window, not an IES requirement —
ShaderNodeTexIES predates 4.5 by years. It is checked first only because a
refusal naming the supported window is more actionable than one naming an
obscure node type; the real gate is whether the build can create the node.
A light whose output is driven by something other than an emission shader (a
Mix Shader, say) is also refused. IES drives an emission node's Strength, so
with no emission node on the output there is nowhere to attach it that the
renderer would read — wiring an orphan instead would report success for a light
that renders unshaped.
Photometric files are read as supplied. Two file-level details change the result and neither is reported by Blender, so they are worth knowing when a profile renders as nothing:
- A file with a single horizontal angle gives Blender a zero-width horizontal range and reads as black in every direction. Rotational symmetry has to be expressed by repeating one vertical distribution across all horizontal angles.
- Photometric type B rotates the frame, so the beam stops following the lamp's aim. Type A and C files keep the profile aligned with the lamp.