Archive for April, 2009

Update On Progress (15 April)

Again its been a while since the last update, and again, not due to any inactivity, but rather I’ve simply had too much to do.  In this article, I’ll just go over what I’ve implemented and what I’m still struggling with in the last 3-4 weeks.

Change in Game Concept:

Its nothing that big really, but I have decided for Britonia, to limit the size of the playing area to one solar system.  Originally, because I am procedurally generating all the content, I had planned to generate as many planets and solar systems as what the player could venture to, using a ‘portal’ system, which would each time take you to a new procedurally generated world (remember, procedurally means it will always be generated exactly the same as long as the seed for a planet doesn’t change).  Recently though, I have spent a lot of time flying around the current planet of Britonia, and it is massive.  So much so, that I am starting to think that it would just be unnecessary to have so many planets and systems.  The player should also have a central ‘HUB’ around which to play, something to call ‘home’; and I think this would be lost if the universe is too big.  That said, I will still add the code for such a universe in the engine, because so far I am really enjoying the procedural aspect of programming.  maybe in the future this could be put to better use, like with a space sim.

So the game will take place within one solar system.

The Solar System.

Although it sounds like a big change, it really isn’t. The game solar system will have at it’s centre one sun, and around it, nine orbiting planets.  I would like to try and model the game solar system around our  own solar system.  There are two ways which I thought about implementing the solar system, and here they are:

#1 – Create a normal scene graph whereby all objects rotate and translation around their parent bodies.  This is conceptually the easiest of the two methods, Each planet would of course have its own set of orbit variables, such as distance from sun, number of days in years, minutes in day etc.  The big disadvantage of this method is that the orbits are round, and not ecliptic – but I this doesn’t really matter for Britonia, as you will never zoom out far enough to appriciate the planetary orbital paths.

#2 – The second option, which I was actually considering, was to implement the orbits using orbital elements.  I only consider this because I originally wanted to generated more than one solar system. This method accurately calculates planetary orbit based on time and date etc.  This would be again overkill for Britonia, especially if you only saw a planet in the Britonian sky once every 9 months or something.

So, as you can probably guess, I will be implementing first method.  I have already started (and have some screen shots for you below).  The only other thing which I had to take into consideration so far is the draw order.  This is nothing overly complicated or time consuming.  All the planets are sorted into order from furthest to closest (based on camera position), and then rendered (i.e. back to front).    The planets will probably be placed so that they are visible from the surface of Britonia (maybe not all planets, but definately enough to get that ‘fantasy’ feeling; check out the screen shots below).


I have also started looking at flora generation.  There is a really good project here on codeplex by Asger Feldthaus which uses the Lindenmayer System to proceduraly generate trees.  I am hoping to implement something similar (although a little less complicated; e.g. without tree profiles etc.) with imposters and point sprites, so that the trees can be seem from high altitudes.

Planet Texturing:

I have also added the code to assign textures to the terrain based on slope as well as height.  This was planned for a long time, but I have always had problems generating the gradient.  In order to get the gradient of a vertex, you use:

float lfSlope = Vector3.Dot(vertexNormal, upVector);

This returns the dot product of the vertex in the [-1,1].  0 means the vertex is flat, 1 means it is a straight up slope (perpendicular to the surface), and -1 means straight down.  We actually only need the absolute value  [0,1]of the gradient, as this will be passed to the pixel shader along with the height (again in the [0,1] range) and this will be used for the texture lookup.

I still apparently have a slight problem with this however, as it appears the value is not exactly in the [0,1]range, but rather between [0,0.5f]. I’m not sure why yet, but when debugging the code, it all seems fine.  I suspect it is how I generate the up vector, which is different for each vertex on the planet, but at least it is working.

Other Areas.

Other areas are generally the same.  For the most part now, I find I end up playing with the heightmap generation and then flying around the planet for a while checking the texturing, which means that a lot of time is wasted just exploring, and also that the heightmap generation code is constantly changing.

I still haven’t managed to get the terrain patch generation (heightmap, normalmap and diffuse map) on the GPU yet, but I will have to get that ready soon as I plan on creating growth maps etc. and soon I will have to start looking at off-loading some of the CPU work on the GPU.

Now for the screeshots: