Procedural Planet - Texture Generation

Texture Generation for procedural planet was a simple step up from generating height based texture for a flat terrain. Because the underlying structure of each planet is a cube, 6 textures are required for each planet. The height is calculated from the distance of the vertex to the centre of the planet, minus the base radius of the planet. This method allows 100% re usage of the normal terrain height map and texture generation functionality.





In the above video the planet is made up of 125x125x6 vertices's and the moon from 65x65x6 faces. There is currently no complete LOD functionality. When fully implemented each face recursively subdivides into 4 faces of equal area, resulting in the level of detail of each face increasing by a level of 4 with each divide.

With some clean programming, a vertex should never have to be calculated more than once (unless the player moves a distance away and the section is deleted from memory). The parent will populate each of its children with the relevant subset of its data, and only the unknown sections calculated, resulting in lower memory usage as well as faster run time higher LOD generation.

Procedural Planet

In continuation to the Procedural Sphere entry I made a few months ago, and from inspiration by the ongoing work of Jelly Edwards I decided to look into further developing the sub-dividing cube with procedural noise in order to make a planet.

The noise algorithm used is Fractional Brownian motion (fBm) which is a form of Perlin Noise.

A good article about fBm in relation to procedural planets can be seen here. This work was carried out by Sean O'Neill who has also contributed allot to atmospheric scattering.

Very early and basic attempts at a procedural planet can be seen below. For the purpose of illustrating the deformation of the sphere I have magnified the hills and valleys on the planet, which results in what looks like an asteroid or moon.

There are some key failings with this version. It is slow to render as the vertex and index buffers and built each frame. The whole planet is the same Level of Detail (LOD). This is ok for distance viewing, however as the camera approaches the surface of the planet, rendering the entire scene at a high LOD would cripple even the most powerful of computers.

Many of the techniques learned when researching and implementing my terrain system will be used here.

