For the next step, I’ve made only one modification from the original plan. Right now I should start working on the streaming of the terrain, but before that, I’ve decided to create one sample terrain, with a good size this time. This way, I can have a better benchmark of the current performance, and also a better test case for the streaming.

To create the terrain, I’ll need an application, a terrain slicer, to create the patches for a big terrain. With this tool, I can work with a large terrain and make a post-process to generate the various slices that I use as terrain patches. It will have the following specs:

• Each patch will have 128×128 vertexes
• The vertex size will have 2 meters (so each patch will have 256×256 meters)
• The view distance will be 2 kilometers
• The total size of the terrain will be 32×32 patches (a little more than 8×8 kilometers)

I’ll also make some simple tests with different settings to check the performance, so I can have a better idea about the impact of the patch size in the application. I’ll have some stall while moving the camera, since I have no streaming yet, but everything should be working nicely.

PS.: I’ll not post screen-shots from this update, since it looks similar with the tests I was doing before. The major difference is the internal structure/management.

As I’ve posted some time ago, I needed a version control system at my home computer, to organize my projects, keep track of code differences and also to make the backup process easier. After searching for some free repository services in the Internet, I’ve found 2 interesting options:

• http://cvsdude.com – 10 MB of space in the free service
• https://freepository.com – 300 MB of space in the free service, but access is only allowed through the web browser

As 10 MB is not enough memory for my needs, and I wanted an easy way to access my files (I didn’t like the web interface of the freepository) I’ve changed my mind. Instead of a remote server, I’ve made a Subversion local server on my machine. The installation was very easy and in a few moments I had my server and repository running.

The next step included organizing all my past projects, restoring of backups (some things had 12 years), cleaning up all the mess and adding everything to my repository. This took me a lot of time, since I had more code stored than I remembered. I should have made this a long time ago, but better late then never, right?

For the Subversion interface, I’ve chosen TortoiseSVN, a great tool that integrates in the windows explorer. Now I can make a dump of my repository to a file, and backup this file to a pen drive. So, everything set, I can continue my work towards the current main goal: a big terrain.

Below there is a screen-shot from the latest version. Finally I could spend some time on the code itself, so the interpolation of vertexes between different LOD levels was made:

You can notice that, even though there are missing vertexes on the lower level, both fit together perfectly. This was made using a very simple interpolation in the higher level, with 5 parameters for each terrain patch, controlling the blend between the current level and the lower one, a float value between 0 and 1 for each side (left, top, right, bottom) and one for the center. The center blend will be used when a LOD level is changed, so we avoid terrain popping from one position to another with a smooth interpolation.

Now I can work on the next part of the project. The creation of a squares manager. This will be an interesting thing, since the manager will make the transition between the LOD levels, increasing/decreasing the quality based on the distance to the camera. Also, it will be asking for new files to be loaded as needed, in the near future. So my current terrain patches will be the low level of my terrain implementation and this manager will organize parameters and data of these patches in a higher level.

• It’s not possible to access textures in the vertex shader below 3.0
• My modest geForce 5600 has vertex shader 2.0
• I don’t want to always run the software driver
• Currently, I have some CPU cycles to spent while the card is rendering

Below I’ve posted an screen-shot taken from my latest build. Keep in mind that it’s just for testing purposes, since it is very small, and each patch has only 33×33 vertexes. It has no lightening yet (I still have to calculate the normals in the near future), so I’m just using the height as the color. You can see the LOD changes by the color, red are the even and green is the odd levels. I’ve also included a wire-frame of the terrain, so you can see what’s really going on.

Regarding the height values, I still have one problem to solve. Since there are missing vertexes in lower levels comparing to the higher ones, you can see gaps between them. I’ve captured a screen-shot from a close up in one of these gaps:

This problem seems to be easily solved with an interpolation. These vertexes that doesn’t exist in the lower level need to be moved to the medium value of it’s neighbors. That’s the next thing I’ll do, since these gaps are really annoying.

Some things I’ve discovered that I need to do really soon:

• A texture slicer, so I can work with a larger version of the height-map, and cut into pieces for the terrain patches. Making this by hand is really boring and takes some time.
• Create an account in a version control system, so I can keep track of my changes, and also keep the code backed up.

