wrong light groups with OpenCL

Use this forum for general user support and related questions.
User avatar
FarbigeWelt
Donor
Donor
Posts: 576
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: wrong light groups with OpenCL

Post by FarbigeWelt » Wed Mar 06, 2019 5:29 pm

pixel_peeper wrote:
Wed Mar 06, 2019 4:52 pm

Unfortunately Blender itself doesn't allow this https://github.com/LuxCoreRender/BlendL ... issues/167
There seems to be a workaround.
rickyx wrote:
Tue Sep 25, 2018 9:47 am
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 ;)
160.8 | 42.8 (10.7) Gfp / Windows 10 Pro, intel i7 4770K@3.5, 32 GB | AMD R9 290x+R9 390x, 4 GB
17.3 | 19.0 ( 4.7) Gfp / macOS X 13.6, iMac 27'', 2010, intel i7 870@2.93, 24 GB | ATI Radeon HD 5750, 1 GB
#luxcorerender | Gfp = SFFT Gflops

User avatar
pixel_peeper
Posts: 13
Joined: Mon Mar 04, 2019 7:45 pm

Re: wrong light groups with OpenCL

Post by pixel_peeper » Wed Mar 06, 2019 10:46 pm

B.Y.O.B. wrote:
Wed Mar 06, 2019 5:27 pm
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!

User avatar
pixel_peeper
Posts: 13
Joined: Mon Mar 04, 2019 7:45 pm

Re: wrong light groups with OpenCL

Post by pixel_peeper » Wed Mar 06, 2019 10:54 pm

FarbigeWelt wrote:
Wed Mar 06, 2019 5:29 pm
There seems to be a workaround.
rickyx wrote:
Tue Sep 25, 2018 9:47 am
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 ;)
:D :D 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!

User avatar
rickyx
Posts: 17
Joined: Sun Apr 29, 2018 5:23 pm

Re: wrong light groups with OpenCL

Post by rickyx » Thu Mar 07, 2019 10:16 am

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

User avatar
Dade
Developer
Developer
Posts: 2388
Joined: Mon Dec 04, 2017 8:36 pm

Re: wrong light groups with OpenCL

Post by Dade » Thu Mar 07, 2019 10:43 am

rickyx wrote:
Thu Mar 07, 2019 10:16 am
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)
Support LuxCoreRender project with salts and bounties

User avatar
B.Y.O.B.
Developer
Developer
Posts: 2506
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: wrong light groups with OpenCL

Post by B.Y.O.B. » Thu Mar 07, 2019 10:45 am

rickyx wrote:
Thu Mar 07, 2019 10:16 am
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?
Attachments
2019-03-07_11-56-21.png
Support LuxCoreRender project with salts and bounties

User avatar
B.Y.O.B.
Developer
Developer
Posts: 2506
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: wrong light groups with OpenCL

Post by B.Y.O.B. » Thu Mar 07, 2019 11:25 am

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.
Support LuxCoreRender project with salts and bounties

User avatar
Dade
Developer
Developer
Posts: 2388
Joined: Mon Dec 04, 2017 8:36 pm

Re: wrong light groups with OpenCL

Post by Dade » Thu Mar 07, 2019 11:51 am

rickyx wrote:
Thu Mar 07, 2019 10:16 am
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.
Support LuxCoreRender project with salts and bounties

kintuX
Posts: 314
Joined: Wed Jan 10, 2018 2:37 am

Re: wrong light groups with OpenCL

Post by kintuX » Sat Mar 09, 2019 12:01 pm

Forward Path seems not suited for this. Check render @ ~160k samples
Path160k.jpg
Oppose to bidir, metropolis, uniform, OIDN, 128 samples (beware the lack of gif quality)

Image

User avatar
Dade
Developer
Developer
Posts: 2388
Joined: Mon Dec 04, 2017 8:36 pm

Re: wrong light groups with OpenCL

Post by Dade » Sat Mar 09, 2019 12:12 pm

kintuX wrote:
Sat Mar 09, 2019 12:01 pm
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.
Support LuxCoreRender project with salts and bounties

Post Reply