Thanks for the help, got rid of the noise issue.
I understand your problem but LuxRender first, and LuxCoreRender after, have always intended the scene design process to be similar to the one of a real photography. Often people setup scenes like in a real photography studio using the same tricks and techniques.
Over time some feature, like light source “Disabled Indirect Visibility” has been introduce but only as work around to some render engine limit (i.e. in this case, sun light source generating a lot of fireflies when using plain path tracing). They are not intended to have artificial control over lighting or fake some result, etc.
The general rules has always been, if it works like reality, it is a feature. I have the feeling you are going to be very disappointed, if you try to translate the classic Vray bag of tricks to LuxCoreRender.
Thanks for the answer! Makes sense - think i understand what luxrender is / is not.
Will have a look at metropolis and hybrid methods…
Keep in mind that there few scenario where metropolis gonna beat Sobol if you are doing archviz.
And it is even true when you add GPU in the combo.
My advice will be to start with a simple project ( Kitchen/ bathroom/ bedroom) share result and configuration in the forum : https://forums.luxcorerender.org/
Then we can easily follow and help you get as much perf as possible.
Its not that - just that OIDN was not trained on metropolis - making it useless in that case.
Btw - I saw on the github page that it can be retrained for different samplers - is that something that’s on the list for the future?
I guess the low-frequency image variations coming from metropolis are not exactly the best case for an ai-denoiser
edit: also seems to struggle with Light Tracing (in all the cases i am doing very low quality renderings - 120sec on ryzen3900…)
Did a benchmark on Mac mini with M1. Have a look here.
A new Video tutorial on Luxcore Light groups feature. Allowing to reset lighting even after render Or Render multiple version of a project all at once Or Make an animation from a single frame
I have problems getting expected results in cycles and luxcore when it comes to specular reflections.
Is this how it should be? So it is impossible to get a basic lambertian shading with disney?
Unless roughness is 1.0, but in any case - the specular slider has close to no effect at all - same as in cycles.
The related cycles thread over at devtalk:
Nope, it isn’t possible to have pure labertian surface with Disney material. I know it may sound strange but it is like that by design by Disney people. If you check the code (https://github.com/LuxCoreRender/LuxCore/blob/55b64c719a14957c40019bd51ded3ee4931e588d/src/slg/materials/disney.cpp#L472) you will see you can not have 100%-only “diffuseWeight”.
Specular slider works fine in Cycles. I don’t know Lux’es implementation, but the diffuse part of Disney is not Lambertian, but Disney Diffuse - it is a different shading model. Lambertian is strictly cosine, whereas Disney Diffuse also take exit IOR into account. Also, Oren-Nayar is not same as Disney Diffuse with roughness.
What’s wrong with using Matte material if you only want diffuse?
The main problem is (also in cylces) that is is not possible to get a ‘slightly’ specular surface easily. The slider surely correct math-wise, it is just not very artist-friendly.
Specifically in the above example (screenshot) moving the specular between 0 and 1 does not change anything in the resulting image.
the file: specular LUX publish.blend (807.8 KB)
The specular slider only has an effect when you look at the surface from top-down, not at grazing angles. Anyway, neither we nor the Cycles devs can do anything about this because it would break compatibility with all the other software that implements the disney shader (the Cycles implementation is already a bit wrong when it disables specularity completely at specular = 0).
You could instead mix the disney shader with a diffuse/matte shader to achieve what you need.
One last question - then i stop: arnold e.g. has three values to set the specular, weight / color / roughness. Could such an approach make sense? Extend the shader so to speak… without breaking pbr workflows with maps
I’m wondering: is ease of use the only advantage of the Disney shader in Luxcore, or are there also other benefits compared to using dedicated Luxcore shaders?
Actually, I consider the major value of Disney material the interoperability across many applications: it is somewhat a “de facto” standard.
I have never found the idea of an “Uber Shader” particularly appealing but I consider the value of a cross application standard quite high.
Thanks, I understand your point.
To be honest I haven’t used it yet, mainly because I’ve always got in the back of my mind that Disney shaders usually sacrifice a little bit of physical correctness to get more predictable, artist-friendly results. Is this also the case with the Luxcore Disney shader?
I prefer the easy material preset buttons that can be found in the Material tab (Colored Glass, etc.). Speaking of which: I noticed that a few materials are not in that section of material buttons, such as the Carpaint material and Velvet material.
The only truly physically correct materials are the measured one, for instance like Metal=>Copper/Gold/Etc. in LuxCore.
The other are the result of a model and they may include some assumption and/or simplification.
Disney may be worse because it tries to cover a really large number of material types so it may require some more assumption/simplification.
This is mostly why I don’t particularly like the idea of a “Uber shader”: “the one material to rule them all” (cit. Tolkien).
How is the Compositor performance with this setup?
Willing to test the new LG
BTW, how you setup 2 hdrs?