And so the work goes on…

• A basic viewer application, with camera fly commands.
• A terrain object/resource, with some configurations and a wire-frame render mode.

It’s not much, but it’s the base I need to work. The next step is reading the height values from a texture, updating the terrain vertex positions. Strangely, my little engine doesn’t have texture support yet, I never needed it on my previous experiments.

As usual, if anyone has questions or suggestions, feel free to add a comment

Main Tasks:

• Add the terrain type resource/object to the factory in the engine. (done)
• Create a test application, with a terrain instance, and some controls to fly in the world with the camera. (done)
• Create the terrain squares logic, creating the needed vertex/index buffers. (done)
• Render the terrain squares, with wire-frame support, just to setup the shader skeleton and see something in the screen. (done)
• Use interpolation to smooth the LOD intersections and also the LOD changes. (done)
• Create the squares manager, which will make the culling, set each square LOD level and ask for data. (done)
• Create a sample terrain. (in progress)
• Implement the file streaming.
• Render each square using the height maps and the current settings.
• Include normal maps to calculate the lights.
• Include texture layers (grass, rocks, gravel…).
• Drink lots of beer Make a code cleanup / optimizations / leak detection / performance tests.

Optional Tasks:

• Create a procedural terrain, and use it, instead the file streaming.
• Add a sky-box.
• Implement a walk-mode.

And that’s it, I hope I didn’t forget anything, since it has enough tasks for some time. I expect that in the end I’ll have a good running terrain, and that all of this will be useful for someone besides me. I’ll update this blog with new posts between the tasks, and hopefully post some nice screen-shots.

Main structure:

As my terrain will be streamed (from a file, network or from a procedure), I need to divide it somehow. I’ve decided to make it in squares of the same size, so I can load single squares from a file, and use it also on my LOD calculation. Given the current LOD from a square, the data will be streamed (in the case of a file, the correct mip will be loaded from the disk). Also, with this approach, I can load first the lower version and substitute it from a better one as soon as the higher versions arrive from the stream. I’ve made an simple image of the system:

• Blue area: First LOD, with the highest resolution (in this example, 4×4)
• Yellow area: Medium quality LOD
• Green area : Lower quality LOD
• Blue Xs: Normal vertexes
• Red Xs: As usual, red means problems. This vertexes must be interpolated to fix the fact that they do not exist on the lower LOD.

As you can see, I’m not an artist, but I think that the drawing fulfills the objective. Here, the camera is in the center of the terrain, so we load all squares surrounding it. It should have the following features:

• Each new LOD will have 4 times less resolution than the previous one.
• Configurable quality parameters, like the quality of the first LOD, distance from LOD to LOD, view distance…
• LOD based on the distance from the camera and the currently available data. As the camera moves, squares will be released and new ones will be loaded.
• The terrain can be loaded progressively (load lower resolution maps first, show it, and substitute when a better one is acquired)
• Only one needed vertex buffer (with the higher resolution) and one index buffer for each LOD
• Use of GPU to calculate the height of each vertex based on a height map texture
• LOD and streaming of other textures, not just the height field (normal maps, texture layers…)
• Use of interpolation when changing the LOD levels and to avoid T-Junction problems between different levels.

Positives aspects:

• Easy to use streaming (fixed size squares, easy to acquire and manage)
• Good visual quality (full quality around the camera, decreased quality away from it, popping can be avoided with interpolation)
• Reduced number of triangles (each LOD blit 4 times less triangles then the previous one)
• Low usage of memory
• Low use of CPU (which can be used to stream/process new data)
• T-Junctions can be corrected on the vertex shader (more on that later)
• If needed, it can be implemented completely in software (i.e.: low spec machines)

Negative aspects:

• A square must always have neighbors with a maximum of 1 level of difference (not a real problem, due to the LOD nature)
• High number of batches (much more important than triangles, these days…)
• Collision detection with the terrain will have different results depending the LOD level.

Example: (considering a 16bit height map):

