Page 3 of 8

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

Posted: Fri Jul 09, 2021 3:37 pm
by daros
Totally misleading test. If you compare closed technologies with open technologies, you have to be much stricter in setting up such tests. Closed technologies steal here and there in order to gain speed.... The tests must be able to highlight these tricks.
And the funny thing is that you don't even appreciate Luxcore's crazy good light distribution compared to most others. And you can easily edit Luxcore's render to make it look like Corona's, but you can't edit Corona's render to make it look like Luxcore's because Corona's image simply doesn't have the same quality of light distribution. It's the difference between a raw file of a photo taken with a professional camera and a contrasty image created by an i phone... it is obvious that for someone the iphone photo is more attractive. Not for the photography professional who knows how to post produce 100 different types of color corrections from a raw file. But he won't be able to do that starting from a poppy cell phone photo. No serious person compares an iphone photo to a raw from a Sony a7r III. To be kind I see some naivety in this test. Otherwise I think it was done in bad faith and with specific goals.

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

Posted: Fri Jul 09, 2021 5:16 pm
by Sharlybg
The issue is that not everyone have a degree in Computer science and Light transport research. Most artist just know at best the purposes of the settings the engine just expose. But such kind of information or argument can't easily proove by an artist. Only someone with the correct knowledge can explain How wrong this is.
At least 2 of the compared engine are opensource. if there is a way to show that this isn't a correct test we should at least explain that.
We can take a cornell box render scene like the one in page 2 render in both Blender and Luxcore output as full EXR same path settings and no clamping. and show why the result is unfair and biased.

Otherwise millions of people are going to believe this big Lie and see Lux as the forever snail.
If someone want I am ready to make scene for the experiment.

Vote for Luxcore! Vote for Quality!

Posted: Fri Jul 09, 2021 6:41 pm
by FarbigeWelt
daros wrote: Fri Jul 09, 2021 3:37 pm Totally misleading test. If you compare closed technologies with open technologies, you have to be much stricter in setting up such tests. Closed technologies steal here and there in order to gain speed.... The tests must be able to highlight these tricks.
And the funny thing is that you don't even appreciate Luxcore's crazy good light distribution compared to most others. And you can easily edit Luxcore's render to make it look like Corona's, but you can't edit Corona's render to make it look like Luxcore's because Corona's image simply doesn't have the same quality of light distribution. It's the difference between a raw file of a photo taken with a professional camera and a contrasty image created by an i phone... it is obvious that for someone the iphone photo is more attractive. Not for the photography professional who knows how to post produce 100 different types of color corrections from a raw file. But he won't be able to do that starting from a poppy cell phone photo. No serious person compares an iphone photo to a raw from a Sony a7r III. To be kind I see some naivety in this test. Otherwise I think it was done in bad faith and with specific goals.
:!: :D :!: :D :!:

Congratulation! I very appreciate your comparison of dull smart phone phtography with good camera's high dynamic raw shots. (Mine example was a bit more sarcastic: 4 colors cartoons on cheap grey-yellowish paper vs. 9 color fine art photohraphic prints on high glossy or velvet smooth >200 g/m^2 paper.

Vote for Luxcore!
Vote for Quality!

German common expression: "Gut' Ding' will Weile haben!".

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

Posted: Sat Jul 10, 2021 10:11 am
by zuljin3d
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.
All the quality of the E-cycles rests on these settings: :D
Image

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

Posted: Sat Jul 10, 2021 10:35 am
by Sharlybg
Do someone know where i can find the russian roulette settings ?
I lost it in the addon.In the past BYOBY just show me but it is no longer
available in the link : viewtopic.php?f=4&t=1741&hilit=Russian+Roulette
B.Y.O.B. wrote: Wed Jan 29, 2020 10:45 am The properties are described here: https://wiki.luxcorerender.org/LuxCore_ ... PATHCPU.22
You're probably looking for "path.russianroulette.depth" and "path.russianroulette.cap".

In the addon, you can add these here for testing: https://github.com/LuxCoreRender/BlendL ... fig.py#L51

It's easiest to add a hardcoded line, something like

Code: Select all

"path.russianroulette.depth": 3,
however note that when you change this value, you will have to restart Blender so the change takes effect.

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

Posted: Sat Jul 10, 2021 10:37 am
by Sharlybg
Sorry I remenber i have to add thoses lines yself :mrgreen:

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

Posted: Sat Jul 10, 2021 11:00 am
by Dade
This is a rendering with intentionally bad RR settings (0.97M samples/sec):

bad.jpg

This is a rendering with default RR settings (3.41M samples/sec):

default.jpg

This is a rendering with intentionally fast RR settings (6.12M samples/sec):

good.jpg

As you see I can manipolate the samples/sec however I want. But check the "rays per samples": the first one traces ~36 rays per samples while the last one only ~4 per samples. Clearly the last one is perceived 6 time "faster" ... but it isn't, it has just more noise and potentially fireflies.

The 3 renderings are still unbiased so they converge at the same solution on the long run.

In the case of Cycles and its clone, I assume by looking at the rendering, they are instead biasing more or less the rendering, cutting stuff. In particular, it is quite evident like E-Cycles does, most of the times, direct light only renderings.

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

Posted: Sat Jul 10, 2021 11:04 am
by Dade
Sharlybg wrote: Sat Jul 10, 2021 10:37 am Sorry I remenber i have to add thoses lines yself :mrgreen:
There are more settings:

Code: Select all

# Higher is the max. depth and more effect RR settings will have
path.maxdepth = 32
# At what depth, RR will start to operate: lower is faster. Range [0, path.maxdepth]
path.russianroulette.depth = 3
# At what value, RR will start to operate: lower is faster. Range [0.0, 1.0]
path.russianroulette.cap = 0.5

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

Posted: Sat Jul 10, 2021 11:33 am
by Sharlybg
In my test i played with theses two setting

Code: Select all

"path.russianroulette.cap": 0.5,
            "path.russianroulette.depth": 1,
As you see I can manipolate the samples/sec however I want. But check the "rays per samples": the first one traces ~36 rays per samples while the last one only ~4 per samples. Clearly the last one is perceived 6 time "faster" ... but it isn't, it has just more noise and potentially fireflies.
So basically the default RR setting are Ok.
In the case of Cycles and its clone, I assume by looking at the rendering, they are instead biasing more or less the rendering, cutting stuff. In particular, it is quite evident like E-Cycles does, most of the times, direct light only renderings.
IS there a settings inside Lux we can manipulate to trigger this Cycles behaviour so that we make obvious the unfairness of the Benchmark.
I don't know something that cut off indirect light internally as we suppose cycles do.

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

Posted: Sat Jul 10, 2021 1:02 pm
by Dade
Sharlybg wrote: Sat Jul 10, 2021 11:33 am IS there a settings inside Lux we can manipulate to trigger this Cycles behaviour so that we make obvious the unfairness of the Benchmark.
I don't know something that cut off indirect light internally as we suppose cycles do.
No, we don't bias if not explicitly told and only in very few cases (Cycles is exactly the opposite).