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:


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.


@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.


Hey @chafouin and @smilebags. This is great information, thank you. It looks like LuxCore has a bunch of features that can alleviate my issues - specifically around setting correct values for high dynamic range scenes and actually getting real irradiance values out of renders (since LuxCore has an Irradiance render pass). Super, super useful.

If LuxCore can manage to translate all that stuff to EVEE, it means I can do my dirty mathy work inside of LuxCore and then have it translate over to real-time scenes automagically. Maybe. Neat.

And the Photographer addon gives me EV, nice.

In my own attempt to plug in real world values, here’s what I’ve tried.

Because we only need the radiant flux, I’m pretty sure we can work backwards to get to lumens since we know the luminous efficacy of R, G, and B. It’s not going to be totally accurate like Troy said in the other thread, especially if you plug in an extreme color, but for sticking in light bulb values found online it seems to be reasonably close and matches the values expected by the Photographer addon.

Doesn’t work in Eevee, but it shouldn’t be that hard to do the same conversion via python so that it can. I’ll try to give that a shot.

Oh, and around 1000 watts per square meter for direct sunlight seems to be right on. I don’t think a conversion to lux would be helpful since we’re not dealing with very saturated colors.


Looks very interesting @jonlampel. Would you mind breaking down the math you’re using in the first screenshot?

As for the sun, how are you ascertaining that value? According to this one can multiply lux by .0079 to get W/m^2 (for the sun in particular) which would yield around 978 W/m^2 for 120k lux sunlight, about as bright as direct sunlight commonly gets. Were you referring to that or using the Photographer addon to guesstimate based on EV?

The reason it might be useful to use lux in the case of the sun is that it’s easy to obtain measurements for yourself for sunlight in lux using an illuminance meter, but confirming luminous values is much more difficult for obvious reasons.

1 Like

Sure! I’m not 100% sure that I did it right, so I’d love to have another pair of eyes.

I used this set of equations from here:


We want to plug in lumens and get out radiant watts, so we have:

radiant watts = lumens / [ luminous efficacy * 683 ]

To get the luminous efficacy, I separated out the R G and B channels and used the values in this table here based on the wavelengths of red, green, and blue light. Then I averaged the RGB values back together and used that to divide the lumens by.

That last part is where I think I might be off, since I just averaged the values instead of doing anything with spectral power distribution or chromacity. I’m not sure that’s even possible though, given how Cycles isn’t spectral.

Yeah there might be some slight issues with using values from that chart to represent the luminous efficacy of an sRGB colour since the primaries aren’t spectral, you’d need to find the luminous efficacy of a spectrum which represents the sRGB primaries. Happy to supply some if desired but I feel like what you have is a good enough approximation considering the rest of the system.


@polyrhythm Oh, and the sun value of 1,000 W/m^2 is just one that I’ve seen repeated a lot in different sources. I’d have no idea how to measure it myself. It makes sense why you’d want to do that!'s%20Energy.aspx

@smilebags Is that something you’d need to know anyway for your spectral Cycles project? I’d be interested in trying those values to see if they would make it work with bright neon colors, but if it’s a PITA to calculate then I wouldn’t worry about it.

I gave these ratios from Wikipedia a shot instead of using the guesstimated wavelength and they seem to work better with super saturated blues and reds.

It makes the lumens conversion brighter than before, but it still seems to be within the right range and I’d rather err on the side of too bright than too dark.

@chafouin, that file above has a bunch of different lights that are based on real world lumens, temperatures, and sizes. I’d be curious to know if they line up with what you’ve set your lights to be at for your addons if you have a second to check.

Would you be interested in beta testing it? I can send you a version.

Yeah! Though if it’s the same as what’s on Gumroad, I can just buy it there if you’d prefer.

Fortunately for me I don’t have to worry too much about this if I was to support it. I don’t think it would be too hard to figure out. It still won’t be perfect since there’s still a bunch of guesswork and hand-waving to get spectra from RGB, but it’d be close enough, I imagine. I’ll give it a try in the next week some time.

1 Like