Improve surface point offsetting to prevent self-intersection#1871
Open
dongclin wants to merge 1 commit intomitsuba-renderer:masterfrom
Open
Improve surface point offsetting to prevent self-intersection#1871dongclin wants to merge 1 commit intomitsuba-renderer:masterfrom
dongclin wants to merge 1 commit intomitsuba-renderer:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR propose a robust, scale-invariant offsetting technique based on Ray Tracing Gems ("A Fast and Robust Method for Avoiding Self-Intersection") in Chapter 6. (6.6.2.4) to the current ray offset mechanism.
The Problem: Static
RayEpsilonCurrently, Mitsuba's ray offset calculation uses a fairly generous static RayEpsilon to modify the origins of spawned rays. This constant approach frequently runs into issues in high-precision use cases where important intersections of nearby surfaces may be "missed."
A concrete example is rendering a realistic human eye: the distance between the inner eye structures and the cornea is often smaller than the default RayEpsilon, causing the renderer to skip critical intersections and produce noticeable rendering artifacts. Other renderers (e.g., Blender Cycles) seem to handle this case more robustly
Visual Comparison
To demonstrate the precision of the adaptive offsetting, I use two spheres at the origin:
mi.math.RayEpsilon)In the current version, it fails to find the intersection of the inside sphere due to the generous epsilon, leading to the light leaking. With adaptive offsetting, we could have the two sphere been rendered.
Testing
Existing tests have been executed. I observed some failures during the process; however, these appear to be strictly related to the CUDA environment/drivers on the test machine rather than the core logic of this implementation.
Checklist
cuda_*andllvm_*variants. If you can't test this, please leave below