<p>According to the <a href="http://www.pbr-book.org/3ed-2018/Introduction/pbrt_System_Overview.html#IntegratorInterfaceandSamplerIntegrator" rel="nofollow noreferrer">description in the book</a>, <code>Scene::IntersectP()</code> "checks for the existence of intersections along the [passed] ray". This operatorion should be symmetric in the sense that if <code>i1</code> and <code>i2</code> are <code>pbrt::Interaction</code>'s, then <code>scene.IntersectP(i1.SpawnRayTo(i2))</code> should be <code>true</code> if and only if <code>scene.IntersectP(i2.SpawnRayTo(i1))</code> is true.</p>

<p>However, I've encountered the following contradiction to this expectation: For two <code>pbrt::Vertex</code>'s <code>x1</code> and <code>x2</code>, <code>pbrt::VisibilityTester{ x1.GetInteraction(), x2.GetInteraction() }.Unoccluded(scene)</code> and <code>pbrt::VisibilityTester{ x2.GetInteraction(), x1.GetInteraction() }.Unoccluded(scene)</code> returned opposite values. Since <code>VisibilityTester::Unoccluded</code> does nothing else than calling <code>Scene::IntersectP</code> in the previously described way (see the <a href="http://www.pbr-book.org/3ed-2018/Light_Sources/Light_Interface.html#VisibilityTesting" rel="nofollow noreferrer">description in the book</a>), it seems like I'm missing something crucial here.</p>

CC BY-SA 4.0
2020-02-16T19:51:10.580Z
Could it be due to numerical issues for ray-triangle intersection?
Hubble
CC BY-SA 4.0
2020-02-16T20:09:23.357Z
@Hubble Well, hard to say, but I guess the error indeed depends on the surface the ray hits.
0xbadf00d
CC BY-SA 4.0
2020-02-16T20:13:29.353Z
I wouldn't be surprised if the visibility tester is inconsistent if you test on a scene with complex meshes with high-frequency details. Maybe try with two triangles facing each others, or reduce the robustness epsilon, and see if the problem is still there.
Hubble
CC BY-SA 4.0
2020-02-16T20:25:28.730Z
@Hubble I don't know if you're familiar with it, but I've tested it with the "sample.pbrt" scene in PBRT which is as simple as possible: https://i.sstatic.net/txaN0.png.
0xbadf00d
CC BY-SA 4.0
2020-02-17T18:07:45.883Z
Huddle is certainly right: It might be due to numerical issues for the ray-triangle intersection. PBRT offset the spawned ray (https://github.com/mmp/pbrt-v3/blob/9f717d847a807793fa966cf0eaa366852efef167/src/core/interaction.h#L73) to avoid such issue. However, there is no silver bullet here.
Beltegeuse
<raytracing><physically-based><global-illumination><pbr><pbrt>
Is casting a shadow ray non-symmetric in pbrt?
0xbadf00d
# Is casting a shadow ray non-symmetric in pbrt?

(Asked by: username_0 on 2020-02-16)

According to the [description in the book](http://www.pbr-book.org/3ed-2018/Introduction/pbrt_System_Overview.html#IntegratorInterfaceandSamplerIntegrator), `Scene::IntersectP()` "checks for the existence of intersections along the [passed] ray". This operatorion should be symmetric in the sense that if `i1` and `i2` are `pbrt::Interaction`'s, then `scene.IntersectP(i1.SpawnRayTo(i2))` should be `true` if and only if `scene.IntersectP(i2.SpawnRayTo(i1))` is true.

However, I've encountered the following contradiction to this expectation: For two `pbrt::Vertex`'s `x1` and `x2`, `pbrt::VisibilityTester{ x1.GetInteraction(), x2.GetInteraction() }.Unoccluded(scene)` and `pbrt::VisibilityTester{ x2.GetInteraction(), x1.GetInteraction() }.Unoccluded(scene)` returned opposite values. Since `VisibilityTester::Unoccluded` does nothing else than calling `Scene::IntersectP` in the previously described way (see the [description in the book](http://www.pbr-book.org/3ed-2018/Light_Sources/Light_Interface.html#VisibilityTesting)), it seems like I'm missing something crucial here.

**Tags:** raytracing, physically-based, global-illumination, pbr, pbrt

> **Comments:**
> **username_1**: Could it be due to numerical issues for ray-triangle intersection?  
> **username_0**: @username_1 Well, hard to say, but I guess the error indeed depends on the surface the ray hits.  
> **username_1**: I wouldn't be surprised if the visibility tester is inconsistent if you test on a scene with complex meshes with high-frequency details. Maybe try with two triangles facing each others, or reduce the robustness epsilon, and see if the problem is still there.  
> **username_0**: @username_1 I don't know if you're familiar with it, but I've tested it with the "sample.pbrt" scene in PBRT which is as simple as possible: https://i.sstatic.net/txaN0.png.  
> **username_2**: Huddle is certainly right: It might be due to numerical issues for the ray-triangle intersection. PBRT offset the spawned ray (https://github.com/mmp/pbrt-v3/blob/9f717d847a807793fa966cf0eaa366852efef167/src/core/interaction.h#L73) to avoid such issue. However, there is no silver bullet here.  

---

## 0 answers

