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.
Luxcore vs Cycles Final/Viewport
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Re: Luxcore vs Cycles Final/Viewport
Even With a simple cube Luxcore viewport seem to be way to noisier. Is anyone else experience this issue ?
- FarbigeWelt
- Donor
- Posts: 1046
- Joined: Sun Jul 01, 2018 12:07 pm
- Location: Switzerland
- Contact:
Re: Luxcore vs Cycles Final/Viewport
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?
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?
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
MacBook Air with M1
Re: Luxcore vs Cycles Final/Viewport
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).
Re: Luxcore vs Cycles Final/Viewport
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.I don’t like to bother asking you the question, what is the meaning of compering clay model renders of different renderers?
Some other user just see the same :
Binke : https://blenderartists.org/t/luxcoreren ... 1183292/68
Anyway i will do a more complete scene just to make it obvious. But what should be important here ?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?
__ 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.
Re: Luxcore vs Cycles Final/Viewport
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.Sharlybg wrote: ↑Mon Dec 09, 2019 2:16 pmOk 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?
He is also comparing RTPATHCPU (i.e. CPU rendering) to "cycles + CUDA" (i.e. GPU rendering).
Re: Luxcore vs Cycles Final/Viewport
Ok this is right.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).
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.
Re: Luxcore vs Cycles Final/Viewport
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).
Re: Luxcore vs Cycles Final/Viewport
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.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).
See the speed in convergence.