• LOD 0: 128×128, 32768 triangles, 1 batch, height map: 32768 bytes
• LOD 1: 64×64, 8192 triangles, 8 batches, height map: 65536 bytes
• LOD 2: 32×32, 2048 triangles, 16 batches, height map: 32768 bytes
• LOD 3: 16×16, 512 triangles, 24 batches, height map: 12288 bytes
• …

Overall

My biggest concern is the number of batches, but each square will have a good coverage area. I think it’s a price to pay for the streamming feature of the terrain, and I believe it will be good enough. I’ll make some performance tests on the future, and, if necessary, I’ll consider different alternatives, but right now I think it will be ok this way.

About the collision detection problem, it can be a big issue depending on the use of the terrain. As I’m implementing it with the rendering and the size as the main objective, it will not be a problem. But it can be solved in different ways, depending on the needs. If we really need a good precision, or a constant terrain, we can add a constraint that a specific (i.e.: the highest) LOD level must always be available in all, or in some squares (i.e.: near the player).

By the previous example, we can see that the number of batches for each new LOD level increases the previous one with a fixed number (8, except for the first one). Also, the camera culling can eliminate unnecessary batch rendering, and each new LOD requires less texture memory than the previous one.In the near future I’ll post details on how I do plan to develop each of these features, with a list of the tasks I must accomplish to make this happening. As always, if you have any critics or suggestions, feel free to post.

Super Frustums

This one is very simple, but I liked the name. Also, it makes me remember that I want super large terrains and that camera culling is always a nice thing \o/

The Second Life of Brute Force Terrain Mapping

This guy have guts, he likes brute force on terrain. Yeah, ok… I’ll skip it.

Continuous LOD Terrain Meshing Using Adaptive Quadtrees

It has some basic concepts on continuous LOD, and also about avoiding vertexes problems in junctions of terrain tiles, since they will have different topologies.

Real-Time Dynamic Level of Detail Terrain Rendering with ROAM

ROAM is very interesting, a nice beautiful algorithm to implement, and produce great interesting meshes. But I’ll not be using it, since I want some more GPU intensive. And also because I want something more straight to the tiled streamed terrain I’m thinking about.

Binary Triangle Trees for Terrain Tile Index Buffer Generation

Nice and clean technique and article. It uses only one vertex buffer and some index buffers that map all different situations regarding T-Junction problems. It shows a solution to automaticaly generate these index buffers, and also reduces it’s number removing the need of special cases between even to odd levels.

Global Terrain

Wow, global terrain, that’s nice. Huge view distances, methods to gather terrain information from large, real world terrain and so on. Maybe a little too much for my necessity, but very nice to read and a good inspiration.

Real-time generation of planetary landscapes

Another planetary landscape. It’s a nice article and it makes a review of various methods (some covered here in this topic).

Terrain Geomorphing in the Vertex Shader

Geomorphing, this is interesting… Smooth transition between LODs, avoiding popping, use of shader… I like it. Also, has some PVS information, to avoid rendering tiles which are not visible.

Terrain Rendering Using GPU-Based Geometry Clipmaps

This is a great, very recent terrain. It makes a nice use of the current GPUs, doesn’t require lots of different meshes to avoid T-junctions, does not require much CPU, gives a great view distance and has a great quality (yeah, I liked it).

/*==============*/

Well, that’s it. Now it’s time to get some of these ideas that fit to my problem, mix with some of my own, and gather the final ideas I’ll be implementing on the next days/weeks. In the next post I’ll post my code decisions, and also comment the “whys” and “hows” of them.

Objectives:

• Create a fast, streaming terrain, with multiple LOD levels
• Support for really huge terrains
• Support for procedural terrain
• Good performance/view distance
• Simple walk/fly modes, so the landscape can be tested
• Wire-frame mode

So the next step is to make some research and choose an approach that fulfill all these objectives.

The first task I have here is to define the first project I’ll work. I’ll make a post initiating the new project soon, stating the problem and objectives I want to fulfill. There are some technologies and experimental things I want to try, but to start, I’ll probably choose something as a base, so I can use it on other projects on the future.

I’ve made some simple things before, so I will probably use them in these projects. The small list is here:

• A (very) simple DirectX-based engine with a modular approach. It has only the basics (initialization, input and resource manager).
• Simple types implemented using this engine. These types includes bitmaps, shaders, spheres and boxes.