progressively darkening rendering

Use this forum for general user support and related questions.
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Post Reply
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

progressively darkening rendering

Post by lacilaci »

Hi,
So I'm trying to pass some scene parts from my last project from cycles to luxcorerender for performance comparison and testing and training myself with luxcorerender and right off the bat I'm getting some weird behavior (might be my fault...?)

So for a while everything was working well with me setting up the scene and converting some basic architecture models and then I switched clamp output on to see what it does basicaly and suddenly next render and preview render was getting slowly darker and darker.

Now it doesn't matter what sampler I use or if I turn off and on the clamp output, nor if I reopen the scene. And also if I try region rendering I get error saying "size mismatch RenderPass->rect size: 359x291, passed width x height: 360x291.

I'm using 2.1 alpha 2 so I know it's alpha and probably very buggy and unstable, but is there something I can do to fix this behavior. Or should I wait for some next alpha? thanks

EDIT:
Ok so apparently I used very small value for clamping (20) I thought it's something like in other renderers "max sample intensity" but it seems that it makes the renderer go break and even shows some weird artifacting. Does it make sense to use the clamping if it shows some insane suggested value, like: 5673935872.00?
Attachments
r1.jpg
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: progressively darkening rendering

Post by B.Y.O.B. »

lacilaci wrote: Tue Aug 07, 2018 11:27 am I thought it's something like in other renderers "max sample intensity"
It is, your scene is just lit by very bright lights (probably sun/sky).
Maybe my post here helps you: https://blenderartists.org/t/motorcycle ... /1119966/6

The darkening over time is probably a side-effect of the autolinear tonemapper (which adapts to the image brightness).
I would recommend to disable the "Auto" option in the tonemapper settings (can be found in the camera properties).
https://wiki.luxcorerender.org/ImagePip ... onemappers
lacilaci wrote: Tue Aug 07, 2018 11:27 am And also if I try region rendering I get error saying "size mismatch RenderPass->rect size: 359x291, passed width x height: 360x291.
Can you upload the scene that produces this error?
It's probably a rounding problem somewhere, would be great to have the exact scene.

As a workaround, save a copy of the scene, then choose a slightly different border.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: progressively darkening rendering

Post by lacilaci »

B.Y.O.B. wrote: Tue Aug 07, 2018 11:51 am
lacilaci wrote: Tue Aug 07, 2018 11:27 am I thought it's something like in other renderers "max sample intensity"
It is, your scene is just lit by very bright lights (probably sun/sky).
Maybe my post here helps you: https://blenderartists.org/t/motorcycle ... /1119966/6

The darkening over time is probably a side-effect of the autolinear tonemapper (which adapts to the image brightness).
I would recommend to disable the "Auto" option in the tonemapper settings (can be found in the camera properties).
https://wiki.luxcorerender.org/ImagePip ... onemappers
lacilaci wrote: Tue Aug 07, 2018 11:27 am And also if I try region rendering I get error saying "size mismatch RenderPass->rect size: 359x291, passed width x height: 360x291.
Can you upload the scene that produces this error?
It's probably a rounding problem somewhere, would be great to have the exact scene.

As a workaround, save a copy of the scene, then choose a slightly different border.
Thank you. I do use sun and sky and it seems it needs much higher values for clamping. The darkening went away after I resaved scene few times and so did the error with border region.

However I'm gonna be using this scene a lot for testing and learning so if I come across the error again I'll save and post it for you to see. Meanwhile can you tell me how to make instances? :D Seems alt+d on couple of trees produced over 133 mil. poly that wasn't instanced and don't fit into 32GB ram
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: progressively darkening rendering

Post by FarbigeWelt »

lacilaci wrote: Tue Aug 07, 2018 11:27 am I'm using 2.1 alpha 2 so I know it's alpha and probably very buggy and unstable, but is there something I can do to fix this behavior. Or should I wait for some next alpha? thanks

EDIT:
Does it make sense to use the clamping if it shows some insane suggested value, like: 5673935872.00?
In my opinion alpha 2 is very stable and most issues are related to wrong use.

The values make sense, you can have a lot of light or almost nothing. You may use clamp suggestion or divide its value by 10 or 100. For some scenes you get better results if you reduce environmental light‘s gain 100 to 1000 times. It is very bright compared to light sources like points or areas.

Trees can eat up your memory especially if you have leafs with a few dozen polygons and make them ‚real‘. A trick to build a forest is using particle systems.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: progressively darkening rendering

Post by B.Y.O.B. »

