opened
fluidray
username_0
Hello Embree Team,
I'm using the same subdivision level for shared edges, but different subdivision levels for edges that are not shared. As you can see from the pictures, cracks appear along the shared edge, as well as inside the subdivided triangles. 
I attached the modified displacement_tutorial that reproduces the issue.

![cracks](https://user-images.githubusercontent.com/12939099/81922886-11f80780-95dd-11ea-922e-34c228267919.jpg)

[displacement_geometry_device.zip](https://github.com/embree/embree/files/4627599/displacement_geometry_device.zip)
Cracks with displacement 
issue
created
cbenthin
username_1
Looked into that right now and I think the subdiv-levels per edge are wrong in the example. The shared edge has indices 1 + 4. The 1+4 shared edge is the first edge in the first triangle and the second edge in the second triangle. The "cube_levels_array" should therefore be:

float cube_levels[6] = {
	3, 6, 6, 8, 3, 8
};

Where the shared edge has subdiv-level "3" assigned, while non-shared edges have either "6" or "8" assigned. Can you double-check that.

Thanks.
comment
created
fluidinteractive
username_2
Yes, you are correct, the shared edge indices were wrong, the array should be:

float cube_levels[6] = {
  3, 6, 6, 6, 3, 6
};

Correcting the error, the problem is still there, notice the crack in the middle of the subdivided triangle in the projected shadow. 

![Screen](https://user-images.githubusercontent.com/63602865/82229773-26186d80-992b-11ea-8e59-c090448910e4.jpg)

Here's the updated file:

[displacement_geometry_device.cpp.zip](https://github.com/embree/embree/files/4645009/displacement_geometry_device.cpp.zip)
comment
created
cbenthin
username_1
OK, I think I've found the issue. If you compile from source please replace the following line in kernels/subdiv/patch_eval_grid.h (around line ~238)

          const float levels1[4] = { 0.5f*levels[(i+0)%N], 0.5f*levels[(i+0)%N], 0.5f*levels[(i-1)%N], 0.5f*levels[(i-1)%N] };

with

          const float levels1[4] = { 0.5f*levels[(i+0)%N], 0.5f*levels[(i+0)%N], 0.5f*levels[(i+N-1)%N], 0.5f*levels[(i+N-1)%N] };

That should fix the wrong tessellation. We'll include the fix in the next release.
comment
created
fluidray
username_0
The change seems to have fixed the problem. There is still a very thin crack that is always a pixel wide, independent on the zooming, maybe it's an intersection precision issue:

![crack](https://user-images.githubusercontent.com/12939099/82438051-b922e600-9a98-11ea-9464-da06c5519f66.jpg)
comment
closed
cbenthin
username_1
issue
created
cbenthin
username_1
Yes, that's likely an intersection precision issue. 
Thanks again for pointing out the issue. I'm closing it for now. Please reopen or fill a new one if you run into more issues.
comment
created
fluidinteractive
username_2
Great. Thanks for fixing the issue so quickly.
comment