tilepath and clamping... again

Use this forum for general user support and related questions.
lacilaci
Posts: 346
Joined: Fri May 04, 2018 5:16 am

tilepath and clamping... again

Post by lacilaci » Wed Oct 31, 2018 6:49 am

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
Attachments
pathclamping.JPG
tilepathclamping.JPG

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: tilepath and clamping... again

Post by Dade » Wed Oct 31, 2018 9:02 am

I need a test scene showing the problem.
Support LuxCoreRender project with salts and bounties

lacilaci
Posts: 346
Joined: Fri May 04, 2018 5:16 am

Re: tilepath and clamping... again

Post by lacilaci » Wed Oct 31, 2018 9:40 am

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?
Attachments
tilepathclamping.blend
(1.04 MiB) Downloaded 1 time
path.jpg
tiled.jpg

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: tilepath and clamping... again

Post by Dade » 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).
Support LuxCoreRender project with salts and bounties

lacilaci
Posts: 346
Joined: Fri May 04, 2018 5:16 am

Re: tilepath and clamping... again

Post by lacilaci » Thu Nov 01, 2018 5:30 pm

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)

kintuX
Posts: 248
Joined: Wed Jan 10, 2018 2:37 am

Re: tilepath and clamping... again

Post by kintuX » Thu Nov 01, 2018 7:18 pm

:|
For now, GPU wise, only tilepath can...
Foods_0003-LuxCore_v2.1b1-raw(6K).jpg
Learn a thing or two about the fine balance in lighting & shading... then clamping & denoising suddenly become dispensable. :o
Credits Team LuxCore 8-)

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: tilepath and clamping... again

Post by Dade » Thu Nov 01, 2018 7:33 pm

6000x6000 ... and in the mean time I feel guilty of "high-resolution" rendering when doing 640x480 ...
Support LuxCoreRender project with salts and bounties

kintuX
Posts: 248
Joined: Wed Jan 10, 2018 2:37 am

Re: tilepath and clamping... again

Post by kintuX » Sat Nov 03, 2018 12:17 am

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. 8-)

lacilaci
Posts: 346
Joined: Fri May 04, 2018 5:16 am

Re: tilepath and clamping... again

Post by lacilaci » 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.

PS: yes it would seem tilepath is indeed only option for very high res rendering.

User avatar
Dade
Developer
Posts: 1458
Joined: Mon Dec 04, 2017 8:36 pm

Re: tilepath and clamping... again

Post by Dade » Sat Nov 03, 2018 1:23 pm

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.
Support LuxCoreRender project with salts and bounties

Post Reply