LuxCoreRender Forums

Hi all,

if you really think about a rework of the light source input please use lumen [lm] for all light sources except the ambient ones (sky,sun,hdri).

The lumen unit is directly handling the brightnes over color issue due to integrated human eye spectral sensitivity (v(lambda))
It's also photometrical and physics based and can easily be set according to real world lamps and luminaires. Most of them have a note of lumen output on their packaging.

Also let's not forget than Physical units are also user-friendly
If you want you area light to maintain its brightness independently of its size, use candela/m2 (a.k.a nits). If you don't, then use candela.
If you want your spotlight to maintain its brightness independently of its size, use candela. If you don't then use lumen.
Lumens are great for pointlights as these values are well-knowns on lightbulb packages, and are based on human perception.
If you want to use radiometric and ignore human eye color sensitivity, then use Power and Efficacy.

1. You can't define a lumanince variation if you simply set an cd/m^2 value for area lights. But a lumen + IES file could do.
2. A single candela value will create an even light distribution for a spot light. Variation is possible with having lumens + IES or maybe lumens + spread angle + falloff.
3. Pointlight in lumen as already mentioned

For the ambient sources you could maybe think about this.
Sun and skies should get something like a scale value. but keeping this at 1 (100%) should deliver natural high luminance values.
For the single color and hdri ambient sources maybe a fixed luminance (cd/m^2) value could be applied. This value should be applied to the brightest (whitest) pixel on the image. That should allow us to work with realistic lighting conditions.

