Page MenuHome

Cycles: improve ray tracing precision near triangle edges
ClosedPublic

Authored by Brecht Van Lommel (brecht) on Jul 27 2022, 9:28 PM.
Tags
None
Tokens
"Pterodactyl" token, awarded by shader."Like" token, awarded by hitrpr."Love" token, awarded by Raimund58."Love" token, awarded by Alaska.

Details

Summary

Detect cases where a ray-intersection would miss the current triangle, which if
the intersection is strictly watertight, implies that a neighboring triangle would
incorrectly be hit instead.

When that is detected, apply a ray-offset. The idea being that we only want to
introduce potential error from ray offsets if we really need to.

This work for BVH2 and Embree, as we are able to match the ray-interesction
bit-for-bit, though doing so for Embree requires ugly hacks. Tiny differences
like fused-multiply-add or dot product intrinstics in matrix inversion and ray
intersection needed to be matched exactly, so this is fragile.

Unfortunately we're not able to do the same for OptiX or MetalRT, since those
implementations are unknown (and possibly impossible to match as hardware
instructions).

It may be possible to find a heuristic with some larger error threshold that
works for OptiX and MetalRT, but so far I've been unsuccesful.

Diff Detail

Repository
rB Blender
Branch
ray-edge (branched from master)
Build Status
Buildable 23311
Build 23311: arc lint + arc unit

Event Timeline

Brecht Van Lommel (brecht) requested review of this revision.Jul 27 2022, 9:28 PM
Brecht Van Lommel (brecht) created this revision.

Test file from T97259:

EmbreeCUDA (BVH2)OptiX
Old
New

As a general note regarding self intersection, it feels like that should be a solved problem in the literature. But for example in the relatively recent A Fast and Robust Method for Avoiding Self-Intersection, the proposed solution is to use the same ray offset mechanism that we used before.

It relies on object and camera transforms being applied to mesh vertices to be robust. In final renders we already apply object transforms, and we could consider doing the same for camera transforms though that would add a fair amount of complexity to shading. However none of that works for instancing as in the test file, and would have poor performance in interactive 3D viewports.

There is also the case of exactly overlapping faces that we don't handle very well right now, though the same artifacts will appear in the 3D viewport with rasterization, so in that sense it's relatively predictable. We could potentially solve that by rejecting intersections at the exact same distance as the current triangle (perhaps by increasing tmin to exactly 1 bit beyond it). But this again relies on being able to match the triangle intersection bit-for-bit.

CC @Patrick Mours (pmoursnv) in case you have any interesting ideas for OptiX here.

Fix hardcoded assumptions about SSE/AVX instructions, do proper runtime checks

Brecht Van Lommel (brecht) retitled this revision from Cycles: improve ray tracing precision near triangle edges [WIP] to Cycles: improve ray tracing precision near triangle edges.Aug 8 2022, 7:10 PM

Make it work also when not using native only kernels

This revision was not accepted when it landed; it landed in state Needs Review.Aug 9 2022, 7:19 PM
This revision was automatically updated to reflect the committed changes.