I see, yes this is different from the mesh stitching. Did you try enabling the
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
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.