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:
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 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…
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.
Capcom’s internal render engine (no public docs, but this is what I work with)
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!)
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.
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.
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.
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.
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.
@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.
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.
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.