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.
Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
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.
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
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.
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.
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
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.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.
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.
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
But does the video include any note about quality ? I mean look how the statue is rendered by Cycles and its clone:
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).
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).
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
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 ?
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 ?
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
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 ?
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
They render for the same amount of time and just use a program to see how much noiseWhat did they use as rendering halt condition ?
A giving image have compared to another.
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
As Cycles / E-Cycles and Luxcore are opensource is it somethingdefault Russian Roulette setting of each engine
We can spot in the code and then have an idea of how biased the final benchmark result is ?
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
BTW is Luxcore RR is adjoint-driven Russian roulette or conventional ?
Re: Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona
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.
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.