Occasionally missing triangles at certain view direction and object coordinates

I tried to work with blender exported OBJ files as triangle source, but ended up with a strange artifact occuring at some view directions.

The following GIF shows (uv.x, uv.y, depth) of the closest hit position as result, you can see at certain angles that some parts of triangles are missing and the ray hits the triangles behind.


Here’s a closer view:


These artifacts seems always occurs at planes where some dimension of the object coordinate is 0. (in example, no transform is applied, but artifacts occurs at same relative position after transforms)

What can be the potential causes of this artifact?

I’m working on an minimum example but it take some time, I’ll update this post as soon as it came out.

What strikes me in that animation is the short rectangular looking corruption which could be from AABBs inside the acceleration structure.
It would be simpler to see what is going on if you only visualized the intersection distance.
To isolate that more:
What are the absolute intersection distance values at the front and back of the sphere?
(You could dump the intersection distances into a buffer or add some code which prints that value for the launch index under the mouse cursor and move the cursor in an out of the area where you see the corruption.)
How is that mapped to the blue channel range?
If this is view dependent

  • Is there an anyhit program which calls optixIgnoreIntersection or optixTerminateRay in that SBT hit record?

Here’s a visualization using color = pow(depth * 0.2, 1/2.2). The scene has only an unit sphere and is captured with a perspective camera with fov = 36, znear = 1e-2, zfar = 1e2.


I do use the OPTIX_RAY_FLAG_TERMINATE_ON_FIRST_HIT flag thus there’s no anyhit program. After switching to OPTIX_RAY_FLAG_NONE the artifacts disappears, but I have no idea why.

The order in which the acceleration structure BVH is traversed is not along the ray direction which makes it view dependent.
If you use OPTIX_RAY_FLAG_TERMINATE_ON_FIRST_HIT it will report the very first hit, which is not necessarily the closest hit.
The same is happening for anyhit program invocations which are also not in ray direction order.

Means OPTIX_RAY_FLAG_TERMINATE_ON_FIRST_HIT should not be used if you require the closest hit!
It is meant to be used for a binary visibility decision, for example, as a faster alternative to an anyhit program which unconditionally calls optixTerminateRay as used for shadow rays on opaque objects.

Read these two threads explaining that as well:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.