Using a photometric-based workflow for lighting

I’ve been trying to wrap my head around Blender’s lighting model. Specifically how it relates to real world units. The large piece I’m seeming to miss is how to validate a test scene to ensure that in-engine units correspond to real-world units.

For starters, the only currently-supported unit type in EVEE is watts. That’s fine and all, but it does make validation difficult, as I really need to convert that into an actual luminance unit like lumens or candelas, and the math to go between them involves multiplying the watts by luminous efficacy. If I assume a typical incandescent light bulb has an efficacy of between 2% and 5%, I can do something like:

watts * 683 (maximum possible luminous efficacy) * actual efficacy (varies by light type)
watts * 683 * 0.02

That gets me lumens. Great, now I can go between lumens, candelas (lumens/4Pi) and watts. The problem is that if I want to specifically assign a luminous power, I can’t, because I’m assuming what the efficacy is - I can’t directly assign it, by, say, telling Blender what kind of light it is. It’s total guesswork. There’s no point in using watts if I can’t tell Blender how efficiently those watts are turning into luminous power.

Second problem. The camera doesn’t use EV for exposure. So not only can I not tell what the luminous power of my light sources are, I also can’t expose by eye because I have no real-world exposure to mess with. There is basically no way to light photometrically that I can see with EVEE at the moment. And that’s a problem for scenes that need to balance high dynamic ranges - outdoor lighting combined with artificial lights, for example.

More random problems:

  • The sun has no “lux” unit so I can’t set it to real world values
  • The skylight has no luminance (cd/m^2) exposure - again, can’t use real world sky luminance
  • No in-engine lux/nit validation tool to see what values are actually happening on the render buffer. The best I can do is do a render and look at pixel values and guess at what they correlate to, hoping they weren’t transformed in some way.

A benchmark I’d like to do is placing a single, one candela point light, one meter above a diffuse white surface, and see if I get one lux of illuminance on the surface, but I can’t get anywhere near a validation scene like that with the above problems.


I’d just like to add that I would also like an explanation about this. +1

1 Like

I am a lighting artist and work in the game industry with real time engines. This lighting workflow is not specific to scientific pursuits. Both UE4 and Unity offer photometric lighting pipelines in their more recent versions, and this will only get more common as virtual production takes over the movie industry…

I think I see watt your problem is. :wink:

Starting from the third sentence of your wiki link:

Depending on context, the power can be either the radiant flux of the source’s output, or it can be the total power (electric power, chemical energy, or others) consumed by the source.

Watts in Blender are the radiant flux that the light is outputting.

Which sense of the term is intended must usually be inferred from the context, and is sometimes unclear.

Not really your fault for not knowing this, as watts in everyday usage typically refers to the total power consumed by the source.

The former sense is sometimes called luminous efficacy of radiation , and the latter luminous efficacy of a source or overall luminous efficacy .

Since Blender is using the radiant flux, there is no need to multiply the luminous efficacy of radiation by a luminous efficiency term in order to get the overall luminous efficacy.

Hope that helps! :slightly_smiling_face:

1 Like

See Why Watt as light value? for additional information.

Interesting! Thanks for those links. I still feel like it’s a cop out! Other industry-standard render engines are using photometric pipelines and even have backing pathtracer implementations which work as expected from a lighting standpoint. In the real world, lighters use photometric sensors to measure light output. In movie virtual production, lighters need to mix virtual photometric lights with real photometric lights.

In a few days I will go back into Blender and, acting as if watts are just radiant flux, attempt to make a validation scene of a single point light above a white surface to see what the heck is going on inside the engine. The lack of a in-engine light sensor, real camera EV, and having arbitrary measures of power for other light sources will make it more of an exercise in curiosity than anything approaching comprehensive though.

In an effort to be more convincing, here are some other engines using photometric pipelines:

One poster in the other thread stated that photometric values have no place in a pathtracer. While I can understand the viewpoint, it’s a bit like being an ostrich with their head in the sand at this point. That ship has sailed - lighting artists want to use units they use in a real-world context, and render engines have adapted by figuring out how to get intuitive and internally consistent photometric values into their real-time and pathtraced implementations.

Stuff you can do if you did have a photometric setup:

  • Validate your own engine! Take an HDRI with known light conditions using an illuminance meter, calibrate it in-engine, and then place physical items in the room, photograph them, model them, and compare the digital render with the photograph
  • Validate the engine against known light values with an in-engine luminance/illuminance meter
  • Quickly baseline scene light settings with appropriate values. Particularly for outdoor scenes with high dynamic range, this is almost impossible right now? (How do I get the sun’s illuminance balanced against sky luminance and an artificial light source? Tweak by eye and watch your magic numbers break when introducing more lights!)
  • Drop-in IES lights

Okay I’ll stop now. Please consider it, devs.


This is a real issue which I’ve noticed for a long time. If there is some sort of internal consistency it isnt very well presented.

@polyrhythm it is worth checking out the Photographer addon and the other addon by the creator about physically based lights and environments, they all have consistent white balance and use consistent brightness units for both the environments and light objects he sells. I’ve found @chafouin very approachable so it might be worth your time to try to ask him about his understanding of the situation.

1 Like

@polyrhythm @smilebags
I agree with the “ostrich with their head in the sand” analogy, this is why I just added Physical units to LuxCore render (coming in 2.3), and will be adding them to the Photographer add-on really soon.

It might not be 100% correct, color luminance normalization might not be 100% accurate for photometric, I understand why some people want to keep it to radiometric. But it won’t be worse than any other engine currently using them. Most of them don’t even support luminous efficiency at all.