wrong light groups with OpenCL

[FarbigeWelt]

Unfortunately Blender itself doesn't allow this https://github.com/LuxCoreRender/BlendL ... issues/167

There seems to be a workaround.

I have solved applying the result directly from the driver script: that is not the best solution but it is working.

Attached you can find a working example:
LuxCore-Drivers.blend


Thank you,
Rickyx

ps. nice discovery: if you remove the constraint and move empty over 1 value you get an emitter from matte node

[pixel_peeper]

I can reproduce this at the 128 samples you set in the file, even with OpenCL CPU device (to eliminate possible driver issues). There might be a bug in the OpenCL code.
Have you tried higher sample numbers (something like 1000)?

No, because it takes too much time and I need to finish this shot anyway thanks for testing it!

[pixel_peeper]

There seems to be a workaround.

I have solved applying the result directly from the driver script: that is not the best solution but it is working.

Attached you can find a working example:
LuxCore-Drivers.blend


Thank you,
Rickyx

ps. nice discovery: if you remove the constraint and move empty over 1 value you get an emitter from matte node

that's funny, rickyx is actually my colleague! I'm not expert as him with drivers and scripts but if I remember well we ended up using light group because it's far more easier to adjust the emission with graph editor and the various interpolation modes.
Now I've copied the keyframes of the light groups to the compositor and if I did everything right I can get a nice result mixing LuxCore and Cycles, at least I hope!

[rickyx]

Yes, my desk is actually less than 2 meters away from the one of pixel_peeper. But now I'm away and he is on his own...

The script cited by FarbigeWelt is ok and has already been tested but it is not user friendly (...specially if you can't write python).

My question now is: samples are allocated in relation to power of light, gain of light, light groups or what? Which of these values is taken into account?
In this case it would have been useful for the groups of lights to contribute to the allocation of samples.

Thank you,
Rickyx

[Dade]

My question now is: samples are allocated in relation to power of light, gain of light, light groups or what? Which of these values is taken into account?

It depends of the selected light strategy: for "POWER" (the one used in the scene), they are allocated according light source power (for "LOG_POWER", the default strategy, according log(1+power) so a very strong light source don't get all samples)

[B.Y.O.B.]

My question now is: samples are allocated in relation to power of light, gain of light, light groups or what? Which of these values is taken into account?

Gain, color, power and efficacy settings of the light are taken into account by any light strategy other than "uniform":
viewtopic.php?f=4&t=942#p10608
However, light group settings (gain, color) are NOT taken into account for sampling probability.

In theory you could set the light strategy to uniform and use the importance parameter of the light emission node to control the sampling probability.
But in your case this is probably not possible because you would need to animate it, right?

[B.Y.O.B.]

I think this feature could help you: https://github.com/LuxCoreRender/BlendL ... issues/101
During export, I would apply the light group's gain/color/temperature settings to the individual lights, solving the under/oversampling problem. The lightgroups would be exported with default gain/color/temperature settings (gain 1, white color), so you would still have them as separate AOVs in the compositor.
If this sounds useful to you, I think I could implement this fairly quick.

[Dade]

In this case it would have been useful for the groups of lights to contribute to the allocation of samples.

It is intentionally not taken in account: if you use light groups, you are going to change their intensities after the rendering, taking into account their intensities during the rendering is a wrong idea (because it is going to change).

The optimal setting is using a light intensity for the lights, during the rendering, equals to the average value you are going to use after the rendering.

Otherwise, you may start to have problems with floating point precision (and you can still have) if the intensity ranges are big.

[kintuX]

Forward Path seems not suited for this. Check render @ ~160k samples

Oppose to bidir, metropolis, uniform, OIDN, 128 samples (beware the lack of gif quality)

[Dade]

Oppose to bidir, metropolis, uniform, OIDN, 128 samples (beware the lack of gif quality)

It is not surprising if the light sources are hidden inside some matte translucent material.