rendering artifact about three.js-pathtracing-renderer

[erichlof]

@dafhi
Hi again, I was able to mitigate the problem by decreasing the amount of the "nudge" that I give to each newly spawned ray origin along the path. EPS_Intersect was previously set at 0.1 units times the normalized surface normal vector, nl. For instance, r.origin += nl * EPS_Intersect. Which essentially pushed the new ray's origin out along the surface normal the distance of 0.1 units. I changed the precision to be higher on desktop (not much I can do about mobile at the moment with how most cell phones' chips are manufactured in 2019, so it remains at a whopping 1.0 units). Now EPS_Intersect is 0.01 on desktop so the ray origins get nudged just 0.01 units along the surface normal.

The old artifact of the bright white line around the red cylinder where it meets the ground is all but gone now. It is ever so slightly still there, but you would have to be looking for it. Depending on your machine, you can try more precision, say 0.001 but on my humble machines, when I asked for too much precision, black spots started to appear on diffuse and coated surfaces like the checkered ground and white capsule, due to incorrect self intersection of newly spawned rays with the surfaces they had just intersected before.

You can give it a try: Geometry showcase demo

I am in the process of applying the most precision I can to some of the other demos (like the CSG museum demos) in order to guard against similar artifacts. Thanks for bringing this issue to my attention, I had just kind of forgotten about it, but now I think I ended up finding a good balance between artifacts and machine precision.

[erichlof]

@dafhi
Hello, yes this artifact popped up back when I combined the refracted (transmitted) ray's contribution to the reflected ray's contribution, in order to capture a realistic double image (like when you look through a window at an angle) that is smooth and real time without any grainy noise as you move the camera around. The old way of doing things was to randomly pick a transmitted or reflected ray each time the camera ray hit a refractive object. Although this eventually gives the right answer for progressive rendering (over many frames) according to Monte Carlo integration, it resulted in objectionable noise of the double image on all refractive objects such as glass, water, clear plastic, etc. if the camera was moving or, for instance, water waves were moving up and down.

The issue that you refer to stems from each new ray's origin point and the lack of machine precision. When the initial ray hits the refractive surface, I have to nudge the transmitted ray forward or through the surface a little so it doesn't self intersect, and likewise I must nudge the reflected ray backwards or out of the surface also to avoid self intersection. If you take away the nudge by commenting out the line: ' firstRay.origin += nl * EPS_Intersect ', the artifacts disappear - however if you now fly the camera above the glass coffee table, the reflected image of the large light spheres in the glass of the table now has many artifacts! Again due to lack of machine precision. Frustrating to say the least.

I am currently investigating this problem - I'll let you know if I can resolve it somehow. I think it was always there, but it used to be conveniently masked by the noise of the random ray choice for refraction or reflection. The artifact can no longer hide behind that noise, because it is a solid (and physically correct) double image now. :)

Thanks!

[dafhi]

huge improvement!

i'll consider the issue closed but let you decide. there may be a possibility of reformulation to make float precision a non-issue. beyond me atm :)