LuxCoreRender Forums

As Mango3 said, until the Python API is declared stable I won't start the 2.8 port, as it would be a waste of time to code for a changing API.

Mango3 wrote: Fri Nov 02, 2018 1:00 pm

if there is at any point any experimental version of blendluxcore for 2.8 then let me know

I cannot speak for the developers, just try to explain why plug-in developers prefer to wait before they start working on the new Blender version. Blender 2.8 beta is not yet out and the Python API and documentation to it needs to be finalized first. Blender 2.8 will be released officially beginning of next year, so there is still some time left.

On GitHub you can follow the status on the issue tracker:
https://github.com/LuxCoreRender/BlendL ... issues/166

Oh I was already told by B.Y.O.B. that he's waiting for the API to be finished. Just letting him know I volunteer to an early experimental version whenever it is ready

@B.Y.O.B.: forcing TILEPATH AA to 1 when using the denoiser is killing the performance because of too light work for each tile. I have added the support for BCD plugin ".warmupspp" property so you can set the average sampler per pixel threshold to end the warmup.

The default values is 2.0 (note: it is a float). When using TILEPATHCPU/OCL it should be set to "AA * AA - epsilon". For instance if you are using a tile AA of 5, it should be set to something like "5 * 5 - 0.1" = 24.9.

Does this work with multipass disabled?
I just did a render with 7 AA samples, warmupspp = 48.9, and the denoiser did not do anything after the pass was done.
Should I use a larger epsilon, or is it necessary to render multiple passes?

B.Y.O.B. wrote: Sat Nov 24, 2018 11:14 am Does this work with multipass disabled?
I just did a render with 7 AA samples, warmupspp = 48.9, and the denoiser did not do anything after the pass was done.
Should I use a larger epsilon, or is it necessary to render multiple passes?

During the warmup period no statistics is collected so the denoiser is basically running without any data if we do a single pass. So, at least we need 2 passes (1 as warmup and 1 to collect the bare minimum data).

The is probably the right condition to use, if denoiser and TILEPATH, set:

....warmupspp = "AA * AA - 0.1"
batch.haltspp = Max("2 * AA * AA - 0.1", <user value>)

Done: https://github.com/LuxCoreRender/BlendL ... 6561df2f0b

Thanks for updates.

Tested Tilepath with denoiser & behavior feels much better, stable and predictable.
But now, tile size really matters!

A (default) | GPU (GTX 1060 6GB): Tile size = 64 ---> Render time for 100 samples @ 1080p = 11:27.23 (685.23 s)
B (custom) | GPU (GTX 1060 6GB): Tile size = 256 ---> Render time for 100 samples @ 1080p = 03:15.13 (195.13 s)

speed ratio A : B = 3.5219 : 1


Problem arises when combining GPU & CPU, since hybrid rendering gives almost no advantage anymore, as is with official Cycles - while nightly got this fixed (small tiles using GPU are as fast as larger).

Can't remember exactly but I was under the impression the tile size didn't make that much difference before... So is this normal behavior for now and is there any bypass (except from separate renderings) or are any optimizations planned?

kintuX wrote: Sun Nov 25, 2018 2:35 pm Tested Tilepath with denoiser & behavior feels much better, stable and predictable.
But now, tile size really matters!

A (default) | GPU (GTX 1060 6GB): Tile size = 64 ---> Render time for 100 samples @ 1080p = 11:27.23 (685.23 s)
B (custom) | GPU (GTX 1060 6GB): Tile size = 256 ---> Render time for 100 samples @ 1080p = 03:15.13 (195.13 s)

speed ratio A : B = 3.5219 : 1

Try to increase tile AA: you can increase tile size but it has a couple of drawback, it is usually a lot better to just increase AA (even moving from 3 to 5 can make a huge difference: 25 samples per pixel instead of 9, nearly 3 times more work).

Dade wrote: Sun Nov 25, 2018 3:15 pm

kintuX wrote: Sun Nov 25, 2018 2:35 pm Tested Tilepath with denoiser & behavior feels much better, stable and predictable.
But now, tile size really matters!

A (default) | GPU (GTX 1060 6GB): Tile size = 64 ---> Render time for 100 samples @ 1080p = 11:27.23 (685.23 s)
B (custom) | GPU (GTX 1060 6GB): Tile size = 256 ---> Render time for 100 samples @ 1080p = 03:15.13 (195.13 s)

speed ratio A : B = 3.5219 : 1

Try to increase tile AA: you can increase tile size but it has a couple of drawback, it is usually a lot better to just increase AA (even moving from 3 to 5 can make a huge difference: 25 samples per pixel instead of 9, nearly 3 times more work).

Thank you. A-OK.

For anyone interested, stats based on Halt time limit (60s) attached

Dade wrote: Sun Nov 25, 2018 3:15 pm Try to increase tile AA: you can increase tile size but it has a couple of drawback, it is usually a lot better to just increase AA (even moving from 3 to 5 can make a huge difference: 25 samples per pixel instead of 9, nearly 3 times more work).

More Tilepath SPP stats. This time, hybrid rendering up to 100 samples.
-------------------------------------------------------------------------------
And possible bugs? IDK, i think, maybe...

0. Suggested Clamping Value has become useless. It's way off (millions over than what appears to be needed for clean render). No matter of Sampler (Light Strategy).

1. With Tilepath OCL in hybrid mode, CPU vs GPU show difference in clamping.
CPU starts to leave fire flies behind. Starting with SPP value of 2 (most prominent with/on Glossy material)
Lowering Value seems fine.

2. With Halt Conditions set, using 10 SPP and above always results in unfinished render (Black Tiles). From statistics it looks as the condition is met but the result isn't there (I think B.Y.O.B. mentioned this already):