Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

General project and community related discussions and offtopic threads.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Sharlybg »

I'm sure you enable caustic cache in your scene.
There no need for that as light tracing is far enough
for the caustic on the outside wall.
With photon Gi only for indirect light there is no way
you will be slower.

Anyway aside from that the disabled clamping make more
Damage. So we have our issue to fix i think.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by juangea »

BlenderBrit sorry but you usage of LuxCore is basically wrong.

You leave light tracing on, which will slow the render a lot, but you disable it on Corona, you don't use PGI, when it's a basic feature that you MUST use for any kind of interior, but you use it on Corona.

[CORRECTION] Even when in the image it shows Light Tracing result, he confirmed LT was not on for the testing.

Clamping is disabled when clamping affects every engine differently.

The lightness of the scene is very different depending on the engine because internally the bounces are crippled, way more light is being evaluated on Luxcore than on Corona or E-Cycles for example, no wonder it will take more time to cleanup.
chrome_iwCdO9Zg3j.png
BTW if PGI is not working in your scene, you did something wrong, because it works even on exterior scenes, where it may not do much sense unless you have partial interiors.

This is wrong man, this is missleading in general, not just for LuxCore, but for any engine and specially for users.

[P.S.] Settings and results will be revisited to confirm or fix whats needed, thanks for that BlenderBrit
Last edited by juangea on Fri Jul 09, 2021 3:06 pm, edited 1 time in total.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Sharlybg »

The lightness of the scene is very different depending on the engine because internally the bounces are crippled, way more light is being evaluated on Luxcore than on Corona or E-Cycles for example, no wonder it will take more time to cleanup.
This part is what i want to understand. I had shared a simillar thought in the past. But didn't get any Expert explanation to help understand that.
FarbigeWelt just give this as explanation here viewtopic.php?f=4&t=2612&p=25539&hilit=porsche#p25539 but not sure if it is true :
FarbigeWelt wrote: Thu Sep 24, 2020 4:42 pm As shown in histograms below LuxCoreRender LCR renders images with extended dynamic. The difference is not very large, how ever it is good visible in the dark parts of the image. I guess this is an advantage for LCR when comparing versus Cycles.
Histogram_LCR shows little more dynamic.png
Noise can be limited by enabling de-noising in BlendLuxCore's settings for final and preview renders. -For final renders a de-noise node can be added between in- and output nodes. There is actually not any reason complaining about noisy LuxCoreRender renders since Intel's open source de-noiser was implemented in add-on BlendLuxCore-LuxCoreRender and final in Blender.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Dade »

But does the video include any note about quality ? I mean look how the statue is rendered by Cycles and its clone:

stat.jpg

I can spot an E-Cycles render miles away: most Cycles renders look like direct light only renderings but all E-Cycles look like direct light only renderings (it is the equivalent of a punch on an eye for me).

Note also as (E-)Cycles is the outlier here (every one else render indirect light).
Support LuxCoreRender project with salts and bounties
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Sharlybg »

They used same max path bounce and disabled clamping as quality rule.
I wonder if it is possible from the coding point of view to hack the light
calculation so that value like max light path doesn't matter. Also can Dev
hack indirect light behaviour internally so that user can't modify it ?
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Dade »

Sharlybg wrote: Fri Jul 09, 2021 1:49 pm They used same max path bounce
So the end result (aka speed) will depend only on the default Russian Roulette setting of each engine (and I'm pretty sure they don't know what Russian Roulette is).

What did they use as rendering halt condition ?
Support LuxCoreRender project with salts and bounties
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Sharlybg »

What did they use as rendering halt condition ?
They render for the same amount of time and just use a program to see how much noise
A giving image have compared to another.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Sharlybg »

default Russian Roulette setting of each engine
As Cycles / E-Cycles and Luxcore are opensource is it something
We can spot in the code and then have an idea of how biased the final benchmark result is ?
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by Sharlybg »

BTW is Luxcore RR is adjoint-driven Russian roulette or conventional ?

Image
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

Post by juangea »

There are many details, E-Cycle vs Cycles is clear that loose a lot of quality, that's what E-Cycles is basically based on.

Now regarding Lux for example you can see how there is a lot more light being computed, its a brighter image.

I've been talking with BlenderBrit about this and how there are fundamental differences between how engines work, like Bounces in lux has a big impact in render time and you don't usually go over 6 or even 8, specially with PGI, while in Cycles or Corona the impact of bounces is waaaay lower, but depending on the situation you may need over 23 bounces to get a proper result comparable to Lux, the same goes for Arnold.

Another example would be Clamping, theoretically is the same, but it behaves differently in every engine, and affects different things, for example in Corona you don't actually really need clamping, they have something (don't ask details) that avoids fireflies and too bright pixels that is embeded inside their algorythm, I know it's not clamping, it's a diffeerent thing because I remember Ondra mentioning it when Clamping was added to Cycles, but Cycles needs it in many situation and it helps to avoid TONS of noise with practically no difference in Lux.

Every engine works differently internally speaking.
Post Reply