• Dividing the planet surface into patches
• Each Patch manages their own LOD (through subdivision and creation of child patches) based on distance from the camera.
• Each Patch maintains its own Vertex Buffer, while sharing a group of Index Buffers (to cover neighbour patches with different LOD's)

Allot of my terrain modules can be reused, with perhaps a little added functionality, so I hope that, time permitting, adding these features will not take too long.

MD5 Mesh and Animation

Two young and very talented modelers from Sweden have started making some game content to be used in Decade. MD5 was their format of choice for doing animations so I used this requirement as an opportunity to research the format.

A good explanation of the .md5mesh file format can be found here and a similar explanation of .md5anim can be found here.



After reading the two file format descriptions specified above as well as a refresher on quaternions it was not too difficult to parse the files and create the mesh and animations.

In order to make Decade's MD5 support as complete as possible it supports multiple loading methods which are specified through a flag parameter in the Load function. One can build hardware/software vertex and index buffers for each specified frame at load time or they can be populated when required.

If an animation does not have a high enough count of frames per second, Decade can calculate additional frames using the mesh/anim data along with quaternions and slerp.

Terrain Precalculated Shading Techniques

After adding slope lighting and seeing how simple it was to make a terrain look better with no run time cost I decided to extend this method to more realistic looking shadow/shade.



Above is a non shaded, non shadowed terrain. This is the control image to which the next 2 results can be compared. In this normal method a height map is procedurally generated and the terrain texture is then created from this height map and a set of layer textures.



For slope lighting an extra step is added during the terrain texture generation.
For each vertex of the terrain, the neighbour vertex in a specified direction is checked. If it is higher than the current vertex shade is applied. This is a relatively fast technique. In a height map of 512x512 the number of comparisons is 262144.



Shadow texture generation is an extension of the slope shading technique. Instead of checking the immediate neighbour a ray is cast from the current vertex to a specified light position. For every step along the ray the height of the terrain at this point is checked, and if it is higher than the ray shadow is applied to the original vertex. (i.e. there is no direct line of light between the light source and the vertex). In my opinion this produces more realistic results and will combine well with shadow maps or shadow volumes but it is allot slower than the previous methods. To calculate the shade applied to each vertex in the shown 512x512 terrain 45556293 checks were required, which took 27 seconds.

This could probably be improved so that the terrain is checked at a lower resolution, with an approximate shade applied to the "in-between" vertices. This would allow the light source (probably the sun in an outdoor scene) to move.

Decade Blog is 1 year old today. 10% of the way through its life!

Slope Lighting

Back at the dawn of procedural texture terrain generation in Decade I decided to skip slope lighting. My reason for this was that I have always planned on adding real lighting effects with shadow maps or shadow volumes.

Reciently my long time friend and arch nemisis Jelly Edwards, who is also now my blog enemy, has started a DX10 terrain engine and his slope lighting effect was impressive especially considering the ease at which it can be added and the free cost of this effect.

Slope lighting is calculated during texture generation therefore has no cost during runtime. Each vertex in the height map is checked against its neighbour in the direction from which the light is coming. If the neighbour is higher than the current vertex shade is applied based on the difference in height (how much the terrain is facing away from the light).



I am hoping that this effect will not be used in the majority of cases, however it is a nice addition to enhance the terrain on computers which do not have the power to do real time shadows.

Terrain Cracks Revisited

In August of last year I posted a blog entry about terrain cracks. Despite having a theory back then about how to fix this problem I never got around to fixing the issue. A new feature was always more exciting and overtook this development.

Long overdue I have fixed the problem. I will briefly try and recap the issue. Segments of the terrain which are further away from the camera are rendered at a lower level of detail than those which are closer. When a patch gets a distance from the camera the level of details halves. Since every second vertex in the lower level of detail is missing this can result in cracks in the terrain. The image below shows this up close. This situation is not realistic because the patch joins will be a distance away from the camera however even at distance it is possible that artifacts would be visible.



In order to overcome this problem I have removed every second vertex along the edge of a patch which has a higher level of detail. This is all calculated during load time. At run time each neighbour of a patch being rendered is examined and a bitmask is calculated accurately describing the surrounding area. This bitmask is then used to offset into an IndexBuffer array, using the correct buffer with no run time calculation required. A more complete description of this can be found in the previous blog entry.



As can be seen above, there are now no visible joints between patches of differing detail, resulting in a more natural terrain.

General Update

Time flies by again. Its been a busy year so far, allot of projects approaching deadlines at the office and I also worked allot on a 2D fluid dynamics tech demo. Development on Decade still continues, however currently at a slow pace.

In the past month I haven't had allot of time to complete 'Parallel Split Shadow Maps', so this is still in a limbo state. They sort of work however sometimes the scene is a mess and other times there are unknown artifacts.

While making the 2d fluid dynamics demo, with the PlayFirst SDK, I was impressed with their usage of LUA scripting. I have researched this topic a little and feel that I will add support for Game Monkey to Decade. As with the graphics and physics layers the script engine will also be extrapolated away so I can, at a later date, add support for another script engine.

I have also added joypad support to Decade to avoid always having to use the keyboard and mouse. DirectInput was used for this so this functionality will not be added to the Ubuntu version any time soon, or until I at least figure out how to do this in Linux.

I am delighted to announce that a friend has at last got on the game engine band wagon and started his own terrain engine called Jelly Engine. His ultimate goal is to generate a procedural universe. Please have a look at this blog and give him grief on how bad his engine is, even though it would be a lie.

Shadows

Having past experience with Shadow Volumes in DirectX I could see a potential issue in using this technique in Decade so I therefore focused my attention on Shadow Maps.

Before giving some detail on my shadow map implementation I will briefly describe why I have bypassed Shadow Volumes for now. Shadow Volumes are created by calculating a silhouette of the mesh from the lights point of view. This silhouette is generated from the raw mesh data. The low poly trees currently used in Decade consist of colour keyed faces. The resulting Shadow Volume generates a shadow of the full face and not just the visible (non blended area). Below is a faked image which shows the shadow that would be generated using the Shadow Volume technique. Notice that the shadow for the tree remains the same regardless if colour keying is enabled or not.



Shadow Maps generate shadows by rendering the scene from the lights point of view and saving the depth buffer to a texture. This texture is then used to shadow the scene. The advantages that Shadow Maps have over Shadow Volumes are

• No colour keying issues
• Complex geometry does not affect the performance of the algorithm. The scene rendering should be efficient as it must be rendered 3 time per light
  
  From Lights point of view. Depth Buffer saved to Texture
  From Cameras point of view with only ambient lighting.
  From Cameras point of view with light enabled and Shadow Map applied.
  
  
  
  The complexity of the geometry is of much higher importance in Shadow Volumes because as mentioned previously the silhouette is generated from the raw mesh data

Due to the limited resolution of the texture map holding the depth/shadow data Shadow Maps can and usually do result in very aliased shadows. In the image below the light is only 75 units from the scene however it is very evident from looking at the car shadow that the shadow quality is very low. The right image shows the depth buffer from the lights point of view which is used to render the shadows.

Below can be seen how the Shadow Mapping technique becomes unusable as the light source moves further away from the scene or as the scene boundary grows. With less shadow map pixels used to represent the shadow of the same area of space the shadow loses form and any relationship with the casting object.

These issues make the Shadow Mapping technique inappropriate for rendering any large outdoor scene. Further research has shown that Shadow Mapping has some advanced friends such as Parallel Split Shadow Mapping. (PSSM). The PSSM method involves splitting the frustum into several parts along the eye vector, and rendering a separate Shadow Map for each split. This allows the area closest to the camera to use higher resolution shadow maps and with the resulting Shadow Map stretched over a much smaller area, less aliased shadows are possible.

Car Physics

Using Joints in ODE basic car physics has been added to Decade. This consists of a car body and 4 wheels. Each wheel is connected to the car body by a combination of 2 joints. These emulate the suspension, steering and the axle.

A known issue with ODE is that when assigning a mass to a rigid body, the center of mass must be (0,0,0) relative to the body’s position. This results in the center of gravity of the car being much to high causing frequent rolls when turning at speed. Top Gear would have a great time comparing the car to some American sports car which has great straight line speed but corners with the grace of a giraffe.

If you note in the video at time 30 seconds, the car is represented to the physics engine as a box. Even when this box is reduced to tightly surround the car the center of mass will still be too high. I feel that if I create a thin box at the bottom of the car, which has 90% the mass of the car, to which the wheels are attached, and connected to this by a fixed joint is the light car body, driving should be allot smoother and realistic.

A fixed Joint is defined as "The fixed joint maintains a fixed relative position and orientation between two bodies, or between a body and the static environment."

As well as this representation working well in Decade it also closely copies real life, with the thin box being the chassis and the larger box, being the much lighter body.

Car model was downloaded from Turbo Squid which as well as selling an excellent range of models, also offers a selection of models for free.

Ubuntu

In an effort to use OpenGL to its full potential, and a feature that is unique to OpenGL over its main competitor DirectX, I have decided to create a non windows version of Decade. Over the weekend I downloaded Ubuntu which is a free community developed, linux-based operating system.

Instead of making my desktop dual boot, I decided to try and use Microsoft Virtual PC, which is also free to download. It was a very easy to create the virtual PC, virtual hardisk and install Ubuntu. I can now access my Ubuntu installation from within my windows environment getting the benefits of both systems.


It took a little effort to get networking enabled, my router requiring some setting changes however once this was complete it was again a simple process to connect over the local network and access the shared drives on my Windows PC. With this setup I hope to use the same source base for Win Decade and Ubuntu Decade.

My first job after leaving university was in a HPUX environment however being a number of years ago I have forgotten allot of the basics. This morning I created the obligatory "Hello World" C++ program, but am having problems building OpenGL and SDL projects.

Decade Meets ODE

Time yet again ticks by. No matter now much I try I can't stop it. As you can see Novermber was a quiet month in the life of Decade. Due to personal reasons I did not have much if any time to program, however last week I returned to Decade and decided that it was long overdue to add some physics to the engine.

Having messed around with ODE (Open Dynamics Engine) a few years ago I decided that I would start with this free physics engine. I am trying to use the same approach in adding the physics as I did with the graphics. I have implemented an extrapolation layer between the game engine and the physics engine with the hope that in the future I can add support for other physics engines without having to change too much of the game code.

Refreshing myself with the theory of ODE last week I have now started to modify Decade. Up to now all transformations, rotations etc.. in Decade were stored as Eulars. ODE rotations are matrix based so rather than have converter functions to change between Eular->Matrix and Matrix->Euler I modified the Decade core so that each object builds its own Model View Matrix. The Projection and View matrices are also build and handled by Decade. Although a little more complicated to code and read this approach does have some advantages. For an object which is static in the world its matrix can be built once, reused time and time again and doesn't have to be updated until the object moves. Using the glRotate, glScale and glTranslate functions this matrix was built for each object every frame.

Now that the basics of ODE have been added I will continue on this course building my Physics Layer. I will create some simple rag doll physics or a vehicle which will introduce me to the topic of joints.

After basic physics is added to Decade I really must invest some time to complete my to do list of improvements on current features. This includes

• Properly fixing cracks in terrain
• Priority Rendering Queue
• Octree V Quadtree
• ROAM Terrain
• Finish Shadow Volumes and Parallel Split Shadow Maps

and after that I need to continue with my future to do list

• Scriptable Particle System and Editor
• Planet Generation
• Some small tech games (Golf, racing etc...)

Atmospheric Scattering

At long long last I have got a grip of atmospheric scattering. Decades implementation of atmospheric scattering is based on Sean O'Neill's amazing research. In the video below you can see the sun rising in the sky as the camera moves around the planet. The word planet is used with grace as the planet is simply a smooth sphere which was procedurally generated with recursive subdivision. (See Post below). Close to the end of the video the rendering switches to wire frame and you can see the planet subdividing by another level.

As always there is a list of improvements to make. The planet is currently rendered in software, each face rendered separately. There is also no culling. Adding hardware acceleration and efficient culling should greatly improve performance. The subdivided implementation of the sphere allows easy culling of vast numbers of faces with a few checks.

I am also going to look more detailed at realtime fractal terrain generation, possibly with Perlin Noise so as I dubdivide the planet as the camera gets closer the result will be a details, rich looking terrain.

Procedural Sphere

While implementing my Sky Dome for atmospheric Scattering a number of issue quickly became noticeable. A sphere generated using the OpenGL function gluSphere or loaded from a mesh file had vertex compression at the poles. This usually causes texture compression/distortion which is naturally very undesirable.

To maintain Decade's procedural capability and to remove the issues with the previous implementation I created my own Sphere function by recursively subdividing a cube until the required resolution was achieved.

Below the two solutions can be seen side by side. On the left is the Sphere created with gluSphere or loaded from a file. The vertex compression is immediately obvious. The size of the face depends on which segment it exists, with faces getting smaller closer to the poles. On the right is my procedurally generated sphere. As you can see there is no vertex compression at the pole. In fact no pole is visually obvious. Due to the subdividing nature of the algorithm each face in the sphere is the exact same size.


I believe I may have achieved allot more than just creating a sky dome with this implementation. Creating a universe with procedural planets has always been on the wish list for Decade but I never knew where to begin. The recursive subdivision appears to be an ideal solution for this. It has level of detail and efficient culling properties automatically built in.

The level of the quad tree rendered defines the level of detail of the planet. Since the root of the planet is 6 quads, it is easy to bounds check these against the frustum and quickly remove unseen areas of the planet and the same process can be repeated for each of the child levels of the quad tree.


By using the above algorithm along with some height maps I believe rendering a full planet should be possible. I look forward to the day when I can roam a planet in Decade then jump in a space ship, fly away and land on another planet.

Oil Painting

For another personal project (web based) I have worked on some image processing, hence the lack of updates this month. Rather than let the new code go to waste I have applied it to Decade too see the results. Here is a normal screen shot of Decade

and here is Decade as an Oil Painting.

I am happy with the results, although now a little unsatisfied that the manipulation is not real time. I'm not sure of the possibility of writing a Pixel Script to do this in real time because it requires sampling multiple pixels in order to create the smudged Oil Paint effect. Despite this I still plan to at least try and implement an Oil Painting script sometime. It would be nice to make a game where it appears that the whole world is painted, and perhaps the levels of the game could be based on classic painting by Da Vinci, Picasso etc.

I have also been working on Atmospheric Scattering this month but because of my other commitments have not yet fully integrated with Decade. I will try and get a video update soon to at least give a taster of my progress.

The other day I found a shortcut to my old website. It has been almost 3 years since it was updated. Hosted on an Irish telecoms provider, I do not seem to be able login to my account from outside Ireland so it has remained static since I left. It has some fond memories for me. This was my start in game programming as a hobby. The host where my game demos were stored is no longer active so you cannot download anything. If you would like to try anything leave a comment and let me know. I will then find the game in my archive and upload it.

Underwater Caustics

Caustics are defined as "The light patterns generated on a surface by reflected or refracted light rays." Imaging that you are in a swimming pool and swimming beneath the water. The sides of the pool are not evenly lit. As the light enters through the surface of the water it is refracted and causes areas of shadow to appear on any surface beneath the water line.


This implementation of caustics is physically fake. I do not represent light beams entering and refracting on the water surface. This effect is achieved by tiling a sequence of textures on the terrain for the area under the surface of the water.

Sequence of textures which are tiled over the terrain

This does require the graphics card to support a 3rd texture unit. If you remember from previous blog entries, the terrain already requires 2 texture units, 1 for the terrain texture and 1 for the detail map to add more realism to the scene. From some quick research it looks as though most modern graphics cards support at least 4 texture units so this should not be a problem.

Water Comparison

With both my planned implementations of water nearing completion it seemed appropriate to run some comparisons.

CPUWater was coded so that Decade could render a terrain with water on PCs which do not support the relevant OpenGL Extensions required for GPUWater. Decade will automatically detect which it can use.

The main surprise to come from running this comparison is non technical. After a few friends and programming peers viewed my comparison video (below) approximately 80% if them commented on how good CPUWater looked and that they thought it looked more realistic than GPUWater.

Scene Rendered with CPU Water

Scene Rendered with GPU Water

The main reason for this is because CPU water moves. Its height at each point varies depending on the tessellation of the mesh therefore it looks like waves lapping the shore. Since GPU water is comprised on only 1 quad and the waves are simulated using bump mapping the shore line is static.

Perhaps I should write a CPUGPUWater. The water will comprise of a tessellating mesh like CPU water, but it will be rendered using bump mapping like GPU water. This might achieve a nice result of having water which moves naturally however also appears to be highly tessellated despite its low poly count.

GPU Water

My second attempt at water rendering uses a vertex/pixel shader along with normal and dudv map's. Using the normal and dudv map's along with the reflection texture, which is dynamically generated each frame, the final effect is achieved.

The image above is the normal map. Instead of using each pixel for a color, the nomal map stores a normal (between -1 and 1). The normals naturally give the image a purple, pink and blue color. What we do with this image is basically use it to bump map our water to give it the appearance of being highly tessellated and realistic. This realism comes when we use per-pixel lighting on the water. If we didn't have a normal map we would just depend on the normal of the water surface, which is pointing straight up, the water would look like a flat mirror.

The image above is the dudv map. It is called that because it's actually the derivative of a normal map. In mathematics the notation for a derivative is du/dv. What this texture does is give us a way to calculate refraction and how the light will react and bend on the water. Notice how the dudv map looks like waves of water.


The image above is the reflection texture. This is caculated each frame by inverting the scene, setting up a clipping plane and rendering the reflective data. Projective texture mapping is then used to apply this texture to the water.

Although I am happy with this implementation there are a few changes that need to be made. Memories of my first implementation of CPU water are coming back. My lake again looks like a mirror. It is too bright and too reflective. It should be possible to see some way under the surface of the water. I have tried to implement the simple changes which were required by CPU water, after I changed to using a reflection texture rather than drawing the inverted scene to the screen, however there is no differnce. Adding Alpha Blending with a fixed function does not seem to make any difference when the pixel shader is used. If I remove the shader from the rendering, a correct flat blue alpha blended quad is rendered. Since the GPU water is effected by per pixel lighting prehaps I need to modify the pixel shader in some way. I have read a few tutorials on OpenGL shaders, however I feel that I need to complete a few more before I have the confidence to say for sure.

CPU Water

As all can see its been a while since I updated the blog so yesterday I recorded a small video of decade. You can now see the engine in motion rather than just static screenshots.

Unfortunately YouTube has really lowered the quality of the video when it was uploaded but it should still give a rough idea about Decade.

The video shows a simple terrain with random trees and my CPU water with vertex projected reflections.



Other features that I am still working on are

GPU Water
Shadow Maps, Parallel Split Shadow Maps, Shadow Volumes
Atmopheric Scattering
Priority Rendering Queue
Octree
Scriptable Particle System

Random Issues

Not a list of random issues, as the name suggests, but an issue with Random Number Generation. Both my procedural terrain generation techniques (Fault Formation and Midpoint Displacement) use pseudo random numbers. The other day when comparing Decade with Decade.NET it was quiet obvious that 2 very different terrains were built even though the same seed and procedural algorithms were used.

Creating 2 basic programs, 1 in C++ and another in C#, I generated 10 random numbers using the seed '12345'. The C++ program generated "7584-19164-25795-22125-5828-23405-27477-5413-29072-23404" while the C# program generated "143337951-150666398-1663795458-1097663221-1912597933-1776631026-356393799-1580828476-558810388-1086637143". I then limited the C# number generation to be between 0 and RAND_MAX (32767) as the C++ rand() function does, but the results were still incorrect with "2187-2298-25386-46748-26131-27108-5437-24120-8526-16580" being generated.

The easiest way to over come this has been to create a Managed C++ DLL with members to seed and create random numbers. This DLL is added as a reference to Decade.NET and it is used to get a random number rather than the Random object. Now both Decade and Decade.NET produce the same random numbers for a given seed any procedural work based on random numbers will match.

Resistance is Futile

It may not be futile, but it is very difficult to resist coding new features when some maintenance needs to be done on what has already been developed. The desire to implement the next big thing is tempting. However I have thus far succeeded in doing what I believe needs to be done in order to improve decade as it exists already.

Friends have told me that premature optimizations are the death of many projects; however I don’t feel that what I am doing now is really optimising. This has always been a learning project, not exactly made up as I went along, but that does have an element of truth. It was best implemented at the time based on what I knew, and through experience learned from my implementation, experimenting and reading I now see there are better and faster ways to do things. Further developments also rely on these better ways of doing the basic things therefore it is important that they are implemented now. e.g. Water will rely on geomipmapped terrain to

A) Reduce the Number of water polygons rendered and
B) Reduce the number of water vertices updated and projected to screen

