• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0

[SOLVED] Tessellation on IcoSphere

5 posts in this topic

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

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="http://www.gamedev.net/topic/642188-which-edge-is-which-when-tessellating/"]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
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


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

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  
Followers 0