Lux, Corona, Cycles

For PGI settings i consider it as a good base for such kind of work. But also alot of things are going to change happen as this the first release of Luxcore 2.2 and PGI. Also Dade want to make some settings automatic. if you Can and Want to dig more here is the 61 page Thread on luxcore :

https://forums.luxcorerender.org/viewtopic.php?f=5&t=840

I see a complete smudgefest on those pictures. Are they denoised? You can’t do really a fair comparison comparing denoised LuxCore images to undenoised Corona ones.

I’am not my Computer at home (i7 8700k + GTX 1080ti) But here at the Office with (1080ti + i7 4930k) i get 380 samples in 5min with this result :

Screen Cap :

Yes but isn’t the corona render Denoised as said at the 1st post ?

There is also a certain difference in the light, I hope you will forgive. It seems that in Corona I added the sun
Render time I bring further: LuxRender 1h 30m+, corona 30m+, cycles 45+, all with denoise!
Reference I picked instagrame

No idea… if it was, it was shitty comparison as well. One thing is to compare renderers, other thing is to compare denoisers :slight_smile: And denoisers are a lot harder to compare, especially if you don’t have baseline renderer comparison. Because then you just end up comparing amount of smudging and edge blurring rather than actual performance. Especially when you say something like “3X faster give a corona like output”. Without any baseline and actual hard data comparison, such as statement is basically pulled out of a butt :slight_smile:

With yet another layer of comparison corruption caused by the fact you are comparing CPU+GPU rendered to a CPU only renderer. And different CPU to different CPU+GPU. It’s just wrong on so many layers it’s pretty much random at this point.

1 Like

Gragh_Sparrow, could you release the scene under a open license like Creative Commons ? Does it include any 3th part copy right model/texture ?

I would like to include the scene in our freely available tests: https://github.com/LuxCoreRender/LuxCoreTestScenes

3X faster give a corona like output”. Without any baseline and actual hard data comparison, such as statement is basically pulled out of a butt :slight_smile:

If you look closely the corona render is the one which the more aggressive direct light clamping. the orange light is almost black or null when bouncing on the ceilling. So i just mean that by going more aggressive on clamping with luxcore my render is 3X faster but with less light bounce as you can see on corona side.

Render engine war are always a bit unfair. Settings / Quality / hardware / Usability / Artists Knowledge / Development level / Cost.

You’ren’t going to be perfectly fair anyway. So just pick the renderer that fit your need and your wallet/philosophy.

1 Like

Give me some time to check. And get acquainted with the rules of the license) I mean, the question of textures \ models

No,

render engines can be compared extremely precisely, if you know what you are doing. Light clamping, etc… will show only if you compare identical setups, which was not the case. It’s highly dependent on the skill of the person doing the comparison. You can’t just compare denoised images and at the same time claim that you even remotely know what you are doing, and then defend that by saying precise comparison is not impossible. It is, you can see it for example here:

Where I first establish some baseline and get at least rudimentary data until I start throwing the denoiser into the mix.

Like i was totally missing benefit from caching with my settings so there is far more to get from luxcore with better result :

BYOB just corrected me here and it is amazing again : He manage to get 680 samples instead of 380.

https://forums.luxcorerender.org/viewtopic.php?f=5&t=840&p=10639#p10639

Everyone, take it lighthearted.
In this pageant show EEVEE already won (done in 8 seconds and 4K in 25).

I like you Man sincerely ! and i start to understand your point and agree if viewed at this angle. And it isn’t a trivial work to do such comaparison when the scen start to include more shader textures and details.

Anyway Luxcore is starting to grow you can expect more from it and i hope i will see something from you with it ( will really like to have someone like you on the board. someone with a strong love for precision and detail is always a good things).

thanks !

The new Release of LuxCore is amazing!!

AMD 2950x + 2 Rtx 2080

1 Like

You also have a wonderfull Workstation Magogg so you can reduce your time by 50%. Also my PGI setting were wrong so try theses one:

Set%20best

1 Like

1 Like