Improvements made this week are....

Use triangle strips rather than triangle lists when rendering Terrain/Water patches.
I have been told in a forum that the more information passed to the GC (Graphics Card) the faster it can render so therefore triangle lists are the best for performance. I cannot find any information to back this up so I will test for myself, but I find it difficult to believe that this is true. Consider the amount of information that needs to be passed each frame....

Patch Size = 17
Triangle List would have 1734 Indices for Patch of highest LOD
Triangle Strip would have 644 Indices for Patch of highest LOD

and presume there are 1000 patches rendered a frame (in a 1024*1024 terrain there would be 3721 Patches) there is a huge difference in the amount of index data sent to the GC. 1764000 as opposed to 644000. Decade supports lists and strips for terrain patch rendering so I will at some stage benchmark the performance of both.


Remove Terrain Cracks.
In terrains which support Level of Details (LOD) artefact's called cracks can appear. These can caused when a terrain patch has another terrain patch with a lower LOD as its neighbour. In the image below you can see the cracks in the distance. I have removed the skybox because the black background highlights the cracks.

Below you can see an up-close image of the cracks. In reality it would not be possible to see a crack this close because as stated it is when a patch neighbours a patch with lower LOD, and that will always occur in the distance. The wire frame image should make it more apparent why these artefact's occur.

