LuxCoreRender Forums

Just doing some test as i'm preparing a cycles vs Luxcore battle Video. And it look like as far as caching isn't in the mix Cycles seem o be too fast for luxcore.
The story is the same from viewport to final render : test just run on CPU to avoid any bottlesneck.

Luxcore :

Cycles:


Test scene blender 2.81a luxcore last build You will need to change luxcore halt time to match cycles rendering time according to your system.

Even With a simple cube Luxcore viewport seem to be way to noisier. Is anyone else experience this issue ?

Hi Sharlybg

I don’t like to bother asking you the question, what is the meaning of compering clay model renders of different renderers? Imagine one renderer to have clay render optimized algorithms omitting all usual calculations just to get a fast as possible preview. Its result would not differ much from a simple openGL shade render.
I think comparison only makes sense if renderer have to use all of their features to show their strengths in computing their kind of most photo realistic pictures. LuxCoreRender requires a scene a scene for showing the beauty of dispersion, caustics (including mirroring) smooth shadows, indirect lightening, contrast high:low lights, tone mapping, black body radiation and white balance, volume scattering and materials like velvet. Well, LCR would pretty surely take its time, even on good, fast graphic cards, while other renderers finished their kind of job already. But hey, are you stuck to 4 colors comics or rather enjoy regular pattern free 9 colors high gloss photo prints of natural beauties?

Is your area light "invisible" ?

Dade wrote: ↑Mon Dec 09, 2019 1:52 pm Is your area light "invisible" ?

In the current state yes (visible to camera is enable). But even when i set it to invible luxcore converge a lot slower. (The blend file is in the first post if you want to take a look).

I don’t like to bother asking you the question, what is the meaning of compering clay model renders of different renderers?

i make it just simple because it doesn't change very much the story. it make sometime where i had seen this performance issue with Luxcore comparing to cycles. Was just wondering how fast is Luxcore Pure Path tracer without caching super boost. and in most of my test Cycles converge way faster when PGi isn't enable.

Some other user just see the same :

Binke : https://blenderartists.org/t/luxcoreren ... 1183292/68

Ok thanks.
I love the results luxcore produces, it reminds me of Corona, I really wish there was a official plugin of Corona for Blender and not just the community made on that lacks a lot of stuff.
Luxcore is really fast in F12 render in OpenCL pathtracing, especially for interior renders.
However, the viewport preview is too slow for me to use in production for the work I do. Its incredibly slow compared to using cycles + CUDA. Are there any plans on improving this?

Anyway i will do a more complete scene just to make it obvious. But what should be important here ?


__ Is a normal behaviour ?

__ Is there any user bad input ?

__ Can we improve it ?


Remenber that this Normal cycles path vs Luxcores path / We don't even speak about E-Cycles.

Even Dade said this before :

viewtopic.php?f=10&t=1549

It is an uphill battle: Cycles is included in Blender, LuxCore is not. Every single Blender user will first learn Cycles than, if he/she is unhappy will start to look around and, may be, decide to put the effort to learn a new rendering package. It is clearly a very hard battle, being a bit better is not enough, you need to be a lot better to justify the additional effort to switch.

this is my point : We are super fast with caching. And if we can be as fast as cycles without caching then a lot more speed is unlocked.

Sharlybg wrote: ↑Mon Dec 09, 2019 2:16 pm

Ok thanks.
I love the results luxcore produces, it reminds me of Corona, I really wish there was a official plugin of Corona for Blender and not just the community made on that lacks a lot of stuff.
Luxcore is really fast in F12 render in OpenCL pathtracing, especially for interior renders.
However, the viewport preview is too slow for me to use in production for the work I do. Its incredibly slow compared to using cycles + CUDA. Are there any plans on improving this?

This is a totally different topic, RTPATHCPU is used for view port rendering while PATHCPU is used for final renders. They are 2 different render engines, the first is optimized for fast editing, the second for rendering.

He is also comparing RTPATHCPU (i.e. CPU rendering) to "cycles + CUDA" (i.e. GPU rendering).

This is a totally different topic, RTPATHCPU is used for view port rendering while PATHCPU is used for final renders. They are 2 different render engines, the first is optimized for fast editing, the second for rendering.

He is also comparing RTPATHCPU (i.e. CPU rendering) to "cycles + CUDA" (i.e. GPU rendering).

Ok this is right.

But did you also notice the slow convergence in the blendfile (viewport/final) ? Or it is a local problem i have ?

Note that shader are the same.

Sharlybg wrote: ↑Mon Dec 09, 2019 3:23 pm Note that shader are the same.

Does Cycles have Russian Roulette ?

Anyway, an analysis must start from simple cases: use a point light and use direct light only (and don't run the test for only 7 seconds or even a microscopic difference in export/start up time can make a huge difference in only 7 seconds).

Does Cycles have Russian Roulette ?

Anyway, an analysis must start from simple cases: use a point light and use direct light only (and don't run the test for only 7 seconds or even a microscopic difference in export/start up time can make a huge difference in only 7 seconds).

The problem i'm mentioning is very obvious. please just open the file switch to viewport render and just change render engine from luxcore to cycles and back.
See the speed in convergence.