Performance issues

Use this forum for general user support and related questions.
User avatar
Dade
Developer
Posts: 4717
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: 2371
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: 2371
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 677 times
Support LuxCoreRender project with salts and bounties

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

User avatar
B.Y.O.B.
Developer
Posts: 3800
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: 2371
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: 195
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/

Post Reply