Terrain Video

 I made a short little video flying around the terrain, 1080p if you click on on the word youtube.

Terrain Blending

NOTE: the methods in this post are old & moronic, don't use them:)

 Blending:

 I've updated the terrain so that it blends seamlessly between different LOD's.  Previously it would just switch from one LOD to the next without any attempt to blend, which looked pretty bad, especially if running the terrain at a fairly low detail setting.

 Textures: 

  For now just using some random textures off the internet.  Texturing is being applied using triplanar texturing.  Currently it is just a global set of 3 textures, but eventually I plan to make it store per vertex a texture ID, so that the terrain can be, at least to some degree, painted upon.

Seamless blending & basic texturing

 
  Some blending details...


       Typically terrain blending is done via vertex morphing & manual texturing blending, at least this is how most height field based algorithms work.
   I am using voxels though.  Rendered as chunks of triangles, essentially each LOD's meshes are unrelated to the next LOD's meshes.  There is no real obvious way to morph between these meshes since they have nothing in common.
     What I have seen done before is alpha blending between LOD's.  Nvidia did this in their GPU terrain demo.  I plan to use a deferred renderer, which generally runs counter to alpha blending, so I've modified this idea somewhat.  Currently what I am doing is rendering high detail terrain into one set of buffers, and low detail/parent terrain into another. In post I blend them together based on a few different things.  The overhead for this is actually surprisingly small, and eventually I will be able to blend the data together prior to lighting being applied, essentially dumping the result into the deferred gbuffer.


 and cracks..
          Are gone, mostly.  I added a check so that if no data is found in the high details, it tries to fill it from the low detail, this seems to fix most cracks. I will probably expand on this to remove all cracks at some point in the future, but it removes most already.

Blue represents any location that was hole filled or crack patched, red represents places where fixes failed.  (The sky is red, which is good since it is shouldn't be patched).

Terrain Collision

NOTE: this post is old and nonsensical but I'll leave it for now..

Testing terrain collision with the green blocks near bottom.  Here they are about to drop over the edge of the cliff.

Dropped a few hundred balls on terrain as stress test.  

Added terrain collision last week, but as I'm not using heightfields I had to use

something slightly different from the norm.

  First I tried a pure triangle mesh based approach, I knew this would be slow as

hell and use a ton of memory but I wanted to have a working baseline to compare

against.

  Initially for physics I used Havok,but after getting the basic triangle mesh collision working I switched to Bullet.   Why? I don't have $100,000 laying around to
waste on a physics engine for which I only have access to the binary version--and Havok only supplies libs for VS2008, not VS2010 which I what I am using, although I was able to
get the 2008 libs working, also I just like having the source code.  

  I'd used Bullet before so it was easy to get it switched over, and once I had 
the triangle mesh collision set up I gave it a trial run.  

  The triangle mesh collision used approximatly one gig of memory, although 
generation speed for the btBvhTriangleMeshShape was fairly quick.  I created a
task to generate collision and spread the work across the cores which made
generation faster.  

  I added spheres and boxes that I could drop onto the terrain to test the accuracy
and performance of the collision detection.  

 A gig of memory for terrain collision was obviously out of the question so I began
testing convex hulls.  

  

      Bullet has a btConvexHullShapewhich takes an array of vertices in floating point format.  This worked and reduced memory usage by more than half.  Still wasn't good enough though. 

      I wrote my own convex hull shape which I called
btCompressedConvexHullShape, as the name implies it uses compressed verts
(about 1/4th the memory per vert).  

      I also started using Bullets utility class btShapeHull.  This class takes in

an array of vertices and produces a convex tri mesh with a greatly reduced
number of vertices.  Feed it 2000 verts and get back a 14 vert convex mesh, 
that type of thing.

    I feed the results of the btShapeHull back into btCompressedConvexHullShape or a btConvexTriangleMeshShape(favoring btCompressedConvexHullShape as they both seem to produce the same results and it uses less memory).  

   Memory usage for the physics simulation was greatly reduced at this point,
down to about 100 megs.  There are still a few optimizations I'd like to do, 
mostly to reduce the allocations taking place in the btShapeHull step, but 
overall the performance and memory usage is fairly good at this point.

  I've also got the physics simulation running as it's own task, with adding and 

removing of objects done asynchronously.  This helps because as you move through

the world a great many terrain chunks(each as a convex hull) are being added and removed.

 Collision seems to be fairly accurate as long as I don't have it too far off

from the visual representation.   

   My gravity is currently just set using Bullets built in system, which is directional.

This means if I navigate to the side of the planet I can start dropping objects

and watch them bounce along through mountains and valleys for miles as they

travel along the edge of the planet.  

  Need to add a character control system soon.