OpenSubdiv
OpenSubdiv copied to clipboard
OpenSubdiv showed cracks after displacement
OpenSubdiv claimed water tight tessellation. I did some experiments to add displacement to check if OpenSubdiv is still water tight after displacement. I modified glslPatchCommon.glsl like the following:
ifndef OSD_DISPLACEMENT_CALLBACK
define OSD_DISPLACEMENT_CALLBACK output.v.position.xyz += 0.4 * output.v.normal; \
WorldPos = output.v.position.xyz;
endif
Basically add a constant displacement along normal. However, I did see some cracks, see one example below:
Any idea why it happens?
I don't think there is an option to turn on/off water tight tessellation. Is it correct?
Thanks
Sheng
We have not (yet ?) implemented the watertight part of the Loop / Meyer paper, although you can probably find a couple of vestigial details in Far. I think all our displacements have been using guttered ptex texels, and so far we haevn't noticed the kind of egregious cracking you are seeing in your example.
I'll try pasting your snippet in my glViewer and see if i can reproduce / get an idea of what's going on. This seems a little extreme for a simple floating point rounding error...
I can reproduce this. The problem seems significantly more prominent around Gregory patches : this is not entirely surprising given how the CVs of the patch are computed in the tess control / eval stages of the shader.
You can reduce this cracking quite a bit simply by isolating extraordinary features 2 or 3 levels, but i guess it's not going to be enough to get me off the hook for implementing the water-tight logic (which is somewhat expensive for real-time...)
PS: it looks like your viewer is missing some of the HUD - if you didn't remove this stuff, then it seems that you may be running off a fairly old version of our code...
To give an update, @takahito-tejima is still seeing this in the 3.0 codebase and had this to say:
This is likely a bug in gregory patch evaluation. It has to be C1 continuous, but we've seen one of the 4 edges of gregory patch show discontinuity and it ends up cracks when we apply displacement along normals.
Yesterday I thought George's fix might fix this issue, but I still saw that, so there's a bug somewhere else.
We'll continue to track this down.
Filed as internal issue #151682.