LuxCoreRender Forums

Dade wrote: Wed Apr 22, 2020 11:27 am

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.

Well... I wouldn't miss the pixelated rendering at all! It's useless anyways no?

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.

Zoom effect help improve viewport responssivness i assume. How much memory cost will be ? if it is in the same league of cycles memory consumption then it is a win anyway.

It is a muss to have a more responssive viewport as the userbase increase this will become more and more a problem.

Sharlybg wrote: Wed Apr 22, 2020 11:50 am How much memory cost will be ?

It is an additional copy of the rendered image (including all AOVs, etc.).

Viewport windows are often small, and during viewport render only a few AOVs are used (RGB, alpha if transparent, avg. shading normal and albedo if viewport denoising is enabled).
So I doubt one copy is much of a problem.

It should be easy to add but open a GitHub issue because, at the moment, I have a kilometre long backlog of stuff to look into.

Dade wrote: Wed Apr 22, 2020 12:24 pm It should be easy to add but open a GitHub issue because, at the moment, I have a kilometre long backlog of stuff to look into.

B.Y.O.B. wrote: Wed Apr 22, 2020 12:10 pm Viewport windows are often small, and during viewport render only a few AOVs are used (RGB, alpha if transparent, avg. shading normal and albedo if viewport denoising is enabled).
So I doubt one copy is much of a problem.

So currently for a fast fix before Dade look into RT modification we can just move to the other engine ( already decoupled one ). so we can just download the last build and see the difference and how it help.

Sharlybg wrote: Wed Apr 22, 2020 12:29 pm So currently for a fast fix before Dade look into RT modification we can just move to the other engine ( already decoupled one ). so we can just download the last build and see the difference and how it help.

If it is not already possible, just add it like an option, like you can already use BIDIRCPU, etc.

Enabling light tracing should do it, you'll get PathCPU/OCL in that case. (it still uses WaitNewFrame(), but I guess that will return immediately in this case?)

B.Y.O.B. wrote: Wed Apr 22, 2020 12:59 pm Enabling light tracing should do it, you'll get PathCPU/OCL in that case. (it still uses WaitNewFrame(), but I guess that will return immediately in this case?)

light tracing enable as a viewport engine ? this is not what i will call an improvement.

I'd still say just use non-rt for viewport... A little lag from rendering isnt as bad as lag when changing materials and so on... I can literally leave octane rendering heavy scene and play around with everything even though rendering and changes are behind, there is no problem changing color sliders etc..