LuxCoreRender Forums

I think to know what it is, it is also quite visible if you compare Cycles and LuxCore rendering. I think this has also already been discussed on the past.

The root of the problem is the initial RTPATH setting for resolution: it is clear from the video that Cycles start rendering with blocks large as about 32x32 while Lux uses 4x4 (1 samples every 32x32 pixels Vs 1 samples every 4x4 pixels). Indeed, 4x4 isn't viable for full screen view port renderings.

Go on this panel setting:


and change the block size to something like 32. It should be a lot more responsive.

At what resolution are you working ?

The root of the problem is the initial RTPATH setting for resolution: it is clear from the video that Cycles start rendering with blocks large as about 32x32 while Lux uses 4x4 (1 samples every 32x32 pixels Vs 1 samples every 4x4 pixels). Indeed, 4x4 isn't viable for full screen view port renderings.

I think we should also reduce resolution for first sample automatically and come back to native resolution(setting in green) after. In my test i get better fluidity with theses settings :

EVEN Block size at 2X and Pixel Size at 2X is impressive to work with. So for me the most affecting setting is Pixel size. If by any trick we can render at 1/2 of the native resolution and come back after first sample it will be great :

Sharlybg wrote: ↑Sun Aug 30, 2020 3:34 pm If by any trick we can render at 1/2 of the native resolution and come back after first sample it will be great

This is exactly what the "reduce first sample resolution" option is doing if you set block size to 2 - unless I misunderstand what you mean.

B.Y.O.B. wrote: ↑Sun Aug 30, 2020 3:39 pm

Sharlybg wrote: ↑Sun Aug 30, 2020 3:34 pm If by any trick we can render at 1/2 of the native resolution and come back after first sample it will be great

This is exactly what the "reduce first sample resolution" option is doing if you set block size to 2 - unless I misunderstand what you mean.

You're right i don't know why but reducing the pixel size by two even without first sample reduction give me much more fluidity impression.

@ Dade, Sharlybg, B.Y.O.B.

Thank you, that did the trick!
I'm experimenting with the block size and the pixel size values and is indeed much more responsive. Of course, at some point, I run into the light tracing limit. If I'm using caustics the result is quite messy. The preview gets stuck at the block construction part and it doesn't show the end result.

The pixel size tooltip indicates that it's about the native resolution of the monitor. That made me think what if I try on my second monitor?
My working monitor is UHD and the 2nd monitor is HD. It turns out, on the HD monitor I don't need to tamper with these settings at all, everything works just smoothly in fact, it runs faster.

Thanks for your help, now I have definitely something I can work with.

Edit: spoke too soon. The issue with the viewport is gone but in terms of performance, I'm now seeing another issue.
When in GPU mode changing any value in the node editor, say for example a slider in the HUE/SAT node or anything in the Disney material node, makes Blender unresponsive until the new value is calculated. In fact, while I drag the slider I'm not able to see the slider being updated until I release the mouse and wait.
When I switch to CPU the response is faster. Is this a limit related to the GPU?

Confirmed.
It is difficult to move objects, cameras, lighting in the pre-rendering mode. Work turns into a struggle.

Here is an example with the most primitive scene.
https://youtu.be/0G6rMHbagIo
scene file: https://dropmefiles.com/PGPBM

UPD:
If you use a Sun - Hemi HDRI card, the performance problems begin.
Here's a map, for example.
https://dropmefiles.com/N6GnP

UPD2:
the same card connected to World Light does not cause any problems.
Conclusion - something wrong with Sun Hemi HDRI
https://youtu.be/g4rVPogMBfk

UPD3: https://github.com/LuxCoreRender/BlendL ... issues/571

Still, I want this issue to be resolved.
The complexity of setting up the light makes it impossible to use Luxcore.

I have noticed that the Area light has a big impact on pre-rendering performance. When using it, moving objects becomes incredibly difficult. And the light source itself is difficult to move.
Switching Area to Sun dramatically increases performance.

Here's an example scene.
I cannot call it difficult. However, already in it I cannot adequately work with Area.

https://drive.google.com/file/d/12-NdSO ... p=drivesdk

I invented a solution to this problem.
Let pre-rendering do not work while transformations occur in the scene.
For example, if pre-rendering is launched, and I decided to move the object, the pre-rendering is waiting until I complete the action.

I have recommended Luxcore to several people and they all said it was an excellent tool. But all said that the weakest point is this freezing during pre-rendering: https://youtu.be/0G6rMHbagIo
All have fast video cards and good processors.

I insist on solving this issue. We are losing strong renderers because of this.