LuxCoreRender Forums

What steps can I take to speed up the viewport preview?
I want to have it nice and fast for material previews.

My working way is :

1__ stay on CPU ( yes CPU it actually more responssive with less load time)

2__ reduce your window view

3__ use low clamp value between 5 to 30 depend of your scene.

4__ use a special collection with only the object your are working on

Birkkromann wrote: Tue Apr 21, 2020 4:17 pm What steps can I take to speed up the viewport preview?
I want to have it nice and fast for material previews.

I use a crop view by pressing ctrl + B, which makes the software more efficient, even if is a large crop view

I wonder if this is related to opencl and if cuda could speed this up.
For example in octane there is a small delay between changes but UI is always as responsive as if no rendering is happening, so quick changes are no problem. In luxcore however we always have to wait for the update to register in viewport rendering and in the meantime UI is "frozen".

Currently, in BlendLuxCore the framerate of the whole Blender interface is coupled to the LuxCore framerate during viewport render. In Cycles and Octane, the two are most likely decoupled and independent.

Currently, in BlendLuxCore the framerate of the whole Blender interface is coupled to the LuxCore framerate during viewport render. In Cycles and Octane, the two are most likely decoupled and independent.

Are we locked in this behaviour by a APi limitation or it is changeable ?

It seems to me like a result of the design of the LuxCore RT engines, e.g. as discussed here, but i'm not 100% sure. Maybe it is possible to decouple it without changing the RT engine implementations.

B.Y.O.B. wrote: Wed Apr 22, 2020 10:40 am It seems to me like a result of the design of the LuxCore RT engines, e.g. as discussed here, but i'm not 100% sure. Maybe it is possible to decouple it without changing the RT engine implementations.

If you use the not "RT" version of the engines it will be decoupled

If you use the not "RT" version of the engines it will be decoupled

But there was a reason why we go with RT engine. are we going to loose something by leaving this RT engine instead of adapt it to be decoupled ?
isn't Rt more optimized for viewport render preview ?

Sharlybg wrote: Wed Apr 22, 2020 11:22 am are we going to loose something by leaving this RT engine instead of adapt it to be decoupled ?
isn't Rt more optimized for viewport render preview ?

You loose the "zoom in" effect at the start of the rendering (i.e. rendering with large pixel blocks and than refine).

P.S. I can decouple RT too but I will have to use some more memory to store a copy of the image.