I think the cache needs a bit more work. It is first alpha release so that is understandable, and if used carefuly can give some amazing performance. But in case of this scene a glossiness threshold of 0.2 is forcing brute force for most of materials so cache is not really doing that much work. Lower values might on other hand introduce some cache being picked up in reflections etc… So for now, it requires some experimentation and balancing values on user end to get best of it, at some point these values will hopefuly decided by some smart algorithm and automatically optimized.

It is a very bold statement, I have traced my first rays more than 35 years ago and I’m still very careful when doing a comparison and I always end with the feeling is rhetorical effort.

It may be not hard to find someone knowing what he/she is doing with Cycles or Lux, anyone has access to all sources and you can literal ask questions to the same people who have written the code.

Even the most experienced Corona user has no idea what is really happening under the user interface and it is hard for anyone to verify any claim. Let’s score a little point for open source: at the end of the day you can very any claim, you have the sources.

2 Likes

Congratulations to the LuxCore team for the great update with GI caching and Intel Open Image Denoiser integration.
Now for render engine comparison purposes I agree with @rawalanche that the engines should be compared without denoiser and I also agree with @Dade that it is really difficult to do in an exact way. Pure render speed is an important aspect but so is ease of use, efficient workflow, material modelling, support of industry standards etc… which are not considered here. In a typical production scenario one would probably use the denoiser and the quality and speed of the denoiser becomes an important topic as well.

1 Like

It honestly doesn’t matter that much what’s happening under the hood as long as the pixels are “right”.

What I mean by that is that as long as you have for example a set of renderers which employ at least importance sampled image based lighting, material with the usual simple diffuse reflection approximation and basic set of primitive area light shapes, you can start to do very accurate comparisons.

I’ve done many comparisons of many renderers in my life, and most of the time, if you know what you are doing, you can establish truly identical setup, and then you can spot if some rendered does something odd. For example, I had comparison of scenes rendered with 4 different renderers with outputs so incredibly close only thing that was different was the noise pattern.

The problem is most of the people set up scenes just similarly, not precisely identically, and then they start making comparisons. There’s so many things that need to be gotten right, such as:

  • Comparing pure path tracing to pure path tracing, and cached GI to cached GI
  • Comparing linear images. That means having to know which renderers do some kind of tone mapping out of the box and how to turn it off.
  • Knowing that it’s unacceptable to compare denoised images unless you are comparing denoisers
  • For example knowing which renderer defaults to refractive materials with caustics vs which ones default to refractive material with transparent shadows
  • Testing with materials of identical albedo and knowing how much negative impact on performance can excessive albedo have.
  • And so on…

I will once again use this link as an example of what I mean by proper testing:

The very first two images are very similar looking images, yet of two completely different renderers - Corona and Cycles. Identical diffuse albedo, identical IBL map with identical orientation, identical camera view, both completely linear with no tonemapping. Both pure path tracing, both using same amount of diffuse bounces, both using same Max ray intensity clamping value.

Now, with having such a good baseline for comparison, you can start making some close comparisons, both in terms of performance and if the “pixels are right”. What that means is for example you can see that Cycle’s slightly darker with same amount of bounces, probably meaning either ray clamping or the russian roulette is slightly more agressive. On the side of Corona, you can see the shadow terminator lines shift a bit, which is typical for Corona’s implementation of the terminator “shadow acne” prevention solution.

Yes, you can take a look at the source code of an open source rendered, but what ultimately matters is how the image turns out, because that’s what pays the bills.

If there was a rendered which would secretly send my scene to India where a group of 100 kids in a large warehouse paints my output image in MS paint pixel by pixel, I would not mind at all as long as the image comes back with low enough compromise in quality (bias) and fast enough :slight_smile:

So there is no problem here. the guy start by comparing mostly workflow he have under 3 dif engine we just add a contribution. So if i follow what you’re saying you are probably the right guy to open such kind of thread and start a very close and fair comparison between Lux and what ever Render engine you want.
As anyone else find it to difficult i suggest you to open a new thread with a production like interior quality and make a relevent one.

i’m serious i will be glad to see something like that from a neutral guy.No matter what will happen if you compare lux to other engine we can only improve day after day.

And a fair comparison will help spot area for improvement. So i really wish you do it at some point.