Giga Benchmark battle : Luxcore Redshift CyclesX ECycles Vray Corona

General project and community related discussions and offtopic threads.
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: Sat Jul 10, 2021 11:33 am
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.
It is a middle ground as usual defaults are. However the default parameters were set in a time when there wasn't variance clamping and denoisers: nowadays you can probably live with the most extreme settings if you use both:

Code: Select all

path.russianroulette.depth = 1
path.russianroulette.cap = 0.0
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 »

No, we don't bias if not explicitly told and only in very few cases (Cycles is exactly the opposite).
It is something i also suspect when i use cycles. The issue is that they provide settings that seem to give you control over bias.
I mean you can enable reflective and refractive caustics. You can disable clamping you can raise bounce value like you want. You can stop glossiness blur.But still it is very hard to produce fireflies in cycles.
So there should be something done internally. And as the code is open i wonder if that can't be prooved factually.
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 »

If it is too difficult to show the part of the code in cycles doing the trickery. Maybe we can prove that by designing a 3D scene that can make the trickery obvious.

Any idea on how such scene should be build ?
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 »

Mmm this opens an interesting conversation.

There are situations where some settings may be preferred, although with a more biased / worse result, but faster, could be interesting to have a "draft" configuration, or some of these settings exposed as advanced.

The idea of the RR settings, Dade you said that the worst situation could be perceived as 6 times faster, this is just because the numbers or because it reaches an specific amount of noise faster but with more dangers like more fireflies? or is the other way around?

One of the things I noticed when working with LuxCore is that we have very small room for tweaking, and while I think this is something that should not be exposed to new users, could be interesting to have access to these settings that can give us more performance at the cost of quality, specially when we have to show quick drafts and things like that.

What do you think?
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 »

There are situations where some settings may be preferred, although with a more biased / worse result, but faster, could be interesting to have a "draft" configuration, or some of these settings exposed as advanced.
For what i can understand there is no such parameter inside Luxcore.It isn't build this way.
Only ways to introduce bias is with stuff like clamping or PGI cache ... what we discussing is
that engine like cycles do introduce internal bias user don't see on the surface. Lux don't do that.
So my idea is to reveal that difference.
The idea of the RR settings, Dade you said that the worst situation could be perceived as 6 times faster, this is just because the numbers or because it reaches an specific amount of noise faster but with more dangers like more fireflies? or is the other way around?
It just look faster because of the samples/sec number (6.12M samples/sec) but in reallity it converge slower because of the small amount of rays/samples
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 I think RR doesn't introduce bias for speed as tradeoff.
One of the things I noticed when working with LuxCore is that we have very small room for tweaking, and while I think this is something that should not be exposed to new users, could be interesting to have access to these settings that can give us more performance at the cost of quality, specially when we have to show quick drafts and things like that.

What do you think?
I think that nowdays there are multiple way to speed up a render engine while being ""fully unbiased""
a recent numerous papers just show. And introducing aggressive bias in engine tend to break lot of code
like bidirectional or light tracing.
I remenber clarissefx have something to filter fireflies without clamping
Dade wrote: Mon Mar 23, 2020 9:51 pm
Sharlybg wrote: Mon Mar 23, 2020 4:56 pm Clarisse Fx or Octane one ? is it better If yes can we add it ?
If I add the their sources...

The PDF based clamping is an old JeanPhi's idea, he tried an implementation based on local vertex path clamping and it didn't worked well however I think the idea may work if considering the complete path PDF.



https://clarissewiki.com/4.0/fireflies-filtering.html

Image

Image
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 »

juangea wrote: Sat Jul 10, 2021 3:43 pm The idea of the RR settings, Dade you said that the worst situation could be perceived as 6 times faster, this is just because the numbers or because it reaches an specific amount of noise faster but with more dangers like more fireflies? or is the other way around?
As I said, there may be some concept worth re-evaluating: RR in ray tracing is about a 30 years old idea (and it is about 60 years old as idea in general). Nowadays we have denoisers, clamping, etc. If some RR setting introduce more noise but the noise is still handled by the denoiser, it may be worth using.
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 »

Anything about spoting the Cycles trickery ?
We can use a scene of given complexity about indirect light
Or spot the trickery inside the code of cycles.

I mean if people don't get the correct explanation this lie is going to make
a lot of damage as it is already doing.
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 »

I made a scene with complexe indirect light visibility. bounce level for every path
is set to 64. Engine tested Cycles 2.93 CyclesX 3.0 Luxcore 2.6. Luxcore just use
Cycles settings for the single Area light and all shaders. With default light auto translation
Luxcore look darker compared to cycles/X. So i double the light intensity in another test
to check if it isn't luxcore missing indirect light. Also made a GI cache render.
All on GPU 2060 super no clamping.

Cycles
Cycles 2.93 time 6mn14 512.jpg
CyclesX
Cycles X time 6mn14 512.jpg
Luxcore Pure Path
Luxcore 2.6 time 6mn14.jpg
Luxcore Pure Path 2X light
Luxcore 2.6 time 6mn14 2xL.jpg
Luxcore GI cache
Luxcore GI cache 2.6 time 6mn14.jpg
BLENDFILE
CvsLX II.zip
(2.34 MiB) Downloaded 164 times
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
daros
Posts: 280
Joined: Thu Dec 12, 2019 3:25 pm
Location: inside human language
Contact:

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

Post by daros »

Hi, think this kind of tests have to be kept as simple as possible in order to isolate one specific engine behaviour.

Emitter has 1.000.000 lumen which is a lot for such a small object. It has to be exaggerated precisely to highlight the internal bounce limitation.

Both 60 seconds renderings.

This is Maxwell Render which claims unlimited light bounces :)
View 01 800x400.jpg
View 01 800x400.jpg (9.02 KiB) Viewed 4104 times

This is Luxcore with only 24 bounces... ohhhhh look at that! Infinite<24!
View 01 800x400 lux_1.jpg
View 01 800x400 lux_1.jpg (10.1 KiB) Viewed 4101 times
Attachments
light bounce stress test.zip
(2.12 KiB) Downloaded 169 times
Last edited by daros on Sun Jul 11, 2021 9:28 am, edited 4 times in total.
daros
Posts: 280
Joined: Thu Dec 12, 2019 3:25 pm
Location: inside human language
Contact:

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

Post by daros »

a part from the wired artifact of the light passing through coincident edges, luxcore even maintains the correct light color tint...maxwell not.

In my opinion Luxcore plays in a different liga and this has to be explained.
Post Reply