There are 2 methods to remove the crack. The 1st is "Vertex Insertion" into the patch with the lower LOD. This is not a difficult task; however it is the more complex of the 2 methods so we will ignore it. The 2nd and preferred method is "Vertex Removal" from the patch with the higher LOD. Decade presumes that a patch can only neighbour a patch with an LOD that is the same as its own, or has a difference of 1. (i.e. 1 Level Greater than or less than its own). With this being the case, to remove a vertex from a patch we simply navigate the index buffer to the indices relating to the side of the patch in the direction of its neighbour (North, South, East or West) and remove every 2nd index. And to make it even more simple, we don’t even have to "remove" the index. By setting the index equal to the next index in the array we visually remove the vertex from the patch, however it is still theoretically present, but rendered as a degenerate triangle (a triangle which has 2 vertices the same, hence no area) and apparently OpenGL and DX can recognise degenerate triangles and do not even send them to the GC.

To further improve the speed of Decade, all this is pre-calculated. For every LOD which the terrain supports 16 index buffers are created.

00 None Lower
01 West Lower
02 East Lower
03 East-West Lower
04 South Lower
05 South-West Lower
06 South-East Lower
07 South-East-West Lower
08 North Lower
09 North-West Lower
10 North-East Lower
11 North-East-West Lower
12 North-South Lower
13 North-South-West Lower
14 North-South-East Lower
15 North-South-East-West Lower

