Performance issues

Use this forum for general user support and related questions.
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
User avatar
Dade
Developer
Posts: 5337
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Performance issues

Post by Dade » Sun Aug 30, 2020 12:27 pm

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:

block.jpg

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

At what resolution are you working ?
Support LuxCoreRender project with salts and bounties

User avatar
Sharlybg
Donor
Posts: 2794
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Performance issues

Post by Sharlybg » Sun Aug 30, 2020 3:26 pm

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

Portfolio : https://www.behance.net/DRAVIA

User avatar
Sharlybg
Donor
Posts: 2794
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Performance issues

Post by Sharlybg » Sun Aug 30, 2020 3:34 pm

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 :
frt.jpg
frt.jpg (10.64 KiB) Viewed 2967 times
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA

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

Re: Performance issues

Post by B.Y.O.B. » 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.

User avatar
Sharlybg
Donor
Posts: 2794
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Performance issues

Post by Sharlybg » Sun Aug 30, 2020 3:53 pm

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

Portfolio : https://www.behance.net/DRAVIA

User avatar
phoenixart
Posts: 18
Joined: Tue May 05, 2020 7:04 pm
Location: Los Angeles
Contact:

Re: Performance issues

Post by phoenixart » Mon Aug 31, 2020 2:26 am

@ 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?
3D Designer, Photographer
https://phoenixart.com

User avatar
Dez!
Posts: 310
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Performance issues

Post by Dez! » Tue Sep 29, 2020 9:18 am

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
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/

User avatar
Dez!
Posts: 310
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Performance issues

Post by Dez! » Tue Dec 08, 2020 4:11 pm

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
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/

User avatar
Dez!
Posts: 310
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Performance issues

Post by Dez! » Wed May 05, 2021 6:11 am

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.
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/

User avatar
Dez!
Posts: 310
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Performance issues

Post by Dez! » Mon May 31, 2021 9:21 pm

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.
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/

Post Reply