Hi,
I have a model made of nurbs surfaces. The individual faces making up the geometry are not connected. The resulting mesh of these surfaces is as shown in the figure.
I have so far been able to capture all the intersections properly.
But I face an issue along the borders. I see the rays leaking in between the surfaces as shown in red arrows.
Could you please let me know if there’s a way to avoid this?
Hi @m_cn, welcome!
OptiX and RTX does provide a “water-tightness” guarantee when ray tracing the triangles that make up any given single mesh. This means that rays will not be able to sneak through the edge between any two adjacent triangles, provided that they share exactly the same vertices along the edge in question.
The guarantee does not apply to meshes in different acceleration structures, especially if they represent instances with different transforms. And the guarantee does not apply to the border between two meshes when the edges & vertices along the border are not actually shared or the same.
Based on the image, this appears to be the main problem you have - correct me if I’m wrong, but it looks like the sampling of vertices and edges along the lower border of the light blue mesh are different from the vertices and edges of the lower white mesh. First the cracks need to be sealed in theory - small actual holes in the mesh definition cannot be fixed. This might be a little tricky, but you need to ensure you’re making the same sampling and tessellation decisions along the shared border between two meshes. This might require some tessellation planning and/or special data structures for sharing information along edges.
You don’t necessarily have to share the actual vertices in memory, but you do have to produce the same vertex values & edges on both sides of the border. By “the same” I mean that the duplicate/shared vertices along the border must be bitwise identical floating point values in order to have the water-tightness guarantee. Getting to bitwise exact can sometimes require a close examination of the order of math instructions used during tessellation, as well as disabling fast-math features during compilation. It may be easier to refer to the shared vertices in memory, or to copy vertices from one mesh’s border to the other after tessellation if there are any differences.
Since the holes look relatively large in the image, I’d guess that in your case you might be able to get sufficiently close to what you need by solving the sampling problem first, without necessarily locking down water-tightness completely. That depends on your tolerance, of course, whether strictly zero leaked rays are required, or if significantly reducing the current problem is enough (say, by a factor of a million).
–
David.
dhart Thank you so much for such a detailed response!
Yes, you are right! The leaks are only along the edges with different sampling of vertices. Could be some effort to produce duplicate/shared vertices with bitwise identical floating point values but should definitely fix the problem.
And of course significantly reducing the current problem should be good enough :)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