and during run time the correct index buffer is selected and applied to the associated vertex buffer. Many tutorials I have seen update the index information at run-time however I think this is unreasonable for high performance in a large terrain. In Decade a Nibble (Half a Byte) is used in order to select the required index buffer.

1000 = North Patch is Lower LOD
0100 = South Patch is Lower LOD
0010 = East Patch is Lower LOD
0001 = West Patch is Lower LOD

So the pseudo code for selecting the correct index buffer to use would be

byte IndexBuffer = 0x00;
if North Neighbour's LOD LessThan This Patch's LOD
IndexBuffer = IndexBuffer XOR 8 (1000 in Binary)
if South Neighbour's LOD LessThan This Patch's LOD
IndexBuffer = IndexBuffer XOR 4 (0100 in Binary)
if East Neighbour's LOD LessThan This Patch's LOD
IndexBuffer = IndexBuffer XOR 2 (0010 in Binary)
if West Neighbour's LOD LessThan This Patch's LOD
IndexBuffer = IndexBuffer XOR 1 (0001 in Binary)

For example presume that we had a Patch which had the following Neighbours. North and West = Same LOD as the Patch, South and East has a Lower LOD. Running through the above code we would hit the lines

IndexBuffer = 0x00;
IndexBuffer = IndexBuffer XOR 4
IndexBuffer = IndexBuffer XOR 2

