Sampler seems to be buggy about three.js-pathtracing-renderer

[erichlof]

Hi @PtrMan
Could you please tell me which demo and which part of that scene is not converging? In this project I choose speed over ground truth convergence so as to keep the rendering real-time. Having a view inside a mirror reflection of caustics on another diffuse surface that correctly converges would require a deeper light bounce count. In order to speed up the path tracing loop, I often cap the bounce depth to 3 or 4 depending on the surface. To converge what I think that you are referring to would require a bounce depth of 6 or 7. It would still be slow to converge as the reflective surfaces are sampled in a fashion similar to Kevin Beason's smallpt (the original inspiration for this project) - that is, instead of rendering both paths of reflective vs refractive bounces, the renderer chooses at random which path to take every frame. This allows all the rays to be done with their work around the same time which keeps thread occupancy high on the GPU. To correctly follow and render both paths of caustics inside of reflections would increase thread divergence - some non-caustic rays would be done early and they would have to wait for the caustics rays to be done with their work before advancing to the next animation frame.

This is why on most rendering software the preview is liquid smooth and somewhat noisy, but when you leave it still to do the detailed final render, the frame rate hiccups and decreases. I experimented with this style of rendering, but found that pulling the mouse-look out of detailed rendering mode hurt the interactivity of the web-style app too much.

[erichlof]

Hi @PtrMan ,

I just wanted to give you an update. I have replaced the old sampler that was using the one-liner random number generator, fract(sin(seed * large number)) that you find everywhere on the internet searching for 'fast RNGs for GPUs' (GPUs don't have them, you must create your own).
I replaced it with a RNG from iq on ShaderToy, that uses WebGL 2.0 newly-supported functionality of integer hashing using bit shifting and bit manipulations inside the GPU fragment shader. The result is that the Monte Carlo sampling is much cleaner, more random, and has less visual artifacts than the old RNG.

I'm going to go ahead and close out this issue because the new sampler should take care of caustics if you let the path tracer run for a long enough time.
-Erich