In the environment depicted below, intersection checks (from every origin, in every direction) fail for the two large triangles using the standard BVH implementation. When stepping through the BVH iterator sequentially, the primitives which contain these two triangles are (sometimes) not reached.
I've set up an MRE which constructs a BVH of the 4 triangles in the environment below and then performs intersection checks downwards from positions above the triangles' centers. These intersections should in theory never fail, but they do. The problem occurs non-deterministically, which leads me to believe there is a small bug in the BVH construction step or in the BVH iterator.
Notes:
3 triangles have two axis-aligned edges and 1 triangle has one axis-aligned edge.
All triangles are sufficiently large enough to the point where floating point inaccuracies should not matter.
I have not tested this environment in the MBVH implementation, since it has been unstable for us in larger environments. For more information refer to @stijn-ucrowds's issue.
Issue:
In the environment depicted below, intersection checks (from every origin, in every direction) fail for the two large triangles using the standard BVH implementation. When stepping through the BVH iterator sequentially, the primitives which contain these two triangles are (sometimes) not reached.
I've set up an MRE which constructs a BVH of the 4 triangles in the environment below and then performs intersection checks downwards from positions above the triangles' centers. These intersections should in theory never fail, but they do. The problem occurs non-deterministically, which leads me to believe there is a small bug in the BVH construction step or in the BVH iterator.
Notes:
How to reproduce:
cargo test -- --nocapture. The test will run for 10 iterations.