which gives us IndexBuffer of 0110 or 6. Referencing the above array we see that index 6 provides the Index Buffer for a Patch with South and East having lower LOD's which is exactly what we required.

This has been my first attempt to make my posts a Little more technical. I hope I succeeded in explaining how I was achieving certain behaviour in Decade. I would be delighted to hear your questions or comments.

Vertex Projected Reflections

A new implementation was required in order to achieve better looking software water. It is slightly more complicated, a little more CPU expensive but I feel the results are allot more appealing and worth it. No hardware acceleration was used so this should hopefully work on any computer.

The differences are:

Previous

• Invert the scene so that it is upside down
• Setup the clipping plane so that only vertices above the water (those that will be reflected) are drawn
• Draw the scene
• Disable the clipping plane
• Render scene as normal

Now

• Invert the scene so that it is upside down
• Setup the clipping plane so that only vertices above the water (those that will be reflected) are drawn
• Render the scene to a texture to be used when rendering the water
• Project each of the water vertices to screen coordinates. Set these values as water texture coordinates
• Render scene as normal

Further optimizations are to be added for the water. Use a terrain approach to render the water by splitting it into patches and rendering with a level of detail therefore reducing the polygons drawn in the distance. As well as reducing the number of polygons rendered I should be able equally cut the number of water vertices updated and projected to screen.

I have just looked through this blog and feel a little dubious about it. I guess the first question is does anyone read it? If so can you let me know. I am going to update it as often as required regardless because it is a nice timeline of the Decade Engine for me, however if people read it and would like to learn something from it please let me know. I can start to make the posts more technical with sample source, comparisons etc... In essence start to build up a 3D engine tutorial.

Reflections

I find it hard to believe that its been almost a month since I last posted. I guess there just hasn't been much new to show since then, as I was converting Decade to Decade.NET. Progress is slow due to a busy life but its now almost there.