Hope some of this will find it`s way into luxcore.

BR.

Thank you for your input!

lighting_freak wrote: Sun Dec 15, 2019 9:39 pm 1. You can't define a luminance variation if you simply set an cd/m^2 value for area lights. But a lumen + IES file could do.

Adding these units won't remove the possibility to have luminance variation using IES files or HDR textures. Nits it's just another nice option for area lights as screens brightness is measured in nits (250 cd/m^2 is the default setting of your PC monitor, consumer HDR TVs can reach max peak luma of 1400 nits, etc...)

lighting_freak wrote: Sun Dec 15, 2019 9:39 pm 2. A single candela value will create an even light distribution for a spot light. Variation is possible with having lumens + IES or maybe lumens + spread angle + falloff.

Same here, the candela unit will just define the intensity of the spotlight at its center, like it is currently with Power. It won't remove the spotlight angle and fallow. The only difference with lumen is that it will keep its brightness independently of the spotlight angle (I said size earlier, I meant it as angle, not light source size).

lighting_freak wrote: Sun Dec 15, 2019 9:39 pm Sun and skies should get something like a scale value. but keeping this at 1 (100%) should deliver natural high luminance values.

Yes! I want to keep that as well.

lighting_freak wrote: Sun Dec 15, 2019 9:39 pm For the single color and hdri ambient sources maybe a fixed luminance (cd/m^2) value could be applied. This value should be applied to the brightest (whitest) pixel on the image. That should allow us to work with realistic lighting conditions.

That sounds like a bad idea to me. Imagine you have a sunset sky with one little street lamp in the background that you didn't notice...
HDRI images should be created using absolute values that works with tonemapper camera settings, and the default Gain of 1 should give your realistic results.
When using single color, I would recommend using lux.

The most important is to give artists the choice, and to clearly communicate what the unit is and when to use it

Hi,

You are totally right. Of course it's possible to create those variations with other sets of units. I was just thinking about a single identical interface that works for all light sources in the same way.

My approach makes me a bit blind for other points of view. Regarding area lights I wasn't thinking of creating directly a display. For this a direct input of cd/m^2 might be easiest. In my world area and mesh sources always represent only the lot up element of a light source (the tungsten wire of bulb or the chip surface of a LED) that's the reason for the pure lumens input.

chafouin wrote: Mon Dec 16, 2019 3:39 am That sounds like a bad idea to me. Imagine you have a sunset sky with one little street lamp in the background that you didn't notice...
HDRI images should be created using absolute values that works with tonemapper camera settings, and the default Gain of 1 should give your realistic results.
When using single color, I would recommend using lux.

Totally agreed in case that you are sure that you have right absolute values behind the HDRI.
But what happens if you don't know about the absolute values? With setting of the brightest point to a specific luminance value at least a little real world link remains... well in GUI it could be a checkbox like "use absolute values from map"

Looking forward to your feedback

BR

I have submitted a patch adding new light units, however while working on it I discovered some "issues".

- The Spotlight cone falloff affects the intensity of the light by focusing or spreading it, instead of just acting as a mask. This made it hard to validate light brightness between different light types, as a spot blend value of 1 makes the light brighter at the center of the cone.

- A spotlight with a 180 cone angle and a blend of 0 seems to break physical quadratic light falloff. It should have the same render as a half point light, but it lights much further.

- The Area light supports a spread angle but didn't properly adjust brightness according to the angle when using Power, like spotlights do. When adding support for this, I noticed that by default, the area lights are brighter than other lights of similar power, which is incorrect. I added a conversion to keep the same look as in 2.2. However, doing so breaks the math between lumen and candela and I would prefer to break backward compatibility and fix this properly.

chafouin wrote: Mon Feb 17, 2020 8:00 pm - The Spotlight cone falloff affects the intensity of the light by focusing or spreading it, instead of just acting as a mask. This made it hard to validate light brightness between different light types, as a spot blend value of 1 makes the light brighter at the center of the cone.

- A spotlight with a 180 cone angle and a blend of 0 seems to break physical quadratic light falloff. It should have the same render as a half point light, but it lights much further.

It might be worth to look into the LuxCore code regarding this, maybe it can be fixed?

chafouin wrote: Mon Feb 17, 2020 8:00 pm - The Area light supports a spread angle but didn't properly adjust brightness according to the angle when using Power, like spotlights do. When adding support for this, I noticed that by default, the area lights are brighter than other lights of similar power, which is incorrect. I added a conversion to keep the same look as in 2.2. However, doing so breaks the math between lumen and candela and I would prefer to break backward compatibility and fix this properly.

Break all the stuff for v2.3, it is the one release where it's ok. Afterwards I would like to keep everything stable for a while (i.e. a year or so) again.

B.Y.O.B. wrote: Mon Feb 17, 2020 8:39 pm Break all the stuff for v2.3, it is the one release where it's ok. Afterwards I would like to keep everything stable for a while (i.e. a year or so) again.

I'd like to get Dade's opinion on that one. I think LuxCore assumes that the area light emits in a 90 degrees cone, while to me it should assume it emits in a 180 degrees cone. Thinking a bit more about it, it's not "incorrect", but probably confusing.

chafouin wrote: Mon Feb 17, 2020 8:45 pm

B.Y.O.B. wrote: Mon Feb 17, 2020 8:39 pm Break all the stuff for v2.3, it is the one release where it's ok. Afterwards I would like to keep everything stable for a while (i.e. a year or so) again.

I'd like to get Dade's opinion on that one. I think LuxCore assumes that the area light emits in a 90 degrees cone, while to me it should assume it emits in a 180 degrees cone. Thinking a bit more about it, it's not "incorrect", but probably confusing.

LuxCore emits in a 180 degree around the normal, notice the CosineSampleHemisphere() in the triangle emit light function: https://github.com/LuxCoreRender/LuxCor ... t.cpp#L105

However it emits with a cosine distribution to optimize the sampling (in case you were mislead by the PI factor we were talking by PM).

I think I've been barking up the wrong tree. I notice the problematic difference in brightness even without my new per unit angle correction, so it's probably not that. This might be coming from the previous fix we did, but I'll continue to investigate.

B.Y.O.B merged the new light units patch, feel free to send feedback if you notice anything weird

chafouin wrote: Wed Feb 19, 2020 4:01 pm B.Y.O.B merged the new light units patch, feel free to send feedback if you notice anything weird

Is there any still (known) issue ? I mean, the v2.3 looks pretty much done and the next release may be a RC1.