Yes sorry Detlef there wasn’t much info there. Was hoping you’d say, “oh well if that happens you’re obviously doing X wrong” :)
I get the same results across the following configurations:
- geforce 750m, macOS 10.13, driver 387, optix 5.0.0
- geforce 750m, ubuntu 16.04, driver 390, optix 5.0.0 and optix 5.1.0
- geforce 1080ti, ubuntu 16.04, driver 390 & 410, optix 5.0.0 (tested programs compiled with both sm_30 and sm_60)
It’s the same regardless of whether I use the refining intersection, the non-refining variant, or a simple one I copied from the github repo you link:
RT_PROGRAM void mesh_intersect(int primIdx) {
const int3 v_idx = index_buffer[primIdx];
const float3 p0 = vertex_buffer[v_idx.x];
const float3 p1 = vertex_buffer[v_idx.y];
const float3 p2 = vertex_buffer[v_idx.z];
// Intersect ray with triangle
float3 n;
float t, beta, gamma;
if (intersect_triangle(ray, p0, p1, p2, n, t, beta, gamma)) {
if (rtPotentialIntersection(t)) {
shading_normal = geometric_normal = normalize(n);
rtReportIntersection(0);
}
}
}
Adding some printfs I get the following, which seems fine at first glance (note I switched from a perspective camera to a simple orthographic just to rule out the perspective matrix doing something weird):
[bound] 0 area: 54449.996094
[bound] 1 area: 54449.996094
[bound] 2 area: 54449.996094
[bound] 3 area: 54449.996094
[bound] 0 (80.000000, 0.000000, -295.000000) -> (245.000000, 330.000000, -295.000000)
[bound] 1 (80.000000, 0.000000, -295.000000) -> (245.000000, 330.000000, -295.000000)
[bound] 2 (80.000000, 0.000000, -130.000000) -> (245.000000, 330.000000, -130.000000)
[bound] 3 (80.000000, 0.000000, -130.000000) -> (245.000000, 330.000000, -130.000000)
----
prim: 0 p0: (245.000000, 330.000000, -295.000000)
p1: (245.000000, 0.000000, -295.000000)
p2: (80.000000, 0.000000, -295.000000)
ray.origin: (127.910156, 238.476562, 0.000000)
ray.direction: (0.000000, 0.000000, -1.000000)
miss
----
prim: 1 p0: (80.000000, 330.000000, -295.000000)
p1: (245.000000, 330.000000, -295.000000)
p2: (80.000000, 0.000000, -295.000000)
ray.origin: (127.910156, 238.476562, 0.000000)
ray.direction: (0.000000, 0.000000, -1.000000)
hit
t: 295.000031
beta: 0.290365
gamma: 0.277344
n: (0.000000, 0.000000, -54450.000000)
Note that prim 2 and prim 3 are never considered, even though their bounding boxes show they’re clearly closer to the ray origin than 0 and 1. Then if I switch the order of the prims so 2 and 3 come first in the index buffer:
[bound] 0 area: 54449.996094
[bound] 1 area: 54449.996094
[bound] 2 area: 54449.996094
[bound] 3 area: 54449.996094
[bound] 0 (80.000000, 0.000000, -130.000000) -> (245.000000, 330.000000, -130.000000)
[bound] 1 (80.000000, 0.000000, -130.000000) -> (245.000000, 330.000000, -130.000000)
[bound] 2 (80.000000, 0.000000, -295.000000) -> (245.000000, 330.000000, -295.000000)
[bound] 3 (80.000000, 0.000000, -295.000000) -> (245.000000, 330.000000, -295.000000)
----
ray.origin: (127.910156, 238.476562, 0.000000)
ray.direction: (0.000000, 0.000000, -1.000000)
prim: 0 p0: (80.000000, 0.000000, -130.000000)
p1: (245.000000, 0.000000, -130.000000)
p2: (245.000000, 330.000000, -130.000000)
miss
----
ray.origin: (127.910156, 238.476562, 0.000000)
ray.direction: (0.000000, 0.000000, -1.000000)
prim: 1 p0: (80.000000, 0.000000, -130.000000)
p1: (245.000000, 330.000000, -130.000000)
p2: (80.000000, 330.000000, -130.000000)
hit
t: 130.000000
beta: 0.290365
gamma: 0.432292
n: (-0.000000, 0.000000, 54450.000000)