Today, for a change (which they say is as good as a break) I decided to implement reflections. A second render pass was needed. 1 to draw a clipped upside down scene which is used for the reflection and then the normal scene.



Unfortunately these images as usual do not do Decade justice. The water looks like a sheet of glass, however in Real Time with the water moving and light reflecting realism is better. I think I will finish software water soon and then add DUDV maps for hardware rendered water.

C++ to C#

I have written many programs in C++ and many in C# before but this is the first time I have tried to convert a full C++ program in C#. Since both languages have a very similar structure and share allot in common I thought this would be a simple matter but I was very wrong.

Its by no means an impossible task, however the small but significant differences require some rethinking and restructuring of Decade. (Managed Code, stronger typecasting, delegates etc...) I have allot of the core graphics components complete and am now on the File Parsers. It has taken a short while to get a grasp of Regex instead of using sscanf and such functions, but now progress is moving again. Hopefully by next week I will have some screenshots from Decade.NET.

Panorama

As conversion continues, and there isn't really anything new to show, I thought I would upload these these test images. They show randomly generated scenes in Decade (hence why there are trees growing in the water) in panorama form,

June is almost over already!

July has been a quiet month with posts, however development continues. Holidays. Being busy at work. Having custom work to complete outside work etc.... the month has just disappeared.

Deciding that my own custom GUI components wasn't the best way to spend my time, I started development on Decade in C# using Tao for OpenGL. Development is slow but steady. I am currently adding in the file parsers for the 3D file formats and then terrain loaders/generators. With this complete it will be on par with Decade and I can begin working on my Sandbox Editors.

There are no screenshots to show, because I am using the same media as Decade and the screenshots look identical. Hopefully I will get some more spare time soon and can get the rest of the current in development work completed.

Decade .NET

For the past number of days I have been contemplating moving Decade to .NET. Programming the GUI Interface has raised this issue. I am currently spending allot of time programming a GUI System so that I can make Level Editors and a range of other tools for Decade.

Drawing and managing the controls myself was inspired by Unreal Tournament, however my results are nothing like this. I don't have the artwork or the time to match these results. In truth my rendered buttons do not look much different to those I created almost 10 years ago when making simple Mode13h Dos Games. In short, with this method I am spending allot of time with little gain and not really learning anything.

Another possibility would be to make the GUI in WIN32, therefore keep the engine as C++. This would save time in now requiring me to rewrite the engine, however I find GUI work in WIN32 to be hideous.

Although requiring the most work and the most time, I think that converting Decade to C# is the best course of action. With this I get to refresh my C#, learn some more .NET and have a nice and simple way to create good Gui's for my tools. To help me with this I have found The Tao Framework. This will help allot in using OpenGL with C#.

If anyone has any comments or ideas on this plan I would like to hear them.

Thanks

Update

Decade Engine is still alive. It has been about 10 days since I worked on it. Last week I had holidays and I also got a new acoustic guitar so was distracted from programming for a short while. In the few hours that I did work on the engine focus was on making GUI Components and the GUI Manager. I hope that buttons, combo boxes, list boxes, edit boxes etc... will all be supported soon and I can start work on mesh and level editors.

Hopefully I will have some screenshots soon, but so far development in this area has been allot of functional stuff so nothing nice to show.

Let there be Light

Basic lighting has been added to Decade. This adds another slight layer of realism to the scene. In my opinion the screenshot below does not do Decade Justice. The moving water being effected by light and shade creates an impressive effect. I have tried to create a video to upload to YouTube so I can show here but so far the quality hasn't been worth showing.

Patch Culling and Node Tree has been added to Brute Force Terrain. This now exceeds the frame rate of software rendered Geomipmapping, however Geomipping will soon be Hardware Rendered too and will hopefully increase in frame rate.

Other in progress work are Scriptable Particle Systems and GUI Components such as buttons, combo boxes etc...

Software Water

Although I hope that some day Decade is a high end 3D engine supporting the most advanced technologies and rendering techniques, at present I want to make sure that almost anyone can play my games.


My full blown water will be rendered using Bump Maps and Stencil Reflections, which not all Graphics Cards support therefore I have first implemented a simple alpha blended tessellating mesh with a sphere mapped texture. Results are not very realistic however give the impression of water with semi-realistic movement.


In Wire frame one can see the mesh clearly. As the water mesh is constantly moving and is alpha blended it does not have to be as high a resolution as the terrain. The terrain is the images shown is 512x512 whereas the water mesh is only 60x60.

Multiple View Ports

To take a little break from terrain programming I decided to try something else last night. While watching a Formula 1 Grand Prix over the weekend it reminded me of playing racing games and being able to turn on or off the rear view. Having always wanted to implement this I decided that now was the time.

I was amazed at how easy it is in OpenGL to achieve multiple view ports. After 10 minutes of reading an online document I realised that I already had all the code from my OpenGL setup functions so only a little reorganisation was required.


