Page 1 of 2
tilepath and clamping... again
Posted: Wed Oct 31, 2018 6:49 am
by lacilaci
Previously there was an issue where tilepath and clamping would especially in first pass clamp too much (not really sure what was the issue in detail)
Now it seems tilepath doesn't respect clamping at all. In attachment pathcpu vs tilepathcpu
Re: tilepath and clamping... again
Posted: Wed Oct 31, 2018 9:02 am
by Dade
I need a test scene showing the problem.
Re: tilepath and clamping... again
Posted: Wed Oct 31, 2018 9:40 am
by lacilaci
here, it's set for 30 sec rendering.
Just render with and without tiled and compare the results(pretty big difference).
PS: looking at this testscene results, it would seem that clamping is working to an extent, but is very different when using tiled anyways.
And I also noticed in that bidir clamps lights differently too. Maybe it's normal pathtracing that does something wrong? At first sight it looks like normal pathtracing is not getting enough bounces, but disabling clamping fixes it...
And one more thing, first pass with tiled has highlights clamped way more and then it continually gets brighter/more correct in next passes, is this normal?
Re: tilepath and clamping... again
Posted: Thu Nov 01, 2018 4:02 pm
by Dade
lacilaci wrote: ↑Wed Oct 31, 2018 9:40 am
And one more thing, first pass with tiled has highlights clamped way more and then it continually gets brighter/more correct in next passes, is this normal?
Your problem is here, I will explain how it works and why you observing this result. Variance clamping uses "window" of valid values around the best estimated pixel value it has, up to that time. For instance:
1) When you start the rendering the estimate is 0.0 (black);
2) You add a sample (for instance with a value of 10.0) with clamping of 1.0, the pixel will now have a value 1.0 (10 was clamped between [0.0, 1.0]).
3) You add another sample (for instance with another value of 8.0) with clamping of 1.0, the pixel will now have a value (1.0 + 2.0)/2.0 (8 was clamped between [0.0, 2.0]).
4) You add another sample (for instance with another value of 11.0) with clamping of 1.0, the pixel will now have a value (1.5 + 2.5)/2.0 (11 was clamped between [0.5, 2.50]).
5) etc.
As you see, the +1/-1 clamping "window" will slowly move up to the correct result. This happen because the clamping value is small (
it is really too small in your test scene). Larger is the clamping value and faster it will move up (and vice versa). So there is warm up phase and larger is the clamping value and shorter it is (but more fire flies you are likely to have).
Why there is a difference between TILEPATH and normal PATH ? There is a difference in the length of warm up phase. This is due how TILEPATH anti-aliasing work. I assume you are using the default settings 16x16 tiles with 6 AA.
Just switch to something like 128x128 tiles with 1 AA and you will obtain a warm up period long (or better short) as the one in normal PATH.
This happens because variance clamping is applied after AA so you need quite few passes to catch normal PATH (where variance clamping is applied to each samples).
Re: tilepath and clamping... again
Posted: Thu Nov 01, 2018 5:30 pm
by lacilaci
Dade wrote: ↑Thu Nov 01, 2018 4:02 pm
lacilaci wrote: ↑Wed Oct 31, 2018 9:40 am
And one more thing, first pass with tiled has highlights clamped way more and then it continually gets brighter/more correct in next passes, is this normal?
Your problem is here, I will explain how it works and why you observing this result. Variance clamping uses "window" of valid values around the best estimated pixel value it has, up to that time. For instance:
1) When you start the rendering the estimate is 0.0 (black);
2) You add a sample (for instance with a value of 10.0) with clamping of 1.0, the pixel will now have a value 1.0 (10 was clamped between [0.0, 1.0]).
3) You add another sample (for instance with another value of 8.0) with clamping of 1.0, the pixel will now have a value (1.0 + 2.0)/2.0 (8 was clamped between [0.0, 2.0]).
4) You add another sample (for instance with another value of 11.0) with clamping of 1.0, the pixel will now have a value (1.5 + 2.5)/2.0 (11 was clamped between [0.5, 2.50]).
5) etc.
As you see, the +1/-1 clamping "window" will slowly move up to the correct result. This happen because the clamping value is small (
it is really too small in your test scene). Larger is the clamping value and faster it will move up (and vice versa). So there is warm up phase and larger is the clamping value and shorter it is (but more fire flies you are likely to have).
Why there is a difference between TILEPATH and normal PATH ? There is a difference in the length of warm up phase. This is due how TILEPATH anti-aliasing work. I assume you are using the default settings 16x16 tiles with 6 AA.
Just switch to something like 128x128 tiles with 1 AA and you will obtain a warm up period long (or better short) as the one in normal PATH.
This happens because variance clamping is applied after AA so you need quite few passes to catch normal PATH (where variance clamping is applied to each samples).
I see, so it is normal then(that heavily clamped first, or first few passes) cause I used heavy clamping value... One way or another, I found little to no use for tiled sampling altogether. In my opinion it should be gone to avoid user error and confusion.(maybe at least hidden away)
Re: tilepath and clamping... again
Posted: Thu Nov 01, 2018 7:18 pm
by kintuX
For now, GPU wise, only tilepath can...
Learn a thing or two about the fine balance in lighting & shading... then clamping & denoising suddenly become dispensable.
Credits
Team LuxCore 
Re: tilepath and clamping... again
Posted: Thu Nov 01, 2018 7:33 pm
by Dade
6000x6000 ... and in the mean time I feel guilty of "high-resolution" rendering when doing 640x480 ...
Re: tilepath and clamping... again
Posted: Sat Nov 03, 2018 12:17 am
by kintuX
Dade wrote: ↑Thu Nov 01, 2018 7:33 pm
6000x6000 ... and in the mean time I feel guilty of "high-resolution" rendering when doing 640x480 ...
Was a test to see what size i can squeeze out of LuxCore in one go, with 16GB RAM while i kept going (with Blender &
hungry FireFox running, consuming ~4GB). It performed really well. System was fluid and i could continue working as if nothing was going on.
Re: tilepath and clamping... again
Posted: Sat Nov 03, 2018 6:30 am
by lacilaci
Ok, but there is an issue when you look at the monkey in testscene or, screenshots in the original post right? Tilepath in beta1 does sample some high power samples and gives way stronger lighting than normal path. This results in fireflies in some cases.
PS: yes it would seem tilepath is indeed only option for very high res rendering.
Re: tilepath and clamping... again
Posted: Sat Nov 03, 2018 1:23 pm
by Dade
lacilaci wrote: ↑Sat Nov 03, 2018 6:30 am
Ok, but there is an issue when you look at the monkey in testscene or, screenshots in the original post right? Tilepath in beta1 does sample some high power samples and gives way stronger lighting than normal path. This results in fireflies in some cases.
As far as I can tell, it was only related to the "too small" clamping value, if you increase the value TILEPATH and PATH produce the same image.