FarbigeWelt wrote: Tue Aug 07, 2018 5:50 pm For some scenes you get better results if you reduce environmental light‘s gain 100 to 1000 times. It is very bright compared to light sources like points or areas.
The thing is that the light brightness and the clamp value are all absolute values.
We are used to deal with relative values scaled to something in the 0 to 1 range (or 0 to 255, if you work with integers) from image manipulation programs like Photoshop. I don't know how Cycles does it exactly, but I have the feeling that the sun/sky there just doesn't use the physically correct brightness (instead it is much weaker).

I also often reduce the gain of the sun/sky to something like 0.00001 to have more manageable values everywhere else, but this is an artistic approach and not a realistic one.
If you do archviz and you know exactly how bright all the lamps in the scene are, you can input those correct values and use sun/sky gain 1 and you will get a physically correct result. Most lamps are just not very bright compared to the sun (try taking a flashlight outside at noon and shine it on the ground).
But in a 3D program you add a sun and a spotlight and expect to see both. Maybe we should raise the default brightness of all lamps beside sun/sky.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: progressively darkening rendering

Post by lacilaci »

Thanks for the input guys. I did few runs with some settings to see how clamping and denoising behaves and also to see how metropolis and pathtracing performs. btw I used sun and sky and clamping was set to 100k.

Few things I noticed that don't make sense to me.

1:Denoiser seems to do some weird highlight clamping too(bug?). I don't know how it works but it doesn't just remove fireflies and smooth/denoise the image, but also makes the image less contrasty especially in the highlights. The difference is subtle in this case but I might be able to find a situation where it shows better. Look especially at unclamped and denoised images, they show pretty destroyed contrast and sky seems even a bit desaturated. It is also interesting how metropolis even unclamped has this desaturated sky and low contrast compared to tiled unclamped.

2:Clamping even on high values makes image less contrasty but since it's still high values then some shaders can produce fireflies. Now of course better control over shaders can help to reduce the issue and maybe lowering sun power too. The practical problem is that if I quickly have to build a scene and make materials I can follow some general rules, like not using too bright and oversaturated colors/textures. But if I start render testing after I built the scene and fireflies start showing up, I might not have enough time to hunt down what material or light is giving me the issue. So I would only rely on renderer not sampling/cutting off high energy samples.

Sadly, I don't know how other renderers do it, but from user perspective changing clamping values on corona or cycles only cuts off those high values leaving everything else unchanged. In luxrender it would seem that everything on screen gets immediately darker the moment you introduce clamping and kinda flattens the highlights right away. But this also might be a realistic result after you clamp the sun power, I really don't know.

On other hand, if I look at tiled unclamped vs unclamped and denoised(or clamped) I see that by default the unclamped non-denoised image has beautiful contrast that is looking way better/realistic than what I get from cycles and corona for example. The clamped(and/or denoised) results are very flat and generaly that's the look I think I'd get from corona and cycles.

So I guess the win win situation would be to find a way to make denoiser and clamping not destroy the contrast but really only cut the fireflies. Maybe instead of some general clamping, having some other smart way to identify those super bright pixels and only clamp those. I'm sorry if I oversimplify the problem as I'm only cabale to use the software, I don't know how it works or should work. And sorry for the long post.
Attachments
100K_clamped_vs_unclamped.jpg
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: progressively darkening rendering

Post by FarbigeWelt »

B.Y.O.B. wrote: Tue Aug 07, 2018 7:00 pm Maybe we should raise the default brightness of all lamps beside sun/sky.
EDIT: some corrections applied
I don‘t think so. A tool tip would be the better solution. Sunlight at ground is about 1kW/m^2, much more than 100 klux. A cloudy sky has 10 to 100 klux. A bright efficant LED delivers 170 lumen/W. 1 lumen equals 1 lux*m^2. One should be aware of that if physics matter and it does 😎.
Last edited by FarbigeWelt on Wed Aug 08, 2018 6:45 pm, edited 1 time in total.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: progressively darkening rendering

Post by FarbigeWelt »

lacilaci wrote: Wed Aug 08, 2018 5:16 am Thanks for the input guys. .

Few things I noticed that don't make sense to me.

they show pretty destroyed contrast and sky seems even a bit desaturated.

2:Clamping even on high values makes image less contrasty

the look I think I'd get from corona and cycles.

And sorry for the long post.
I like the story Einstein told us, the imaginary ride on a ray of light. If you clamp brightness every reflection is also reduced because you can simplified assume rendering is all a about multiplications.

Currently cycles has some other advantages, i.e. defining materials. But, you wont get the astonishing look of luxcorerender pictures.

Don‘t, for me speaking, your efforts and posts are welcome.

And well, fire flies are a pest.. I guess there is not any simple solution to get rid of them without loosing crispyness. You may render 4 to 16 times of final resolution of a 32 bit float openEXR, temove them in a post process with a smart filter and export in final resolution png. It helps, but consumes a lot of time.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
Post Reply