Sign in to follow this  

[SOLVED] Tessellation on IcoSphere

Recommended Posts

chrisendymion    411
Hello ;) Before, sorry for my poor english... 
I'm working on a procedural engine with some results on generating a full planet.
But I have a "crack" problem with the tessellation (based on frustum and distance LOD).
The icosphere is generated by code with X subdivisions. Let's go with 0 subdivision for theory..
I'm using this algorythm for adaptive tessellation :
Every vertex's distance is calculated and the minimum is used for defining the tessellation factor on the edge.
So, in theory, there will be every time the same factor for the same edge, and in result, no cracks !
But, there is a problem.. Which vertex for which edges ?
I need to address tessellation factor for each 3 edges in a hard order.
Edge 1 from triangle A must be the same edge shared by triangle B in the same order (egdge 1).
(in the exemple here, vertex variable is the tessellation factor calculated from distance to camera)
HULL SHADER (patch function)
_output.Edges[0] = min(_vertex2, _vertex3);
_output.Edges[1] = min(_vertex1, _vertex3);
_output.Edges[2] = min(_vertex1, _vertex2);
_output.Edges[0] = min(_vertex2, _vertex3);
_output.Edges[1] = min(_vertex1, _vertex3);
_output.Edges[2] = min(_vertex1, _vertex2);
So, if the edge shared by A and B is edge[1], A.vertex1 must be the same vertex as B.vertex3....
If not, there will be differents tessellation factors and cracks...
Whith a flat grid, this is working very well (every edges shared are in the same order) :
But for an icosphere.. It's not possible (view eclated from upside) :
The order is wrong......
I'm using 3 points patch list, I tried with 6 points patch list (neighbors), but it's the same problem...
I'm not sure to have correctly explained the problem.
My general question is : How to do tessellation on icosphere without cracks ?
Is there a better algorythm ?
I'm far from an expert in graphics.. 
Thank you very much for any help ;)
Here some screenshots from actual rendering results :
Edited by chrisendymion

Share this post

Link to post
Share on other sites
unbird    8335

Note sure if I follow your problem right, but if you got your tesselation factor calculation right, the geometry shouldn't matter. Hold on, I grab my tesselation test scene and feed it a icosahedron icosphere.


What SDK and especially what shader compiler version are you using ? I once had a bad bug with the June 2010 SDK compiler in conjunction with tesselation factors.


Update: Hmmm, maybe I understand better  now. The link you gave uses quad tesselation. For triangles one needs to know [url=""]this[/url]


And jep, my tesselator has no trouble with an icosphere (had to make one first).


Edit: By the way, nice screenshots!

Edited by unbird

Share this post

Link to post
Share on other sites
chrisendymion    411
Thank you Unbird for your help.. And thank you for your time testing this with your engine !
I'm sorry, I didn't understand posts from the link you gave me... 
Ok, it's helpfull to know that edgeX is opposite to vertexX. But what else ?
You said in the other post : 
As long as neighboring patches share the same control points, and the control point to tessellation factor algorithm will produce the same output for the given input control points, then the order doesn't make any difference. 



But as the picture I posted before (ico from upside), I cannot produce the same control points without altering the order, which will break the cull back face. Or I'm missing something ?
I thought about using a 4 points patch list, the fourth point is the order to give to the edges.
It almost works, but creates strange artifacts.. Perhaps the bug you said about the June 2010 SDK (I'm using it) ?
Which SDK are you using ?
Using the 4 points for the edge's order :
_output.Edges[0] = floor(min(vertex1, vertex2));
_output.Edges[1] = floor(min(vertex0, vertex2));
_output.Edges[2] = floor(min(vertex0, vertex1));

if (inputpatch[3].Model_VertexPosition.x == 1.0 && inputpatch[3].Model_VertexPosition.y == 3.0 && inputpatch[3].Model_VertexPosition.x == 2.0)
_output.Edges[2] = floor(min(vertex1, vertex2));
_output.Edges[1] = floor(min(vertex0, vertex2));
_output.Edges[0] = floor(min(vertex0, vertex1));

Results (other edges are working correctly) :

Using Edges[0] or Edges[2] with 1 as value does not generate artifacts (but one edge tessellation is logicaly missing) :
So artifacts appear only if the three egdes are > 1, if one edge is set to 1, it works.
Is that a bug ? I'm totaly lost... 
[UPDATE] Yeah, forget the bug's part.. If found this, changes made it to works ! 
Now with my idea of passing a fourth point, which says the order of edges, it's working with 0 subdivision.. But it will be hard to do the job with the subdivision.
No better algo ? I feel complicate unnecessarily.
Edited by chrisendymion

Share this post

Link to post
Share on other sites
chrisendymion    411


Nevermind... Forget all my posts....

All the troubles were caused by the SDK June 2010 !!!

All is working very well now !! ;)


Thank you again for your help !!


If someone has the same problem, you need to add this in the hull shader file :

#if D3DX_VERSION == 0xa2b
#pragma ruledisable 0x0802405f

All this drawing and posting time just for a little bug.... 

Share this post

Link to post
Share on other sites
unbird    8335

Glad to hear it's working. And thanks for that link. I did not know one could "patch" the compiler this way. It's also good to know the bug is actually documented.


I'd still recommend using a newer compiler: Read here!




All this drawing and posting time just for a little bug.... 




Tell me about it. It isn't little if it's not your fault - since you look for compiler bugs last (if at all). And waste time.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this