Getting around non-connected vertex gaps in hardware tessellation displacement mapping

Started by
20 comments, last by windschuetze 9 years, 4 months ago

I solved my problem! I had serveal bugs:

  • filling the edge map: indices[indices] instead of indices...

  • I removed the hashing of the index and it worked!

Thank you very much, I couldn't have done it without your help!

Now my cube looks smooth and crackfree:

screenshot16111.png

Advertisement


It's Rocko!

Ah yes, haha, remember watching that in the mid-late 90's. Maybe worth a rewatch now that I'm old enough to actually understand it better than back then...

As for the displacement mapping I eventually settled on a rather simple approach for use with pre-existing triangle list meshes (it is by no means perfect but it seems that the "real" solution is really just having the 3D / texturing artist(s) being aware of your intents and have them author appropriately mapped bump maps and ensure corners actually are rounded, albeit with extremely short edges between corner vertices, as seemed to be the main point that the chapter in Zink, Pettineo & Hoxley (2011) as referred by unbird in the last post). Basically I average all disjoint vertex normals and create a 6-control patch index buffer that holds the initial triangle in the first 3 indices and then any "dominant" vertices sharing the position of these original vertices in the last 3 indices. The dominant vertices are arbitrarily chosen as the first found in the vertex data for a given position and are set to the same vertex as in the first three indices if there are no shared vertices at a given position. The dominant vertex is used to ensure that all overlapping vertices will sample the same value from the displacement map, while still allowing them to sample other textures by their UV coords.

Not perfect but good enough for some general-purpose examples.

As for actually employing this kind of displacement mapping in a more professional game / visual demo / what-have-you, the artist should ensure that there are *no* disjoint vertices (as said, such vertices can be moved slightly apart and be connected by a short edge, allowing the corners to appear mostly sharp) and a secondary set of texture coordinates should be provided for the displacement map / alternatively the displacement map should be handcrafted such that when displaced (with a reasonable strength / height factor), faces won't extrude through each others.

Of course there exists more elaborate ways as described in the previous posts, I just thought I would share this if anyone found it interesting, After tracking down a copy of that practical rendering book just for that tessellation chapter, it didn't say that much more about this particular problem, so might as well save others the trouble.

Hi,

im trying to implement the dominandt data, but I'm struggling again...I'm not sure how to understand the GDC 2012 slides, when i'm generating the index buffer:

? Can use AEN edge data as well

vs:

? All shared vertices must have the same dominant data
? Both edge vertices must be from the same primitive

I tried with the PN AEN Indexbuffer adding 3 arbitrarly chosen vertices, but it didn't worked.

Then I found on the Maya Homepage a despription of a PNAEN 18 implementation using dominant data with a 18 size index buffer and I tried to adapt it. But the result isn't good either, the UVs doesn't look smoother:

screenshot0312.png

My index buffer now looks like this for unbirds example:


0,1,2,0,1,4,3,2,0,0,1,4,3,2,0,0,4,2,3,4,5,2,1,4,5,5,3,4,3,4,5,5,3,4,4,5

(See also xls Attachment for details).

I'm pretty sure that the shader interpolates right:


			float 
		uCorner =  (u == 1 ? 1:0),
		vCorner =  (v == 1 ? 1:0),
		wCorner =  (w == 1 ? 1:0),
		uEdge =    (u == 0 && (v * w)!=0 ? 1:0),
		vEdge =    (v == 0 && (u * w)!=0 ? 1:0),
		wEdge =    (w == 0 && (u * v)!=0 ? 1:0),
		interior = (u * v * w)!=0 ? 1:0;

		vec2 displaceCoord= 	uCorner*InPatch.domVert[0]
							+vCorner*InPatch.domVert[1]
							+wCorner*InPatch.domVert[2]
							+uEdge*mix(InPatch.domEdge0[1],InPatch.domEdge1[1],v)
							+vEdge*mix(InPatch.domEdge0[2],InPatch.domEdge1[2],w)
							+wEdge*mix(InPatch.domEdge0[0],InPatch.domEdge1[0],u)
							+interior*UV;

Any clue?

This topic is closed to new replies.

Advertisement