I must have done something right. Converting terrain to a planet took all of 2 hours. A couple tweaks to collision works a little bit but likely I'll have to make a decent octree system for collision. I'll worry about that later. For now PLANET!


Not sure where to go from here. I'm not 100% about the quad tri system anymore. The T Junctions are starting to concern me a bit. I need to get some more motivation. I'll be studying lighting techniques... since I've never done it before. I haven't really been working on it much lately because I haven't been able to think of what to work on. For some reason I don't think it's quite at the state to apply to a planet. Maybe I just need to do some refactoring. Current list of things that need to be done 'right':

  • Culling
  • Proper thread based subdivision
  • Texturing
  • Lighting
  • Add Quad/Oct tree for faster collision
  • Water
  • Clouds
  • Atmosphere
  • Stars
  • Sun
  • Foliage

I need to stop complaining about something to do and just do something. For now you just get furry terrain.
furryterrain.jpg At least I know the normals are correct.

Getting sick... in the middle of summer. I almost lost motivation in the triangulation system I'm using. There are plenty of proven systems available, mainly ROAM, so the thought of proofing out a new one is quite daunting. At first I was going to make a post how I'm thinking of dropping this system. I sat down to have one more look at it and had a few epiphanies.

I guess I should first say why I was losing motivation. I want to have a nice simple triangulation system. Using Quad Triangle tree (each triangle splits into 4 when subdivided) seemed interesting. When using an equilateral triangle all sub triangles keep the same proportions. My only concern initially was the T junctions that were caused. Once I created a simple triangle class that only managed the subdivision I thought the system was complete. The problems came when I tried to subdivide in more that one location. I started getting gaps all over the place (see first picture). I found a few fixes (making sure edges are never more than 2 levels apart) but the problem persisted.

I got my epiphany and narrowed it down to the points. New points are created by interpolating between two existing points. They are not always updated to reflect the proper position. What would happen is that a triangle would be subdivided but it's points would not be updated. Then when triangles further away would tesselate they would cause the points that were used to create a point to update but the child points would remain unchanged. All in all a really weird situation. Since I was already keeping pointer to the two points that were used to create any particular point I simple added some update counters so I could easily tell when a point changes. The one problem I'm not happy with is that whenever a point is requested it has to check if it needs to update. That can always be optimized later though. For now I'm sick and motivated again. I finally have a decent smooth mesh (see second picture).

Didn't get much time to work since the last update. A few quick changes. First is that I fixed a bug in the subdivision routing. Edge triangles cannot be more than one level of subdivision away from any given triangle. This immediatelly allows the mesh to be a lot smoother. Though in no way smooth enough for proper terrain. Secondly I added some simple coloring to show height, from the black depths of the ocear to the snow peaked mountains (sounds more impressive than it is).

It took a lot of thinking to get my head around it but I finally have camera positioned based tesselation. In the end it was simpler than I thought. I used a similar system to my previous post. I simply determine which head triangle my camera position is contained within and subdivide it. Do the same thing recursively. Once I've subdivided to the lowest triangle I do a plane distance check for simple collision. This works great except that the only area of detail is directly under the camera. I tried a simple method to extend the tesselation by spliting neighbours. I split the neighbours up to the same amount of steps away as the current tesselation depth. This works except triangles stopped connecting properly so I simply found another bug in the base triangle class. The bug searching will have to wait until after the weekend though. Here's a pretty nasty shot of the terrain. Once I fix the bug in the triangle class I'll try to make it a bit prettier.


Sorry if this is a little unintelligable (sp?) it's past my bedtime. I'll fix it up later. Or maybe I'll just leave it here as a lesson to go to bed on time.

After three tries I finally have a base architecture for my triangle grid that works well and is very flexible. Once I finally limited the class to the core functionality of spliting and collapsing triangles everything fell into place. My class is a lot cleaner and simpler, I've added only the minimal code required to keep the mesh coesive. All splitting and rendering logic are done outside of the class. This allowed me to add a a bunch of debug rendering and even some basic splitting code which helped me track down some bugs.

I've been thinking how I can write unit tests for it but the key thing stopping me is being able to come up with complex enough tests and proper test data to compare it to. Most of the bugs I've found have to do with collapsing and rebuilding multiple neighbouring triangles at the same time. Trying to iterate through making sure that all the edges and children are resolving properly sounds like a plan.

Well anyway, here's the exciting bit. Some screenshots of subdivision in action. The first is the basic structure, two head triangles connected to each other. The second show where two rays shot into the mesh cause it to tesselate. It's not amazing at the moment but it's a very important first step. Next step is getting an algorithm together to auto tesselate the mesh based on view position.