Path Space Regularization (aka the solution to SDS paths)

[lacilaci]

It is not supposed to be different from CPU rendering

But this is a bug right? Like, not seeing caustics in shallow water or whatever is the issue...

There is currently a problem: it is like if SDS paths "eat" caustic paths in term of importance from Metropolis point of view (i.e. Metropolis renders only SDS paths if they are enabled).

But sds are still not converging anyways, that's another issue right?

I have not been able to make an example where I would obseve any convergence at all no matter how long I render, this looks the same in 200 or 7000 samples:

sds stay blurry and dark and only some fireflies appear...

this is how sharp it should look underwater

for better comparison this is pathcpu+metropolis with 1000 samples(lacks volume absorption but demonstrates how sharp it should be):

[epilectrolytics]

so I'd like to try out PSR with pure (backward) Path Trace + Metropolis

PSR is used only for SDS paths in light tracing (on the last path vertex <=> eye connection). Using PSR only for SDS paths in backward path tracing (on the last path vertex <=> light connection) would produce exactly the same result: the paths are perfectly symmetrical.

Exactly same result, yes, but if it was possible to do it with PathOCL instead of LightCPU wouldn't it render way faster?
Or is there some OpenCL restriction versus the CUDA implementation from the paper?

[Dade]

Exactly same result, yes, but if it was possible to do it with PathOCL instead of LightCPU wouldn't it render way faster?

Using Metropolis is mandatory to get anything meaningful out of path space regularization and Metropolis works really bad on GPUs.

[provisory]

...Metropolis works really bad on GPUs.

Can any of these help?

- Coherent metropolis light transport on the GPU using speculative mutations
https://www.semanticscholar.org/paper/C ... 2b4d983429

The Metropolis Light Transport algorithm generates physically based images with superior image quality than classical ray tracing. Although it is trivially parallelizable on GPUs by running N MLTs, the performance on current graphics hardware is below par. One of the main problems is the set of incoherent paths due to the independent Markov chains. Since each MLT generates full paths and mutates them sequentially, we construct totally incoherent rays which in negatively affects the performance on the GPU. By using a novel speculative variant of the Metropolis algorithm we increase the similarity of paths and achieve higher coherence. This decreases the computation time significantly. Further, we improve memory access by optimizing the data layout to better utilize coalesced access.

- Memory-compact Metropolis light transport on GPUs
https://www.semanticscholar.org/paper/M ... f1e33588de

Solutions to the key problems of Metropolis light transport implementation on GPUs are proposed. A “burn-in” method relying on the ordinary Monte Carlo method, owing to which the “startup bias” is significantly reduced, is suggested. Memory optimizations methods (including multiple proposal Metropolis light transport) are proposed, and technical aspects of efficient Metropolis light transport implementation on GPUs are discussed.

[provisory]

- Glass volume absorption gets very saturated during Light Tracing with PSR

Do you have an example ?

- It seems to me, that Light Tracing and Path Tracing brightness add up in some cases, so (without clamping) Hybrid becomes brighter than BiDir or simple Path tracing.

Do you have an example ?

I think now, that these were because of too large PSR scale.

Path/Metropolis:

Rook-Path-Metro.jpg (14.93 KiB) Viewed 5131 times

Hybrid PSR with scale 1:

Rook-Hybrid-PSR-scale-1.jpg (16.21 KiB) Viewed 5131 times

Hybrid PSR with scale 0.05:

Rook-Hybrid-PSR-scale-0_05.jpg (16.45 KiB) Viewed 5131 times

[Dade]

There is currently a problem: it is like if SDS paths "eat" caustic paths in term of importance from Metropolis point of view (i.e. Metropolis renders only SDS paths if they are enabled).

It was a general problem in handling glossy surfaces, I have fixed the problem.

[Dade]

The results aren't bad:

Note: total samples/pixel can be quite misleading when rendering with GPU+CPU light tracing, LuxCoreUI now shows separate stats for eye and light samples too:

So you can have an idea of how many light tracing passes you have really done.

[lacilaci]

The results aren't bad:


pool.jpg


Note: total samples/pixel can be quite misleading when rendering with GPU+CPU light tracing, LuxCoreUI now shows separate stats for eye and light samples too:


stats.jpg


So you can have an idea of how many light tracing passes you have really done.

how about large scale scene and how about homogenous volumes? Will this render juice in glass?

[Dade]

how about large scale scene and how about homogenous volumes?

Never tried, I will try to set the above scene water volume to homogeneous and see what happen.

Will this render juice in glass?

99.99% isn't going to be worth the effort: I mean, If the juice glass is just few pixels in a large scene, there are many other tricks to deliver the result without paying the costs associated with a more complex rendering (PSR will be slower and more complex to set up).

[lacilaci]

Will this render juice in glass?

99.99% isn't going to be worth the effort: I mean, If the juice glass is just few pixels in a large scene, there are many other tricks to deliver the result without paying the costs associated with a more complex rendering (PSR will be slower and more complex to set up).

so... hybrid glass?