Hello,
at the moment, I’m playing around with the given displacement samples in optix 3.9.2 and 5.1.1. If I higher the tessellation rate to something above four and leave the code as it is, the mesh starts to show artifacts, mostly missing triangles. What’s the reason behind that?
Thank you in advance!
Hi, welcome @Persynphony!
The mesh that gets built in the displacement sample isn’t stitched, so it always has cracks, even with the default displacement values. This sample should just be thought of as a demonstration of using MDL with OptiX in the context of tessellation, not an example of producing watertight meshes.
–
David.
Hello David,
thank you for your answer! That’s true but I think I mean another phenomenon. I tried your code on a plane (2 triangles).
I don’t want a solution I’m just trying to figure what could be the problem here and would we grateful for any suggestions :)
[Edit] I forgot to mention that the tessellation rate is 16 and if you use 4 as a tessellation rate there are no disappearing triangles.
I see, yes this is different from the mesh stitching. Did you try enabling the USE_BRUTE flag?
I don’t have a concrete answer. My guess is that either there are some hard-coded assumptions in the sample based on the value of DISPLACE_N, or there is just a bug in the intersection function. It may be that you can’t safely increase DISPLACE_N without updating other parts of the code in geometry_programs.cu.
It’s worth noting that intersect_displaced_tri contains a loop over DISPLACE_N number of triangles, suggesting that a high value for this number was never intended. It also has to consider the neighbors of the cells visited, and the logic is not trivial. I don’t see any bugs immediately, but looking at the code, it doesn’t surprise me if there are limits you bump into by increasing the tessellation. Be careful with USE_BRUTE because its run time is the cube of DISPLACE_N – this is another clue that DISPLACE_N isn’t really meant to go as high as 32, it’ll cause traverse_displaced_brute to have something like 16k iterations per thread, where the default value of 4 would only be ~32 iterations.
Unfortunately the author of that sample isn’t available for questions, so if it’s critical to get this working, I would say the best course of action is to dive into the intersect functions and map it out so you can understand it well enough that the reason for the missing intersections becomes apparent.
By the way, this sample is pretty old now, and the structure of it is probably not recommended as a template for tessellation. If you want good render performance and have an RTX GPU now or in your future, pre-tessellating and using the hardware intersector is going to be much faster than a custom software traversal – as long as you can afford the memory.
–
David.
