Light intensities and matching Cycles

[Dade]

The problem may be in BlendLuxCore, it seems to set the "gain" value with the "color" for spot lights

Just export the scene and check the properties, they seems to show this problem. This behavior clearly breaks all the above discussion.

[Dade]

The problem may be in BlendLuxCore, it seems to set the "gain" value with the "color" for spot lights

It looks like BlendLuxCore multiply the scalar gain for the color and export everything as a gain value.

[chafouin]

Okay this is good news then, I can try to fix it in the add-on. I'll have a look at it later today! Thanks.

[B.Y.O.B.]

Hi,

most of the information in this thread is news to me
It would be great if you could rework how this is done in BlendLuxCore.

The main file of interest is https://github.com/LuxCoreRender/BlendL ... t/light.py
I used the "gain" property everywhere because not every light has a "color" property (e.g. sun, sky) but every light has a "gain" property, so it was simpler to just use "gain" for every light. I did not know that LuxCore would take a different code path when "gain" is set, this should probably be mentioned in the documentation.

When we rework this, we could in the same breath switch to Cycles/Eevee light properties and aim for compatibility with them, so switching between engines becomes more seamless. We would probably have to do some unit conversions or multiplying with factors behind the scenes, but it should be possible (I think). Area lights with its differing behaviour between Cycles and Lux might be a problem, though.

We could still offer a physically correct "LuxCore light settings" mode based on color, power and efficacy, but it should not be the default.

What do you think?

[chafouin]

I would be happy to help you with that. I am about to move to the other side of the world, my schedule is a bit chaotic at the moment, so I don't want to commit to a specific deadline, but I'll definitely do it.

There are several things that I would like to do:
- Adding Luminous Efficiency weighting to Gain, and remove it from Power (right now it is the other way around)
- Adding several units support. Since the Color Luminance Weighting is already there, we can support human's perception units like Lumen, Candela, Lux, Nits.
- Convert the Sun Gain to output W/m2 instead of Lux (lm/m2), this would also mean adding an offset to the tonemapper to compensate for that. This way we can remove Luminous Efficacy and match Cycles easily.
- Or the other way around: assume a certain default Luminous Efficacy (179lm/W if Radiance can be a reference, or 683lm/W if we assume the max efficacy to be ideal) and change the default Tonemapper values.

I also want to use a 3rd renderer as a reference, probably Octane as it is free. That way we get proper redundancy, but also because Cycles only supports Power and can't be 100% trusted

[marcatore]

@BYOB and chafouin
Great!
I hope you'll find a way to collaborate. I'm feeling that will have a good light setup options.
I really like the idea to work with "real" world numbers cause, for my experience and kind of job, it's the easier and fastest way to setup a scene as lighting.

Obviously an "artistic" way of setup is needed so I really appreciate an "advanced" mode to activate so everyone will be happy to choose what fits best for him/her.

Nice plan!

[chafouin]

I would be for replacing Gain with Exposure the way it works in Arnold and Renderman. It should be a photometric value (i.e. keeping same brightness independently of color), maintain brightness independently of light size, and use base-2 logarithmic scale. That way you get something that is really artist driven.

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.

[neo2068]

@BYOB and chafouin
How is the progress on this topic?
Also, the emission material is affected and should be adapted to the new export scheme.
https://github.com/LuxCoreRender/BlendL ... mission.py
I can assist with the implementation if there are any problems.

[chafouin]

@neo2068 Thanks for fixing the color / gain issue that I reported earlier. I noticed a bug when using a light with a Power of 0 would still emit light.
I have a fix for it but... I don't understand how GitHub works. Do you all work on your own fork to be able to Pull request, or do you work directly on the BlendLuxCore repository? I can't push my changes if I do so (I don't have permissions, and I'm totally ok with that, I don't want to commit without review), but keeping my fork up to date and pull requesting only the files that I want to push is a nightmare.

I would really like to get Power/Efficiency not normalized in LuxCore first, because this is a radiometric unit and this won't match Cycles.
Normalization should be kept for photometric units.

[Dade]

Do you all work on your own fork to be able to Pull request, or do you work directly on the BlendLuxCore repository?

Only members of the project can directly push to the BlendLuxCore repository (https://github.com/orgs/LuxCoreRender/t ... rs/members), an occasional push is usually handled with a pull request instead.

You usually open a branch and work on specific new feature than you create a pull request from there (https://gist.github.com/Chaser324/ce0505fbed06b947d962).