OPTIX SDK Problem with Glass.cu example

I am working on a GPU problem of Ray Tracing and using the Glass.cpp example as a starting point in understanding OPTIX and CUDA. I replaced the wine glass with my own wine glass that contains an object of wine. Now the inside surface of the wineglass and outside surface of the wine are the same. Solidworks was used to create the objects, but when it converted the objects to a mesh (.WRL) the actual faces overlap each other. This causes the “Glass.CU” CUDA code to see the start of a new refraction (wine) before it sees the exit of the glass refraction. (See picture #1). Now I can solve the problem by reducing the XY model of the wine by say .95 and the problem goes away. (See picture #2). But I need to solve this problem without changing the model.

I think the solution is to change “glass.cu” to remember when it is ray tracing to handle both the exit of the old refraction and the start of the new refraction when it detects a new refraction before it was exited the old ray. Does anyone have any examples of solving the problem?

Here are my two pictures.


Ok, I have some more info on this problem. It seems to be in the “trangle_mesh_iterative.cu” CUDA code. I have attached a worst case example where SolidWorks output mesh can actually overlap with an example that shows the actually length of the refracted ray is not correct. I also included a 2D graph of the ray trace problem. The code tries to calculate the “refined hit point”, but always returns 0 because it uses only the face normal in the calculations. The “light blue” refined point is wrong. Also the surface normal is only calculated for the initial “hit_p” and not the “refined_hit_p”.

Does anyone know of a fix for this?

pipe_glass.bmp (1.5 MB)

mesh_graph.bmp (462 KB)

mesh_graph.bmp (32 KB)

I do some Optix myself, but this topic is way above my head. Have you tried the Optix forums?


Hello Russ. The problem demonstrated in your first post is to be expected.
The sample shaders we have provided are not sophisticated to robustly handle
degenerate geometry such as the overlapping geometry you describe.
Coplanar polygons will present similar problems as well.

One way to solve this problem would be to create a dielectric material program
which takes two indices of refraction and two color extinction terms – one for
inside the medium, one for outside the medium. That way you would not explicitly
model the liquid that is touching the sides of the cup, instead the interior of the
cup would have an interior_refraction_index for glass, and an exterior_refraction_index
for wine. Then you would create a mesh for the top surface of the wine (the wine/air
interface), and a mesh for the glass air interface. The downside to this method
is that you have to partition the model into its three separate material areas – air/glass,
air/wine, and glass/wine.

I am not sure I understand the issue you are describing in your 2nd post. The iterative
triangle intersection algorithm offsets the hit point in the direction of the geometric
normal, not the ray direction as your diagram would indicate. Which portion of the code
is “returning zero?”