|
||||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread ![]() |
| Procedural Planets Part 1 - Structure |
|
![]() OrangyTang GDNet+ Member since: 3/19/2002 From: London, United Kingdom |
||||
|
|
||||
| Nice article, but I can't see where you determine how to split or combine faces. From the demo it looks like you're splitting based on distance to the camera, but for a sphere I think you'd get better results if you split silluette faces as well to get a better profile. |
||||
|
||||
![]() Sphet Member since: 9/16/1999 From: Vancouver, Canada |
||||
|
|
||||
| Arn't you worried about the creation of TJunctions? When a subdivided triangle meets a non-subdivided triangle, you'll get cracks along the joint. Isn't this why some ROAM engines ( I think ) use special tile-joints to convert from high tesselation to low tesselation? I'll also agree with the previous poster - I would think that making sure the sillouette is constant or at least consistent around the circumference is very important. Looking at the sample there is some strange behaviour as a spin the planet around. [edited by - Sphet on March 25, 2004 11:58:46 AM] |
||||
|
||||
![]() Binstar Member since: 3/26/2004 |
||||
|
|
||||
| Adjacent triangles that are of a lower level of detail, cause the neighbour to split down to the midpoint of the edge, without the radial+height displacement, therefore avoiding the gaps. When both triangles are of the same level of detail, the shared point on that edge pops up (use geomorphing to hide this). This way the T-junctions are self healing. This is recursive and independant of the method used to drive the LoD (determine priorities). In the demo it uses a simple determination (is the camera within the length of a triangle) , but as I say it's an interactive diagram not a planet. You'd use some function of length, distance and a factor to determine it in this case. Whatever you use, the LoD is self healing however. eg. http://www.binstar.com/index.php?page=gallery&newsid=4&showimage=8 (albeit thats not using a great priority determination), but as you see, it has no gaps. Note there is an ommission in the article (I submitted it a while back). The center triangle of each group, t[3], when split, requires t[3]->parent->e[0-3] to be split also. Anyway, it's the visual appearence that it's a t-junction nightmare (two triangles bordering one edge of a larger triangle) as used in frontier FFE, that prompted me to investigate how this LoD tesselation works. I don't cover priority and detail generation in this article because it's just about the structure. Perlin or Midpoint displacement(plasma) or any other determination will do, and not effect the LoD's integrity. I don't pretend this is the most efficient method (ROAM for example doesnt require keeping split triangles edges flattened) but the visible results are good, the mesh very cohesive and excellent for placing objects onto, and there are some good optimizations available. You also get a very rapid tesselation of LoD data. Some interesting additional facts are helpful for later use of the mesh, eg. The center of any triangle, will also be the center of a triangle at higher LoD. [edited by - Binstar on March 26, 2004 3:33:50 AM] [edited by - Binstar on March 26, 2004 3:43:14 AM] |
||||
|
||||
![]() technobot Member since: 1/5/2003 |
||||
|
|
||||
Note: I admit I only skimmed the article and didn't read it very carefully, but I think I understand the basic ideas.quote: The way I understand it, your approach solves the gaps (by subdividing the lower-lod neighbor without moving the new vertex), but it does not solve the T-junctions . When you split that lower-lod neighbor, you still have the situation of two triangles on the same edge of a neighbor triangle. The T-junction results from the middle vertex not being used by all neighbor faces. Due to round-off errors, this may appear as a visual artifact in the form of unfilled pixels. It seems that the most appropriate way for your system to fix the craks and avoid T-junctions, is to use skirts. These have been discussed many times in the graphics forum. As a side note, if you are interested, you may look up my planet rendering threads in the graphics forum (a search for "planet rendering" should give you the liks) - we've discussed a similar system in much more detail. Michael K., Co-designer and Graphics Programmer of "The Keepers" We come in peace... surrender or die! [edited by - technobot on March 28, 2004 5:19:24 PM] |
||||
|
||||
![]() Geocyte Member since: 9/28/2000 From: United Kingdom |
||||
|
|
||||
| Michael is correct. Round off errors due to limited z-buffer resolution lead to an effect commonly known as "seaming" "stitching" or "cracking". It isn't apparent in the demo because all the tris have black borders and the buffer is cleared to black. Clear the buffer with a colour or draw the sphere a solid colour and it will become apparent. I still found the article useful in implementing my own procedural spheres as the relationships between triangles are well illustrated. Geocyte Has Committed Suicide. |
||||
|
||||
![]() swiftcoder Member since: 7/3/2003 From: Boston, MA, United States |
||||
|
|
||||
| Any chance of that further article on LOD, etc? Eagerly awaiting, SwiftCoder Tristam MacDonald - swiftcoding |
||||
|
||||
![]() Downie Member since: 2/23/2009 From: Dundee, United Kingdom |
||||
|
|
||||
| Hey Im guessing this thread and article are long dead but In a vain hope that anyone is still checking this here goes. Has anyone had a problem with the normals of the mesh once the shape has been split? Im finding that every other triangle seems to have a dodgy normal. It could just be my implementation but just wanted to check. Thanks if anyone's listening lol |
||||
|
||||
All times are ET (US)![]() |
Last Thread Next Thread ![]() |
|