Decade can now support 1 t0 X view ports (I haven't tested an upper limit) and each view port is independently controlled, updated and rendered. They can share scene data or use entirely separate data.

Uses for this within my plans for Decade are currently limited. It was implemented for my enjoyment rather than for a real need, however it should become useful for rear view when in a car, split screen multiple players etc..

The Sky's the Limit

Sky Boxes have been added to Decade, and as a friend has commented they give the scene atmosphere in more than 1 sense. The sky boxes used were taken from Hazel Whorley who offers his creations free for use in non-commercial projects. They are some of the best free sky box textures I have ever seen.

I will use sky boxes for a while with Decade however I want to soon implement sky domes. They have many advantages over sky boxes. Due to the cube nature of the sky box it is very difficult to animate the sky without the cube structure becoming obvious to the user. The dome removes this and will allow me to set the time of day and add procedural clouds.

Erosion Filters

Having put the issue raised in blog entry If a man owns land, the land owns him on the to "Fix It Later" pile I continued development of Decade. All my documented issues are always on my mind as I research and develop, so yesterday while searching through random Terrain documents I found a Box Filtering Height Maps for Smooth Rolling Hills tutorial and immediately thought it might be useful. Even though I am not always going to want to have rolling hills I thought that such a method might enable me store the terrain in its original 1 or 2 byte format instead of using 4 byte floats.

Terrain with height values stored in 1 byte

Terrain with height values stored in 4 bytes

Terrain with height values stored in 1 byte and modified with Erosion Filter of Box Size 3 and 1 Iteration

As you can see, running the Erosion Filter on the terrain greatly improves the quality of the 1 byte height field. (When I say 1 byte height field I mean that the data in the .raw file was stored in bytes. The height field is still stored in 4 bytes (float) within Decade). There is a little loss of detail compared to the 4 byte terrain however depending on the game and environment this may be acceptable.

Terrain with height values stored in 1 byte and modified with Erosion Filter of Box Size 11 and 5 Iteration

Care has to be taken when using the Erosion Filter. As you can see above running with too large a box size over many iterations starts to remove allot of the detail from the terrain resulting in a flowing rolling landscape. Again, this may be desirable in certain instances and not in others.

What this has thought me is that there is no right answer to the question I am asking. It all depends on personal preference and the requirements of the game at that time. To accommodate this I am going to allow a broad range of options. My custom height map file will be modified to allow the user specify how the data is stored.

Currently the simple file type is
Width (2 Bytes)
Length (2 Bytes)
Data (Width * Length * 4 Bytes)

so by adding in a type field the user can save and load as they desire

Width (2 Bytes)
Length ( 2 Bytes)
Type (1 Byte)
Data( Width * Length * Type Bytes)

I hope that this,along with the box and any other Erosion Filters added later, will allow Decade deal with a large variety of requirements when rendering/storing its terrain.

A little forrest.

As I mentioned in a previous post, I really wanted to add trees and other vegetation to my terrain engine. I believed that this would greatly add to the atmosphere. My first desire was to create all these trees and plants procedurally. After searching online for a while I found a few good tutorials on how to achieve this but have decided to place that idea on hold for a while. Eventually I would love to do this. It would be great to have procedural plants on a procedural planet in a procedural solar system within a procedural universe. :)

For now I have decided to use mesh's for the plants. Again, rather than waste my time trying to model them myself or look for appropriate free models online (any I found either looked wrong or were to complicated) I choose to purchase the tree packs from Loopix These are decent quality, low poly trees which are ideal for my needs.

Currently a small selection of the available trees are just placed at random on the terrain. Already I think they add a whole new feeling to the demo.

Procedural Texture Mapping

Decade can now generate its terrain textures procedurally. This is a big step as each terrain created automatically gets textured based on its unique attributes. Instead of just showing you a screenshot I will briefly explain how the textures are created.

A set of base textures is gathered. These are plain textures of all the environments which will exist in the terrain. e.g. sand, grass, rock, mud, snow etc...



Each of these environments is given

• optimum height (The best height at which this environment exists)
• min height (The minimum height at which this environment exists)
• max height (The maximum height at which this environment exists)

By cross referencing these values with the height map, the textures assigned to each terrain which exits at the given height are blended together with higher preference going to the more optimal terrain.

The result is the above texture which is then applied to the terrain. For my first implementation of this algorithm I am happy with the results, however as always there are many improvements which need to be added.

• Tiling textures instead of stretching them
• Add support for applying the detail texture to the terrain texture at this stage to cards which do not support multi-texture can still have detail at no extra cost.
• Some better logic for texture blending instead of just checking the height. The environment in a valley is different to that of a cliff face at the same height, or rocky outcrops on a snow covered mountain etc...
• Add lighting so that features are enhanced.
• Add vegetation to add more realism.