Galaxy Generation:

On a slightly more upbeat note for Britonia I have made a start a few more things, the first of which is the actual galaxy generation. This is going good and from the initial results I’m actually quite excited for getting it finished. There are a few kinks to work out which seem sound in theory but I’m having trouble getting them to work in the game. One such thing is the change / relationship between galaxy space and star system space.

For example because double precision isn’t enough to cover the distance of an entire Galaxy, I must always have a point of reference for the camera to use as the world space origin. It seems conceptually sound to say, have the main star in a solar system act as the point of reference for the world space, and then switch this PoF as the player warps aroung the galaxy, but actually generating the galaxy around the camera, without first knowing the exact location of a planet has got me a little stumpted. I’ve got a few ideas, like having a perminant planet(s) which are always ‘there’ regardless of the galaxy seed. Another idea is to use markers to remember the locations of special planets (this was my idea for saving and loading games), but again – for them to work the galaxy must have already been generated to get this information.

Which continues on to the next problem I’ve run into which is the initial generation of the galaxy, and more specifically saving the player position within it. I’m pretty confident I’ll get it working in time and once I fully concentrate on it again. I will definately do another full article on the galaxy generation as it is a very large part of the game play.

The galaxy generation uses octrees to managing the placement of star (systems) based on the depth of the octree around the camera. This is pretty much the same as Flavien Brebion outlined in his article here. I still have to define the function which will shape the galaxy.

Asteroid Rings
I wanted to add a little note on asteroid rings for planets as I have also got pretty nice results for this. Unfortunately again this isn’t finished yet and I still need to improve the performance, especially when rendering the individual asteroid geometry. The geometry for the rings are defined in ‘real’ size so they will offer pretty impressive visuals when encircling the planets.

The Story and Factions:

I also made a start a few weeks back on the story and factions within the game. I have gone with a classic Star Wars sytle galaxy plot, with two main factions battling on an ‘epic’ scale. As it seems to me to be too easy to make overcomplicated plots with space simulation games, I wanted to try and keep the number of factions and important characters to a minimum, plus I am not overly confident in my ability to create engaging story so I will be sticking with basics; good vs. bad. There will be 4 four main factions in the game, 2 major and 2 minor:

The Galaxic Imperium:
The Galaxic Imperium rule the galaxy with an iron fist. No single organisation or body can match the Imperium in terms of resources or military power, and their rule is absolute.

The Revolutionary Alliance:
The revolutionary alliance directly oppose the Imperium. Whilst they very rarely face the Imperium in open combat, the Revolutionary soldiers are oft involved in more covert operations of sabotage. The RA seek to restore a people’s voice to the galaxy and reinstate a Repulic.

The Union:
A collection of many powerful multinational companies with near limitless credits and heavy lobbying in the ruling Imperium. The Union has arguably the most gifted scientists who are constantly prototyping new mechanical, biological and chemical weaponary, albeit using dubious and questionable work ethics. The Union run the majority of star and trade ports throughout the galaxy.

Chruch of the New Aeon:
A religious group bent on converting all the entire population to the Chruch’s beliefs. The Church are openly hostile to all who repel their offerings of a new faith. Unfortunately due to some high profile figures in the Chruch’s hierarchy, the Chruch seldom face finacial hardship. The Chruch also have an advanced branch of technology not available to the Union or Imperium. The original source and development of this technology is unknown.

As you can see the naming of the factions are nothing unique, but like I said, I am trying to keep the story quite basic. I aim to let the player freely roam between helping any of the four main factions and letting them build repuatations. There will be a main plot for three of the four factions in which the player can help tip the balance for a win. More to come.

Things on the Side:

On a last note, I’ve created a new blog which I will be using for writing up a little about some of my other, somewhat smaller projects. I decided about a month ago that with Britonia taking so long, I’d like to try and make a few smaller games for release on Windows Phone 7 and the Xbox. The blog is here:

http://xnabits.wordpress.com/

there’s not much on it yet, but hopefully that’ll change.

You can read the previous article here.

To be honest, I wasn’t very happy with details of the last post and I’ve wanted to expand on it ever since. The idea was to give people who wanted to work on a planet renderer enough information to make a start on their own project with ideas for the basic planet geometry. As previously mentioned, my planets are based on quad trees which are orientated around the planet center to form a cube (therefore 6 quad trees are required, one for each cube face). My LOD is then based on the distance of the camera to the particular node. This is slightly contrary to ‘traditional’ quadtrees which are usually split based on a number of objects assigned to a particular node.

There are many different implementations for both flat and spherical terrains (more information), but I find this method my favorite because of the ease of working with the different nodes of the quad tree; knowing that the size of a node is n^2+1 means texturing is easily accomplished and finding specific vertices in the grid becomes trivial. In this article I’m going to cover the planet geometry again, albeit in more detail.

Quad trees:
Quad trees can be a huge help in optimizing terrain rendering. The basic idea is that we want to define a series of bounding boxes which contain parts of the terrain at different scales, which get progressively smaller (each node will be 1/4 the size of its parent node). We can use the bounding boxes to check which parts of the terrain are visible, starting at the root (the largest BB) and recursively calling the children all the way down to the tree leafs where all our geometry and sceneobjects lie.

Implementation :
We start by defining the root node of the tree which encompasses the entire area of the terrain (remember we are working with a 2d plane now – so this can be done the XZ axis). Each node has four child nodes (which can be null in the case of the leaf nodes) and a bounding box volume which defines the extents of the node along each of the two axis. It can also be beneficial to store the center point of each node, which I’ll come to later.

The general flow goes like: starting with the root node, subdivide it to produce 4 children of equal size which fit within the current BB and pass in the new bounding information from the root node to each child. This subdividing of nodes happens ‘n’ number of times. n can be either a predefined depth variable for how many levels the quadtree will have, or a minimum amount of objects allowed in a node. Once we subdivide down to this depth level we have reached a leaf node. The leaf node should contain the terrain geometry and possibily a collection of sceneobjects within its bounding volume.

One representation of a quadtree would be:

Rendering this terrain now only requires one call the draw function on the root node, where a bounding box check will be done with the camera view frustum. If the BB is within or even partially within the frustum we call the draw function of each of the children in the tree. This happens right down the tree until a leaf node is reached. Once at the leaf node, we know it is visible by the camera and so we can render the terrain mesh and the sceneobjects attached to the node.

This can save a lot of work; imagine that for a high level node which isn’t within the camera frustum, we can immediately cull this along with all its children saving all those draw calls. You can also further benefit for the fact that if a particular bb is fully within the camera frustum, you can go straight to the leaf nodes and draw them, saving on furter BB.Intersection() calls.

Using quadtrees can also narrow down the amount of work needed between scene object interactions because each scene object is assigned to the node within whos bounds they lie. When it comes to doing things like collision checks then you only need check each object with the other objects in the same node.

Storing the scene objects and the terrain mesh in the leaf node isn’t the only way to do this as you could also store them in each of the nodes at different depths (like chunked LOD). But as there are many ways of doing this, your implementation will depend greatly on what you want to achieve.

Defining the Planet Geometry
The above example of the quadtree works quite well for traditional terrains but for the purpose of creating a planet we need to actually define the spherical geometry based on a cube. This means defining the cube first and then transforming the vertices to form a sphere. In order to do this and make sure the LOD is sufficent to get down to one meter at surface level we need to calculate the size of the cube.

This is done using a binary logarithm of the radius of the planet, taking the gridsize of each node into account. A binary logarithm will tell you by what power or exponential you need to raise a base number to get the desired number. (or simply put, how many times must I subdivide a number to get to two). This is easy to work out:

float _iRadius = 32;
int _iMaxLOD = (int)Math.Log2(iRadius * 2.0f);

This function will tell us that we need to subdivide a cube of size 64 (radius = 32), six times to get to a resolution of two (meters);

The only problem now is that 6 will subdivide the cube down to a resolution of 2 – but what if the patch grids have a size of 32^2? This would mean the resolution of the vertices on the surface would actually be a lot smaller than our desired 1 meter. To correct this we simply take the binary logarithm of the gridsize (n^2) and subtract it from _iMaxLOD. Luckily, these LOD functions only need to be called when initialing the planets, so we don’t really need to worry about performance.

Defining a cube of vertex Grids:
Defining a cube using quadtrees isn’t particually hard once you get used to it, but it can be a pain getting the orientation of the cubes quite right. Each of my terrain patches has a buildMesh() function which, when called, generates a grid of vertices around a center position on a given plane. The individual planes are very important as they will define which quadtree belong to what cube size. The function looks similar to:

private void BuildMesh(Vector3 centerPos, Vector3 axisX, Vector3 axisZ)
{
    // temp array for demonstraion
    VertexPositionTextureNormal[] vertices = new VertexPositionTextureNormal[width*height];

    int index = 0;
    for(int u = 0; u < height; u++)
    {
        for(int v = 0; v < width; v++)
        {
            vertices[index].Position = new Vector3(centerPos + (axisX / width) * (v - width / 2) + (axisZ / height) * (u - height / 2));

            index++;
        }
    }
}

Calling this function 6 times passing in the correct local orientations should produce a cube made up of 6 grids of vertices like this, where the red denotes the local X axis and the blue denotes the local Z axis. The back faces are missing in the diagram:

Based on the size of the cube which we calculated above, you should ensure that when defining a quadtree cube face, at least one component is equal to CubeSize / 2, and that the other two components are CubeSize. This will help created a closed cube.

Making the World Round:
Projecting the vertices from a cube out to a sphere is very easy. Consider the following diagram and the instructions to see how to do this:

1) Center the cube on zero (0,0,0).
2) Normalize each vertex in the grid. This will create a unit sphere.
3) Multiply the vertex position by the radius of the planet + the height of the terrain at this point, which will scale the sphere to the desired dimensions of your planet.

and all this convets to a simple function:

private Vector3 GetWorldSpaceCoordinate(Vector3 cubePos, float height)
{
    cubePos.Normalize();
    return cubePos * _fRadius + height;
}

The height above can come from a variety of sources. I use 3d perlin noise in a number of shaders which render the heightmaps for each patch to several rendertargets of varing sizes. I then use the corresponding texture values are coord U,V to get the height for the terrain grid at X,Y. As long as the size of the rendertarget matches the patch nodes this seems to work fine.

Following the above instructions, you should be able to generate spheres which resemble the following image:

LOD Selection:
As with everything else, there are numerous methods for calculating when to split each quadtree node into smaller pieces. I don't think this has to be particularly complicated to get good results. One thing I would suggest though is splitting the nodes of the quadtree based on the distance from the camara to the center of the closest edge on the bounding box. Using calculations which depend on the distance of the camera from the center of the node can cause huge differences at higher LOD levels when the camera is stradling the borders of nodes.

Other Little bits:
Of course this article only outlines the way I have defined planet mesh geometry and there are still many things left to do after this. Here are a few of the many things needed to get this geometry resembling a planet:

CPU heightmaps - I wrote this article to describe how to generate heightmap textures using the CPU.

GPU heightmaps - the same again, just adapted to work on the GPU

Real Scales and Imprecision - If you want to create realistically scaled planets, you will inevitably encounter issues with 32-bit imprecission which I discuss a little in this article.

Depth Buffers - This is another important issue when using realistic scales because all that distance between planets wont fit correctly into a 16-bit / 32-bit depth buffer.

Quite honestly I glossed over the fuel and payload section in the previous article because I knew it would be a problem and I hadn’t quite decided yet how to handle the issues in-game. The question is of course “how realistic will the game be in terms of fuel and fuel consumption”? and “will be by fun/entertaining for the player to fill up the cargo hold full of fuel just to be able to leave the atmosphere of a planet”?

The three approaches which are most obvious at this stage are:

1) Simulate Realistic Physics and Fuel Consumption : This is certainly an appealing approach and a lot of people would perhaps admire such a simulation for its realism, but will definately be off-putting for casual gamers. Furthermore, accurately simulating spacecraft using real physics models is extremely complex and involve many factors; all of which aren’t really feasible or a benefit to simulate. This would also introduce issues of ship design. As an example, the thrusters required for huge spacecraft to launch would themselves be huge; and would have to appear to scale on the ship. Add to this the need to place thrusters all around the ship for rotating and ‘strafing’ etc. and the ships will no longer look slick and cool (yes cool) but like big masses of ugly efficient-functionality.

A few other less-than-fun issues introduced with this system are ‘what do you do if the player runs out of fuel?’ As always there are a few ways of handling this, but short of actually waiting for someone to come and pick you up would break the realism we were striving to achive in the first place. This is a concern.

2) Forgo Fuel Consumption: This approach was adopted in the Elite series whereby conventional thrusters didn’t require fuel for acceleration; and this definiately had its merits. For one, the player only needed to concern his/herself with purchasing fuel for hyperjumps to use the jump drive and there was nothing overly complicated with taking off and leaving a planet. Just ‘launch’, rotate the ship upwards and fire! As you can read in Robert’s previous comments, this eliminates the issue of taking off within a the gravational area of a planet.

3) Use a mixture of the two above. : Now I’m all for realism and I’ve read a lot of comments which go both ways on just how real to simulate things like this, but I’m just not convinced that simulating real space flight dynamics will be fun for the player. Also, to pass up the issue of fuel will remove some of the element of ‘danger’ and planning I think has the potential to be enjoyable. So at the minute I plan on using a mixture of the above, but perhaps a little differently than tradional space sim games.

I am thinking about including three different engines types for flight, each of which will be mountable in one ship thruster slow/position. Here are the three types (not including Jump-Drives):

ION/Plasma Trusters

ION thrusters are used in real life for long distance space flight. They are typically favoured because of the relatively low fuel consumption when compared to traditional chemical engines. This improvement in fuel consumption is because electic thrusters typically offer much higher specific impulse (this represents the change in momentum per unit amount of fuel).

There are a few draw backs with ION thrusters though, which when implemented in the game will lucky add a little diversity. The first draw back is that they don’t provide as much thrust compared to chemical thrusters due to practical power source contraints. The second draw back is that they only work in environments that are void of ionized particles, so if you decide to equip just ION thrusters on your ship, you wont be able to land on planets with atmospheres.

There are three kinds of ION thruster in real life (Electromagnetic, Electrothermal/Plasma and Electrostatic). There will be diferent ION trusters available within the game but the differences will be purely cosmetic (different thruster description, different coloured beam), with all thrusters performing with the same characteristics:

Pros :
Low fuel consumption (read: no-fuel consumption)

Cons :
Cannot fly within atmosheres
Low thrust (force) output

Summary :
A good option for beginning players as the there is no need to worry about fuel consumption and/or running out. Hopefully more experienced players will want to eventually opt for more power chemical thrusters for greater acceration.

Chemical Rocket Thrusters

Currently all spacecraft use chemical rockets for launch. Chemical thrusters require a large amount of fuel to operate, but provide consideratly more thrust than ION thrusters. In the context of the game, chemical thrusters will be required to navigate within the atmosphere of a planet, and will indeed require fuel to do so, although the fuel consumption may not be realistic:

Pros :
Provides much more power compared to the ION thruster.
Functions in atmospheric conditions (i.e. planets with atmospheres).

Cons :
Requires fuel.
Would be plausible that the player can run-out of fuel and thus would need rescuing.

Summary :
A good choice for players who want faster ships but requires a little more journey planning and management of fuel.

Hybrid Thrusters
Whilst perhaps not currently technically possible I would like to include some kind of hybrid technology to make the game more sympathetic to new players who perhaps don’t want the hassile of outfitting different ships and just want to ‘shoot things’. The hybrid engines will non consume fuel in outerspace, and will require significantly less fuel when within a gravatational area. This will come at the expense of having significantly lower thrust outputs then the chemical or ION/plasma thrusters.

Pros :
Offers both the benefit of power provided by the chemical engine and the ease of mind of a fuel-less alternative for emergencies.
No restricts on environment conditions

Cons :
Provides less acceleration than either the electric or chemical engines of the same class.

To Sum Up

So hopefully with the details mentioned above it should be a little clearer to see what I intend to do. If you decide you want to outfit one ship for space dog-fighting, then you may want to use chemical rocket engines and refuel often for the advantage of higher accelertion. If you are a trader, then perhaps ION thrusters would be beneficial considering you needn’t worry about fuel on long journeys. The last question which I haven’t address yet is the actual consumption of the chemical engines, however this will be fun-factor based so its a little too early to say.

-John

Aim:

My aim is to make a list of ships, similar in structure the one found here, which should offer a good overview of the capabilities of each ship. As the ships in HORIZONS are to be modular (with interchangable components), each component should be believable in scale and capabilities, affecting the ship as one might expect.

First Stumbling Steps:

What is perhaps obvious, but easily overlooked, is that the physical attributes of a ship need to be reflected in the visual representation of that ship. Initially I created a draft of the ship list and created a nice balanced amount of varied ship classes, even going so far as to defined the hull mass, engine classes and max acceleration/thrust.
When I started to model the Locust I realised that it was quite hard to get the ship to match up with my expectations on paper. That’s not to say it isn’t possible, but I felt modelling the ship first and then working out a set of matching attributes based on the model would ultimately be an easier endevour.

So now I calculate the attributes after I have setup the basic shape of the ships in Blender3D, making sure that have the same dimenions as when they appear in game. As an example of a scout ship, the ‘Locust’ ship has dimensions of 26m / 12m / 6m, with 2 static hardpoints and 1 turret.

Mass, Volume and Density:

My first step was to look at what is needed to work out the acceleration of an object, as I was eager to define how fast each ship would be in-game. This is given by the simple formula:

The force (F) will be defined by the engine class and number of engines on the ship, so we can come back to this a little later. But first I would like to look at the volume and mass (m).

So how do you calculate the mass of an object? A quick google search will reveal that mass is measured in Kg, and that mass is equal to the volume of the object multiplied by its density. Well the density of an object is defined by the density of the materials used to make the object. There will be six main parts which make up a ship in HORIZONS, so is the break down of what makes up the ships:

Hull: The shell of the ship, the hull, defines the basic hit-points (tons). All ship hulls in HORIZONS will be constructed from aluminium, which has a density of 2700 Kg/m3. Taking the volume of the Locust, mentioned above, with a hull thickness of 5cm, the mass would be 135845.2Kg, or 133.7 tonnes (long)

There will also be an option of adding armour plating to the hull of a ship. Armour plating will be made of steel, which has a much higher density at 7850 Kg/m3 which should add a significant amount of tonnage.

It is obvious that just using the rectangle dimensions of the ship is not the most accurate (indeed it is actually quite inaccurate) but it will suffice for my uses as at least the ships will all have a relative amount of inaccuracy in their total masses. It will of course be possible to tweak the overall masses etc. later for balancing out issues and inconsistancies.

Generators : Generators produce electrical energy for use by the different components of the ship. The power generators will be constructed from steel.

Engine: There are two different engines available; sub-light engines for relatively short distances of say, within a solar system, and then there’s jump drive engines. Both types of engine will be constructed from steel, although it is very likely I’ll change the mass of the engines to tweak performace of the ships.

The engines will not take electrical power directly from the power generators, and so will work independantly, running on there own powers sources (hydrogen fuel, nuclear cells or whatever).

Components: There are many different components available, each adding different perks and features to your ship. Component material is mainly Polyetheretherketone, which is a plastic with a density of 1320Kg/m3. The components will require a specific amount of electrical power to function.

Turrets/Pylons: Both turrets and missile pylons will be constrcted from steel again with a density of 8850Kg/m3. I have picked a high density for turrets and missile pylons because heavily armed ships should really have a handicapped acceleration.

Static Hardpoints: The static hardpoints on the ships are what you fire when in the main view first person mode. The number of hardpoints will vary, but typically a ship will have either 2 or 4. For mass and density, they will be comparable to the turrets.

n.b. obviously the density of metals can vary depending on various alloying elements added (tungsten or chrome for example), but these values are taken for simplicities sake.

So that’s the different parts of the ship covered, let’s move onto the actual mass of the ship. We can’t just calculate the ship’s mass from its volume (width*height*length) * denstiy, as this will give the density of a solid object. For this reason it is necessary to calculate two volumes, one for the outer volume of the hull and the other for the inner volume; the empty space. I do this by assigning a wall thickness parameter to the ship, which can be scaled by the player (for a cost in the ship yard) to gear the ship up as either a heavier, more armoured craft or a lightly amoured affair with a faster acceleration.

I mentioned above that I will be using steel as extra plating which can be installed around the ship to increase the hit points. The plating added to a ship will be measured percentage (0% plated – 100% plated). As with the hull thickness, the amount of plating (which has a high density) can be added to increase hit points at the expense of acceleration. This will be available to players in the ship yards.

So now I have the mass of the empty ship (Kg) minus all turrets and components still, as well as the internal space (inner volume m3). We still need to work out two more factors which weigh into the overall mass of the ship, those being fuel and payload. I will not show that here, but instead cover cargo a bit further on as the fuel and cargo will also affect the acceleration of your ship when playing as they affect the overall mass of your ship.

As you can see though, to get the total mass we need to take the hull, components, hardpoints, engines and interior objects into account.

Next up is to define the Force that can be applied on the ship, then hopefully I’ll be able to work out some actual values for acceleration.

Engines and Force

I have created a first draft of proposed engine sizes and thrust generated. I got the values for the engines based on the Rocketdyne Wikipage and this Boeing page but I’ll undoubtidely have to change them when I have larger craft to fly because these are totally untested. Here is an example of Engine classes and the thrust they produce:

n.b. the SI for force is Newtons (kilo-, mega- giga-)

So now we should be able to calculate the acceleration of a ship based on the engine class installed in the ship and its total mass. Bare in mind that this is just the sub-light thrusters, and the jump-drives will not be influenced by the mass of the ship itself, but rather the mass of the target and the distance.

So, looking back, we get the acceleration from

Let’s take a look at the Locust MK I ship. it has by default 2 E7 class engine thrusters:

And lets take a look at possibly one of the much larger ships in the game :

And that’s pretty much how I plan on working out the acceleration when I create the rest of the ships.

I will cover jump drives in a later article, when I have made some more progress on the octree scene graph and galaxy generation.

Cargobay, Components and Life Support

Lastly I’d just like to cover some ideas I had for the cargo and transportation with the ship.

As you can see above I already have the interior volume. The interior of the ship will be split into three areas.
Here’s how I plan on assigning the interior space:

Life Support: For each crew member and/or passenger seat on the ship an area of 4m3 will be set aside and used as living space. Living quarters will be needed for all crew, passengers, captured pilots and purchasing slaves from the outer colonies on the black market. So, if you have a small ship with only 4 meters^2, then you cannot pick up passenger missions because as the pilot you’ll already be using the living space.

It will be possible to extend the life support on your ship, but you’ll end up eating into the cargo bay space.
Life support will be measured in seats, with passengers and pilots taking 4 square meters. Space slaves and hostages will take 2 square meters.

Components: In order to install additional components to your ship, you’ll need to ensure that you have the following:

Enough space to install the component (taking from the interal volume)

A free component interface

Enough free electrical power

Each of these 3 points are actually quite flexible, and providing the player has enough credits they’ll be able to install extra component interfaces for a fee (which increases with the total amount of interfaces already on the ship).

There is a difference here between the space required and an interface. The space will come directly out of the interior volume of your ship (so again eating your cargo space), but further to this, if you want to install 6 components you’ll have to first install 6 component interfaces.

Cargohold :

The remaining interior volume will be assigned as the cargohold (m^3), and it will be here that any trade goods will be held when transporting. The amount of trade goods you can transport will be restricted only to the volume (not the mass/weight).

When purchasing and outfitting your ship, you’ll be able to set the percentage of interior volume (minus the life support) which will be assigned between cargo space and component space.

And thats about it. One thing I’d like to say is that most of the information is based on what I have recently read on various websites (after apparently not paying enough in physics class at school). If you happen to see any thing above that is plainly just wrong, or you feel could be done better then I appreciate any comments.

-John

Well, the time has finally come that I have started to model and texture in-game content. This is the bane of the hobbyist programmer, but time and consideration are definitely in order when modeling content because if it doesn’t look good, nobody is going to want to play your game (oh how I loved the Amiga, when it wasn’t about graphics, it was about gameplay).

For me the decision to go with a particular set of software is usually pretty easy; the less it costs, the more likely I am to give it a chance. Hey, I’m not a professional programmer, nor am I an artist and as Britonia is purely a hobby project, its just not viable to spend €1000s on professional software packages. But alas, that doesn’t mean that I have to use a sub-standard set of tools.

Modelling:

Many times when I browse any XNA forums, I run accross the same topics: “Which 3d modelling program is best?”, so this is where I’ll give my 2 cents and also run through some of the features which I have used so far, and how they can be used in conjuction with XNA.

As stated above, my modeling tool of choice is Blender3d (website). The biggest negative point mentioned in the forums for Blender is that the learning curve is too hard, but I honestly don’t think its any harder than learning 3ds max. Whether a beginner chooses to use Blender or Maya/3ds max it is going to be hard and time consuming; but that’s modelling. Its just a question of which product you choose to invest more time in. After a little while, and a run through the tutorials I found the blender interface quite intuitive; and it certainly doesn’t fall short on the features list.

One change I would definitely recommend making though is to modify the FBX export script to include opaque data when exporting to FBX files. Opaque data are values which can be assigned to individual meshes within blender (and then imported with the model in the content pipeline). This is pretty good because it allows the designer to specify different contraints on different meshes. For example, in this video (youtube link), you can see I have put white planes on the top of the ship which are to be turret points; and within the opaque data fields for this mesh I have specified:

Name: Turret
Size: 1
MeshName: <>
…

This is then read in in the content processor and used to fill a ship attributes class which is then stored in the Model.Tag. So the content pipeline can see from this example that this is a turret mount point, with size and the name of the mesh. I can then use the AbsoluteBoneTransform for this mesh when drawing a turret model and it should appear on the ship.

Exporting Opaque Data:

Opaque data is not automatically exported with the default FBX export script, so we do have to make a few changes. I found a nice article about modifing the export script to include this data (link here). (thanks to Ronzan for giving me the link, and Kibix for writing it).

You can get a modifed version of the FBX exporter from that website, but I actually had a few problems with that exporter as it is, so I had to copy just the following parts into an unmodified version of the default FBX export script:

# Edit by Kibix
// This is the part which writes the opaque data to the FBX file
properties = ob.getAllProperties()
for property in properties:
    if(property.getType() == "STRING"):
        file.write('\n\t\t\tProperty: "%s", "enum", "A+U", 0, "%s"' % (property.getName(), property.getData()))
    if(property.getType() == "FLOAT"):
        file.write('\n\t\t\tProperty: "%s", "float", "A+U", %s' % (property.getName(), property.getData()))
    if(property.getType() == "INT"):
        file.write('\n\t\t\tProperty: "%s", "int", "A+U", %s' % (property.getName(), property.getData()))
    if(property.getType() == "BOOL"):
        file.write('\n\t\t\tProperty: "%s", "bool", "A+U", %s' % (property.getName(), property.getData()))

End of edit

I’m not sure yet why it didn’t work, but you can see the author has made a few other changes to the exporter. This was a quick fix for me and with this small change, you should be ready to go.

To actually add the opaque data within blender you must go to ‘object mode’ (where selected objects have a pink outline) and open the logic tooltab (the pacman icon), which should look like this:

You can see the options on the left handside of the tab to add strings, ints, floats, bools etc. to the mesh data.

To test this out, you could create a cube object and add some opaque data to the mesh. Then use your new export script to create an ASCII FBX file which you can open in a texteditor. You should then be able to see the following information in the new file like this :

Importing into XNA :

Importing into XNA also requires a little work in the content pipeline, as the default FBX processor will not read the opaque data we just added to the FBX file. Luckily this change is pretty easy. Just create a new content pipeline importer and derive from the ProcessModel function and make the following changes:

ContentProcessor.cs

public override ModelContent Process(NodeContent input, ContentProcessorContext context)
{
    // Uncomment out if you want to debug (JIT)
    // System.Diagnostics.Debugger.Launch();

    SpaceShipAttributes _ShipAttributes = new SpaceShipAttributes();
    ModelContent model = base.Process(input, context);

    for (int i = 0; i < input.Children.Count; i++)
    {
        NodeContent node = input.Children[i];
        ReadShipInformation(ref _ShipAttributes, i, node);
    }

    // Copy the attributes into the model.tag property object.
    model.Tag = (SpaceShipAttributes)_ShipAttributes;
    return model;
}

private void ReadShipInformation(ref SpaceShipAttributes shipAttributes, int index, NodeContent node)
{
    if (node.OpaqueData.ContainsKey("ShipName"))
    {
        shipAttributes.ShipName = (string)node.OpaqueData["ShipName"];
    }
}

You can see here that we search each of the model's mesh nodes to see if they contain any of the tags which we predefined. In this case, I am just searching for the shipname, which will be stored in the ShipAttributes class object. If the node does, then we can read this data and store it in our own class. Finally, this class is then casted in the Model.Tag.

A few things to watch for in Blender:

Keeping an Eye on the current 'Space':

For anybody who has used directX or XNA this is perhaps a no-brainer but I thought I would mention about the differences between working in world space and object space. When creating your model, there are two spaces which you work within (at least, there are two which are exported to XNA), the first is called the world space and the second is the object space.

The world space is where the position, rotation and scale of the meshes are stored in world coordinates relative to the origin (0,0,0). The world space is changed when you move the model in 'object mode' within blender. You can see the axis of the model in world space below:

Any transforms (translation, rotation and scale) made in object space will be stored in the AbsoluteBoneTransforms matrices in the model.

The object space is where the position, rotation and scale of the individual vertices are stored in object coordinates, that is, coordinates relative to the object origin (0,0,0). The object positions are changed when you are in 'edit' mode within blender and you move the individual vertices, as below:

Each vertex is actually already stored in object space, so there really isn't anything to do there, but you must remember to pass the correct world matrix to your effect when rendering each mesh. As you can see in almost all the 3d samples on the creators club, this is done so:

// Copy the world transform into an arry of matrices.
_ShipModel.CopyAbsoluteBoneTransformsTo(_Transforms);

foreach (ModelMesh mesh in _ShipModel.Meshes)
{
  worldMatrix = _Transforms[mesh.ParentBone.Index];

  foreach (ModelMeshPart part in mesh.MeshParts)
  {
     Effect currentEffect = part.Effect;

     currentEffect.Parameters["xWorld"].SetValue(worldMatrix); // world matrix
     currentEffect.Parameters["xView"].SetValue(camera.View);
     currentEffect.Parameters["xProjection"].SetValue(camera.Projection);
  }

  mesh.Draw();
}

So with this in mind you can see that we can get the correct positions for all meshes (including our place holders) relative to the model.

UV Mapping:
Another big hurdle is how to UV map you models. I guess there are many different ways and you'll only find which one best suits you by trying it out, but here is how I do it ...

Load up your model and centre on it in the 3D view. Now if you right click on the seperator between the toolview and 3d view you can split the view port, then you should have something like this:

I find this view makes it much easier to work with. Now, I like to use the projective UV map button for actually defining the UV coordaintes. Using the numpad, start off with the top (num7), then select the faces which you want to appear as an area within the UV map:

Then press 'U' and choose 'project from this view'. You can see that the same area is displayed in the UV screen, where you will be able to scale and move the selection around the texture reactangle. This process should be repeated for each of the faces in model, until every face has a unique area on the UV map (unless of course they should be sharing the same texture information). This is an example:

When you export this FBX file, the UV coordinates for each triangle will be saved in the vertex data. Then you can use the TEXCOORD symentics in HLSL to properly texture each face.

Scaling:

The last thing to note on the blender side is that models exported with the default FBX exporter need to be scaled down in XNA by 0.01f to get a 1:1 blender / xna unit scale. It is possible to do this scaling in many different places, either in the content file properties in VS, or in the exporter OR manually before rendering the object, like this:

worldMatrix = _Transforms[mesh.ParentBone.Index] * Matrix.CreateScale(0.01f);

// pass world mat to effect when rendering mesh

Well, that's it for now. If you have any questions about the blender / XNA process then just leave a comment here or in the forums and as always I'll try and answer.

I have added a new page to the screenshots section on the site where I'll upload shots of ships as I make them.

-John

So I had a look around on the weekend for project hosting sites which offered free hosting using SVN, and I found a few. Many of the project hosting sites however only offer only free hosting to open source projects, but I did manage to find one called ProjectLocker. It seems to have everything I could need for hosting my project privately and it also offers an intergrating Trac system. So I thought I’d give it a go.

For anybody who hasn’t heard of SVN, basically it offers a way to host your entire project (minus build and object files) on a server and using a tool like TortoiseSVN in windows, you can quick and easily download (checkout) or backup (commit) changes to this one central repository. It also keeps a copy of all versions of a file and logs changes made.

This makes it easy if say, you want to work on your project from several locations, or you have multiple developers working on a project.

For now, while I still haven’t setup it all up – I am hoping that the Trac system will help me focus on specific enhancements and bugs in Britonia. I’m finding that when I sit down I spend a good 1-2 hours just playing with what is already ‘working’; tweaking the heightmaps, changing scattering colours, flying around the planets etc.

If you want to try it out, here are a few links to the tools which I am using :

TortoiseSVN: http://tortoisesvn.tigris.org/
This can be used to quickly upload/download files in your project.

AnkhSVN: http://ankhsvn.open.collab.net/
A plugin for Visual studio professional (does not work on VS Express )

Project Locker: http://www.projectlocker.com/
There are many hosting sites, but this is the one I choose because its private and free.

Trac: http://trac.edgewall.org
Bug tracking system.

I set myself no time limit for finishing the development of the game, piling on the features.  I knew it would take a long time, but that didn’t bother me and indeed it still doesn’t; after all what is the point of making a game if you don’t enjoy it? 

I spend quite a lot of my free time working on Britonia (or at least XNA related projects), but there are still a great many things required to get a full game working which I haven’t even started, and I think it would be better ( or faster) in the long run if I change the theme of the game before I get into the actual in-game content creation.

Therefore I am considering to change the theme / genre to a Space trading simulation, just like the old classic Elite by David Braben and Ian Bell. 

Luckily though, changing to a space sim wouldn’t require me to re-write reems of code, so everything I have done thus far will remain largely unchanged.  Of course the ‘new’ space game will have you landing in ground ports and/or flying around the surface of the planet looking for minerals and artefacts.

So why the change?

Simply put, after comparing the content required (models / textures / environments) for both a space sim and fantasy RPG, I think I have a much better chance of creating believable content for a space sim as opposed to the likes of human NPCs and monsters.  Some of the other considerations are :

I just wrote these off the top of my head, and I must admit it is hard to remain impartial after convincing myself a change is needed, but even looking at the above table I think the space sim would generally be faster and easier to implement.  Although I made a few less-than-serious remarks above, some of the areas such as travel / distances are obviously made easier with the concept of space flight.

Well, please let me know what you think because I still haven’t fully made up my mind yet.  You have until the website theme changes to a space scene to leave me your comments

-John

What are Depth Buffers?

Depth buffers (commonly referred to as Z- or W- buffers) are a means to check which pixels being rendered will occlude one another. This is achieved by creating a separate surface the same size as the back(colour-) buffer where the depth of each rendered pixel is stored. Then before any other colours competing for the same pixel are rendered, they must first pass the depth function test using the same position within the depth buffer. Typically this check is passed if the new depth is less than or equal to the current depth in the depth buffer, although it is possible to change the pass conditions.

Enabling and setting the depth function with the following:

// enable depth buffer checks
GraphicsDevice.RenderState.DepthBufferEnable = true;

// specify the pass criteria for pixels
GraphicsDevice.RenderState.DepthBufferFunction = CompareFunction.LessEqual;

// allow writing to the depth buffer
GraphicsDevice.RenderState.DepthBufferWriteEnable = true;

Z-buffering is when the z component of a transformed pixel is stored as the depth. This differs from W-buffering, which takes the homogeneous W-component as the depth value. Because most of today’s hardware has support for Z-buffering it is the more commonly of the two.

Depth buffer Formats and Resolution:

The precision that you will get from the depth buffer depends greatly on the format of the surface you choose to use as well as the near and far clip plane distances. Depth buffers are non linear, and the depth stored in the depth buffer is relative to the z coordinate. The maths can be a little confusing but put basically, you get more precision closer to the near plane as you do the further away you get. There is a Z-buffer calculator on this site here so you can test it out for yourself.

In that article he talks about the resolution of z, so instead of covering the same equation, I thought I’d do a little picture representation of the resolution of Z:

The depths are calculated using :
depth value = (1 << depth_format) * ( zFar / (zFar - zNear) + zFar * zNear / (zNear - zFar) / distance_of_object )

The graph above shows a 16-bit depth buffer. The closest depth (1.0f) has a value of 0, while the furthest depth (1000.0f) has a depth value of 65536 in the buffer. As you can see on the left of the x-axis although the increments in distance are only relatively small (1.1, 1.2 etc.), we actually have a huge difference in the depth values assigned to these positions, whilst towards the furthest distances, the differences in depth value is very small.

Hopefully you can see form this graph the importance of selecting as high a value as possible for the zNear distance. This is a pretty common mistake when starting out with directx/xna whereby the programmer defines a point extremely close to the camera for the zNear like 0.1f, but you can see from above that this wastes a lot of depth needlessly – especially considering that not many objects will actually be that close to the camera.

Similarly, you should also pick sensible values for the zFar distance.

Planet Rendering

Of course when rendering planets, the distances involved mean you would very quickly have problems considering the depths distances involved if you were to use constant values as the near and far plane distances. As you can imagine, this isn’t that difficult to overcome, but I wanted to mention it so you have a reference.

For each individual planet in Britonia, I dynamically adjust the near and far clip plane distances based on the closest point on the planet sphere and the furthest point. Even using 16-bit depth buffers and realistic planet sizes there are no visible artifacts (anymore).

Creating, Caching and Restoring the DepthBuffers

Creating a depth buffer is very straight forward. In XNA the depth buffer is created and on the graphics device like so:

Graphics.GraphicsDevice.DepthStencilBuffer = new DepthStencilBuffer(Graphics.GraphicsDevice, width, height, DepthFormat.Depth16);

It is worth noting that if you wish to use a stencil buffer when rendering your scene, then this shares the same surface as the depthbuffer, and you will have to sacrifice some bits per pixel for this stencil buffer. As example would be:

Graphics.GraphicsDevice.DepthStencilBuffer = new DepthStencilBuffer(Graphics.GraphicsDevice, width, height, DepthFormat.Depth15Stencil1);

The last thing I’d like to mention is the ability to store the depth buffer for your scenes, which can be restored and used again later. Again this is quite easy to do:

// Cache the current depth buffer
DepthStencilBuffer old = GraphicsDevice.DepthStencilBuffer;

// Set our custom depth buffer
GraphicsDevice.DepthStencilBuffer = shadowDepthBuffer;

As an example of how this may be benefical: In britonia I store the depth buffer for each planet during the planet rendering phase. This is then later restored when rendering the ground objects on the closest planet. This is required because of the swapping of depth buffers with multiple planets as mentioned above.

I hope this article was at least partitially helpful.

If you feel like reading up some more, you can find the MSDN article here.

In the last tutorial we looked at how improved 3d perlin noise works on the CPU, and how we can use this to generate various fractal like textures either at compile-time or run-time. If you are not sure how perlin noise works, I would definitely recommend reading that article first here. Noise on the CPU has many uses but it is slow when making multiple function calls with many octaves. Often, you’ll find that performance will be seriously impaired when you regularly call the inoise function, but without all those extra octaves the resulting textures won’t appear all that great. Further to this, there are some pretty cool effects which we can easily add (as long as we are sensible) when rendering models by using per-pixel noise.

As before, the code for generating noise can be split up into 4 sections:

1. Getting the position within the cell and apply a fade curve to the fraction
2. Using the permutation table
3. Calculating the gradient values
4. Lerping and generating the noise

Getting the position within the lattice:

So the first task to calculate the position of the input value within a lattice (a 3d space). As before, we need to find the integer position which will represent the lattice cell index. We also need the fraction part of the input to use for the linear interpolation, and we need to remember to pass the fraction through the fade curve which will weight the fraction value towards 0 and 1 . This is required to reduce artefacts when sampling across lattice cells which have sudden changes in gradient values. (the fade curve function will be defined later):

HLSL:

float3 P = fmod(floor(p), 256.0);
p -= floor(p);
float3 f = fade(p);

// Make sure that no component of the integer coordinate is larger than the
// dimensions of the permutation texture which we pass to the effect.
P = P / 256.0;

The permutation table:

The first big change that is needed is the way we store the permutation table. In the CPU version, we iterated through a for loop in the class constructor and ‘randomly’ added the integer values between 0 – 255 to an array, which we called the permutation array. For the GPU however, we will pass this ‘array’ to the GPU as a texture, and use the tex2D to sample the information. Here is permTexture2D file that I be be using.

HLSL:

// Hash Coordinates
float4 AA = perm2d(P.xy) + P.z;

float4 perm2d(float2 p)
{
    return tex2D(permSampler2d, p);
}

You can get a permutation texture here.

The Gradients:

Again, looking back to the CPU tutorial, we calculated the gradients at each position in the lattice using the grad() function. This used some fancy bit manipulation to return a scaler value which we used as the gradient. This time on the GPU, we will take a similar approach as with the permutation table and pass in a 1D texture which can be sampled with the tex1D function.

When sampling the 1d texture we want to have as much of a random index as possible. So we use the colour value from the permutation texture (which we sampled in part I) as the texture coordinates. Like this:

HLSL:

/// Calculate the gradient at this 'position' using the value sampled
/// from the permutation table.
float gradperm(float x, float3 p)
{
    return dot(tex1D(permGradSampler, x), p);
}

You can get a permGradTexture here.

Lerping and Generating the Noise

This part is actually almost identical to the CPU version, with the exception of the change of function names. Again you can see that 3d Perlin noise requires 7 linear interpolation calculations from the surrounding positions in the lattice:

HLSL:

// AND ADD BLENDED RESULTS FROM 8 CORNERS OF CUBE
return lerp( lerp( lerp( gradperm(AA.x, p ),
                              gradperm(AA.z, p + float3(-1, 0, 0) ), f.x),
                       lerp( gradperm(AA.y, p + float3(0, -1, 0) ),
                              gradperm(AA.w, p + float3(-1, -1, 0) ), f.x), f.y),

                 lerp( lerp(gradperm(AA.x+(1.0 / 256.0), p + float3(0, 0, -1) ),
                              gradperm(AA.z+(1.0 / 256.0), p + float3(-1, 0, -1) ), f.x),
                       lerp( gradperm(AA.y+(1.0 / 256.0), p + float3(0, -1, -1) ),
                              gradperm(AA.w+(1.0 / 256.0), p + float3(-1, -1, -1) ), f.x), f.y), f.z);

And believe it or not, that is it. There is not a lot of code required at all to get this up and running in an effect. This version of the improved noise takes into consideration the optimisations mentioned here, and takes up just over 53 instructions, so this is still quite expensive.

The rest of the code for the effect file is taken up by the fractal functions like we covered in the last post. They are fractal brownian motion (fBm), turbulence and ridged multi-fractal.

Here is the complete effect file:

HLSL:
*note that < and > are represented below as ‘lb’ and rb’ respectively.

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// TEXTURES - IMPORTANT! you must pass these textures to
// the effect before generating any values using the improved
// noise basis function (inoise()).
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
texture permTexture2d;
texture permGradTexture;

sampler permSampler2d = sampler_state
{
    texture =  lb permTexture2d rb; // lb and rb are left and right angled brackets
    AddressU  = Wrap;
    AddressV  = Wrap;
    MAGFILTER = POINT;
    MINFILTER = POINT;
    MIPFILTER = NONE;
};

sampler permGradSampler = sampler_state
{
    texture = lb permGradTexture rb; // lb and rb are left and right angled brackets
    AddressU  = Wrap;
    AddressV  = Wrap;
    MAGFILTER = POINT;
    MINFILTER = POINT;
    MIPFILTER = NONE;
};

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// FUNCTIONS
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
float3 fade(float3 t)
{
	return t * t * t * (t * (t * 6 - 15) + 10); // new curve
}

float4 perm2d(float2 p)
{
	return tex2D(permSampler2d, p);
}

float gradperm(float x, float3 p)
{
	return dot(tex1D(permGradSampler, x), p);
}

// Improved 3d noise basis function
float inoise(float3 p)
{
	float3 P = fmod(floor(p), 256.0);	// FIND UNIT CUBE THAT CONTAINS POINT
  	p -= floor(p);                      // FIND RELATIVE X,Y,Z OF POINT IN CUBE.
	float3 f = fade(p);                 // COMPUTE FADE CURVES FOR EACH OF X,Y,Z.

	P = P / 256.0;

    // HASH COORDINATES OF THE 8 CUBE CORNERS
	float4 AA = perm2d(P.xy) + P.z;

	// AND ADD BLENDED RESULTS FROM 8 CORNERS OF CUBE
  	return lerp( lerp( lerp( gradperm(AA.x, p ),
                             gradperm(AA.z, p + float3(-1, 0, 0) ), f.x),
                       lerp( gradperm(AA.y, p + float3(0, -1, 0) ),
                             gradperm(AA.w, p + float3(-1, -1, 0) ), f.x), f.y),

                 lerp( lerp( gradperm(AA.x+(1.0 / 256.0), p + float3(0, 0, -1) ),
                             gradperm(AA.z+(1.0 / 256.0), p + float3(-1, 0, -1) ), f.x),
                       lerp( gradperm(AA.y+(1.0 / 256.0), p + float3(0, -1, -1) ),
                             gradperm(AA.w+(1.0 / 256.0), p + float3(-1, -1, -1) ), f.x), f.y), f.z);
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// FRACTAL FUNCTIONS
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// fractal sum
float fBm(float3 p, int octaves, float lacunarity = 2.0, float gain = 0.5)
{
	float freq = 1.0f,
	      amp  = 0.5f;
	float sum  = 0.0f;
	for(int i=0; i lb octaves; i++) {
		sum += inoise(p*freq)*amp;
		freq *= lacunarity;
		amp *= gain;
	}
	return sum;
}

float turbulence(float3 p, int octaves, float lacunarity = 2.0, float gain = 0.5)
{
	float sum = 0;
	float freq = 1.0, amp = 1.0;
	for(int i=0; i lb octaves; i++) {
		sum += abs(inoise(p*freq))*amp;
		freq *= lacunarity;
		amp *= gain;
	}
	return sum;
}

// Ridged multifractal
// See "Texturing & Modeling, A Procedural Approach", Chapter 12
float ridge(float h, float offset)
{
    h = abs(h);
    h = offset - h;
    h = h * h;
    return h;
}

float ridgedmf(float3 p, int octaves, float lacunarity, float gain = 0.05, float offset = 1.0)
{
	float sum = 0;
	float freq = 1.0;
	float amp = 0.5;
	float prev = 1.0;
	for(int i=0; i lb octaves; i++)
	{
		float n = ridge(inoise(p*freq), offset);
		sum += n*amp*prev;
		prev = n;
		freq *= lacunarity;
		amp *= gain;
	}
	return sum;
}

This improved noise can be used as you saw in the last tutorial or in any number of other ways. Just remember though that doing noice calculations at run-time can be very expensive so its best to do as much ‘work’ as possible off-line.

References for this tutorial are:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter26.html

The noise function that I’ll cover is implemented as per Ken perlin’s improved noise article here. The full source code is provided at the end of the article, but I have tried to write it as such that you can follow through each step and steadily build up your own XNA 3.1 app.

Generating complicated textures on the CPU is an expensive operation and can stall the application; especially if you attempt to generate large textures at run time – but learning about perlin noise is probably more straight forward on the CPU (as opposed to the GPU). I’ll be covering noise generation on the GPU in a future article.

Step 1 – Setting up the Project:

So let’s set up a new XNA 3.1 project where we can work from:

File->New->Project

Give it a name and make sure you have selected the project type ‘XNA Game Studio 3.1′ and press OK. After the default workspace has been loaded you’ll will be presented with the default project layout.

Before I get into the beef of the article, I’d just like to create the empty classes within the project so you have a view of the overall setup. We will fill these classes in as we run through the tutorial. Right mouse button on the project in the solution explorer (Ctrl+W then S) and create the following files:

We will put all of the perlin noise and fractal functions in the Noise.cs class file. The CreateTexture.cs is where we will define the code for mixing different fractals and producing the actual textures. To make things easier for this tutorial I’ll be creating these two classes as static classes, which means we don’t need to create an instance of the classes to use them, we simply need to call the namespace.class.function() from anywhere in the project and it’ll work.

Step 2 – Exploring Perlin Noise:

First we’ll look at the perlin noise class and go through the implementation that will enable us to produce the textures. Perlin noise can be used to calculate pseudo-random values in any dimension, but the higher the dimension the more it will cost you in terms of performance. Here we’ll be implementing a 3d improved noise basis function which takes 3 variables as input and uses 7 linear interpolations (lerps) per octave to obtain the end result. Although we’ll be implementing 3d perlin noise, we can still use it to create 2d textures by passing in an x and y value and leaving the third component zero.

Perlin noise works by taking input values and returning one pseudo-random value in the range [-1,1]. It does this by using the input values as coordinates in a grid (usually called lattice) of gradient values. Each gradient isn’t cimputed until we have the exact coordinate, but once we find the gradient at a particular coordinate referenced by the input, we can use linear interpolation with this and all its neighbouring gradients in the grid to obtain the apparently random end result. Because we define this lattice of values the same for each instance of the class, we will always get the same output for a specific input.

In order to make sure that we get even further variety, instead of calculating the gradient vector based on the input coordinates directly, we use the input values as a reference into a hash table. The hash table is called the permutation table, and we create it in the class constructor.

As an explanation; while cell indices 0 and 1 may be next to each other in an array of gradients, they will not necessarily be neighbours in the final grid, because 0 and 1 passed through the hash algorthm will return totally different results. To achieve this we define a permutation array which contains the integer values 0 – 255 in a pseudo random order.

It is also important to note that if the permutation table is not the same between different instance of your application (i.e. not constant), you will get different results from the perlin noise function even if you use the same input coordinates for a particular texture. For this reason we will use an instance of the .net Random class with a seeded constructor.

So let’s jump into the code for the Perlin noise. Open up the Noise.cs class file and change the basic class template code to resemble this:

using System;

namespace TextureGeneration
{
    public static class c3DPerlinNoise
    {
        private static Random rand;

        private static int[] ms_p = new int[512];

        // The static class constructor
        static c3DPerlinNoise()
        {

        }
    }
}

Here we just defined a new static class and two static class members. You can see that the permutation table we dicussed above is defined as being 512 in length. Just something to note, static constructors in static classes are run the first time you try and use a function within the class itself.

Now we’ll look at filling up the constructor and creating our tables. Let’s add the following code in the class constructor:

// Create an instance of the random number generator, making sure to pass in a seed.
rand = new Random(42);

// Use the bitwise left shift operator to make sure the array of permutation values is a multiple of 2
int nbVals = (1 << 8); // result is 256
int[] ms_perm = new int[nbVals];

// set values in temp perm array as "unused", denoted by -1
for (int i = 0; i < nbVals; i++)
{
ms_perm[i] = -1;
}

First up we create an instance of the random class, remembering to pass into it the seed. The seed can be any integer or float value, here I just used 42. For those of you unsure of the << operator, it shifts the bits of the right hand value, effectly incrementing it in multiples of 2. This is used here just to make sure we defined the size as being a multiple of 2 (256). Next we defined a temporary array half the size of the final permutation array. We will use this to define the integer values between 0 and 255 in a random order, before copying them to the final permutation array.

Next we must fill the permutation array:

for (int i = 0; i < nbVals; i++)
{
// for each value, find an empty spot, and place it in it
while (true)
{
// generate rand # with max a nbvals
int p = rand.Next() % nbVals;
if (ms_perm[p] == -1)
{
ms_perm[p] = i;
break;
}
}
}

for (int i = 0; i < nbVals; i++)
{
ms_p[nbVals + i] = ms_p[i] = ms_perm[i];
}

Here we iterative though a loop 256 times, and each time we try and find a free position within the temporary permutation table at a random location. This loop ends when all the integer values between 0 and 255 have been randomly placed in the array. The last part of the above code places the temporary permutation values in the final array, and fills it out so we have a full 512 values.

And that’s all for the constructor – pretty painless. We basically end up with a permutation array with 512 cells of mixed up integer values and a static random number generator.

The next step is actually implementing the perlin noise based on what ever input the user provides. The input I am refering to in 3D noise are three seperate values which are typically some sort of coordinate such as the position of a texel or vertex on a terrain etc.

There are three important things to note about the input to the noise function:

1. Integer values will always return zero. You’ll see why this is true later, but basically we use the fraction part of the input as the amount to linear interpolate for the given gradient. Therefore if the input value is an integer then there is no fraction part, and thus the lerp will return 0.
2. Small variations between input values to the noise function will yield small changes in the output values.
3. Large variations between input values to the noise function will yield apparently random output values.

We are counting on all of the above being true in order to produce nice generated textures.

Next up we’ll create the noise function which calculates the gradients and performs the linear interpolation. Create a new static function within the c3DPerlinNoise class with:

private static double Noise (double x, double y, double z)
{

}

The first step in the noise function is to take the input values and work out a coordinate within the lattice of gradient values. We do this by using the integer part of each of the input coordinates (that is, we take the fraction part away from the input components). Because the input values could very well be larger than the permutation array of hash values in any one dimension, we also need to also wrap the input integers and keep the range within [0,255]. Do this with the following code:

int X = (int)x & 255;
int Y = (int)y & 255;
int Z = (int)z & 255;

Now get the fraction part of each of the input values. We will use later as the distance to linear interpolate into each gradient. If you are unsure about the linear interpolation you can check it out here. If you remember the three points we covered about a page back, this is point 2. Add this code:

    x -= Math.Floor(x);
    y -= Math.Floor(y);
    z -= Math.Floor(z);

Uisng what we have seen so far, try to imagine now calling the noise function 30 times using small increments in the input values, say from within two nested for loops. Using the above code, you can see that we work out the lattice gradient using the integer part of the input, and the fraction is used in the lerp calculation. Imagine that the first vector we linear interpolatie on is a vector which is ‘pointing’ straight up. So we carry on incrementing the input values and calling the noise function. Once the incremented input values cross out of this lattice cell and into another cell (when the integer increments), the linear interpolation will be called on a gradient vector which is probably ‘pointing’ in a completly different direction. If the increments of the input values are exactly the same then you will see a noticable seam where the gradient changes.

To try and avoid this we run the fraction parts of the input through a fade curve (s-curve) which will weight the input towards 0 and 1. This is needed to avoid seams in the output texture due to the transitions between lattice cells where the different gradients produce noticable jumps in the output values. We will define the fade function a little later, but for now add this to the noise function:

double u = fade(x);
double v = fade(y);
double w = fade(z);

Before we go on to calculate the gradient value, we need to pass our new integer values into the permutation table to get the hash values (remember, this should mix up the values even further, and help to add variation). We do this with the following code:

int A = ms_p[X    ] + Y, AA = ms_p[A] + Z, AB = ms_p[A + 1] + Z;
int B = ms_p[X + 1] + Y, BA = ms_p[B] + Z, BB = ms_p[B + 1] + Z;

Okay, so this is getting long winded but rest asured we are nearly there. This is the final step and it is where we employ linear interpolation between the gradients. As I said earlier, each extra dimension of noise introduces a performance overhead; this is because of the need to lerp between more surrounding points in the lattice, for 3d noise we must lerp between 7 gradients. The last thing of note here is that we calculate the gradient values using the hash value and the input coordinates:

return lerp(w, lerp(v, lerp(u, grad(ms_p[AA  ], x  , y  , z   ),
                                      grad(ms_p[BA  ], x-1, y  , z   )),
                             lerp(u, grad(ms_p[AB  ], x  , y-1, z   ),
                                      grad(ms_p[BB  ], x-1, y-1, z   ))),
                   lerp(v, lerp(u, grad(ms_p[AA+1], x  , y  , z-1 ),
                                      grad(ms_p[BA+1], x-1, y  , z-1 )),
                             lerp(u, grad(ms_p[AB+1], x  , y-1, z-1 ),
                                      grad(ms_p[BB+1], x-1, y-1, z-1 ))));

This will return a double value by linear interpolating between all the gradient values at this point in the lattice.

Before this will work, we just have three utility functions to define. The first one is the fade curve, which weights the input fractions towards zero and one, to ease the transitions of interpolations across lattice cells:

private static double fade(double t)
{
return (t * t * t * (t * (t * 6 - 15) + 10));
}

The _lerp function (linear interpolation) is pretty straight forward,and returns a double:

private static double lerp(double t, double a, double b)
{
return (a + t * (b - a));
}

The last, and most important of the utility functions is the grad() function, which computes the gradient based on the hash value:

private static double grad(int hash, double x, double y, double z)
{
int h = hash & 15;
double u = h<8 ? x : y;
double v = h<4 ? y : h==12||h==14 ? x : z;

return ((h&1) == 0 ? u : -u) + ((h&2) == 0 ? v : -v);
}

And that is it, at least for the perlin noise part. The above functions can now be used to return a pseudo-random value in the [-1, 1] range for any 3d input, such as terrain vertex positions etc.

Step 3 – Fractals for Interesting Noise:

Okay, with the noise class defined above you may well be thinking that the battle’s almost over – well, not quite. We could (if we hadn’t defined the noise function as private) just call the noise function above and pass in the input coordinates to define a texture of noise. This would result in a texture based on just one octave of noise. But in order to achieve nice results, or rather varied results for a wide variety of textures, we need to use multiple octaves of noise.

Each successive noise function you use for one point of input is known as an octave, and you can use as many or as little octaves as you like in the texture. When we call multiple octaves of noise, we can specify an amplitude and frequency. The amplitude is used to modify the output of the noise function while the frequency modifies the input values for each call to the noise function. The frequency of an octave is usually double that of the previous octave. For this reason, there becomes a point where the frequency of the octaves is too high to be displayed on the screen, so it makes sense to limit the use of octaves.

There is another property which can be used called persistence or lacunarity, which specifies the rate of change of the frequency (of the input) over octaves.

Now we’ll just run through some fractal functions which can be used to create more interesting noise, and which should explain these new terms a little better:

The first fractal function is fractal browian motion (fBm). This is just the weighted sum of multiple scales of an arbiturary basis function (the basis function in our case is improved perlin noise – but the basis could be anything else such as simplex noise)

public static double fBm(double x, double y, double z, int octaves, float lacunarity, float gain)
{
    double frequency = 1.0f;
    double amplitude = 0.5f;
    double sum = 0.0f;

    for (int i = 0; i < octaves; i++)
    {
        sum += noise(x * frequency, y * frequency, z * frequency) * amplitude;
        frequency *= lacunarity;
        amplitude *= gain;
    }
    return sum;
}

You can see that the frequency used to modify the input values is doubled on each iteration of the octaves (I'm assuming here that the lacunarity is 2.0f), while the amplitude is modified based on the gain. The frequency is multiplied with each input variable to the noise function. This function produces textures similiar to:

The next fractal function is Ridged multifractal. It is generated in much the same way as fBm noise, except the output of each octave is modified by an absolute value function. This function is very popular for creating terrain heightmaps, as it produces ridge like features at all scales. The implementation is as follows:

public static double RidgedMF(double x, double y, double z, int octaves, float lacunarity, float gain, float offset)
{
double sum = 0;
float amplitude = 0.5f;
float frequency = 1.0f;
double prev = 1.0f;

for (int i = 0; i < octaves; i++)
{
double n = ridge(noise(x * frequency, y * frequency, z * frequency), offset);
sum += n * amplitude * prev;
prev = n;
frequency *= lacunarity;
amplitude *= gain;
}

return sum;
}

public static double ridge(double h, float offset)
{
h = Math.Abs(h);
h = offset - h;
h = h * h;
return h;
}

The RdgedMF in the source code I have provided produces the following texture:

4. Getting the Project setup to create and display the textures:

We have covered a lot of ground so far, but there is still one thing left to do, and that is to actually create the textures! If you want to go ahead then and open up the CreateTexture.cs file class in the solution explorer and we'll define the following function in there. First of all setup the class as another static class like this:

using System;
using Microsoft.Xna.Framework.Graphics;
using TextureGeneration.Noise;

namespace TextureGeneration
{
public static class CreateTexture
{

}
}

All the following functions should be created inside this class. Now we'll justlook at creating a texture which could be used to generate a heightmap from, like in Riemers tutorials (here). Define the following function:

public static Color[] CreatefBmHeightMap(int width, int height)
{
Color[] data = new Color[width * height];
float tempColor;

float x = 0, y = 0, z = 0;

As you may be able to guess, we'll be filling the Color[] array within the function and we'll pass it back out at the end. This will later be used to fill a texture2D class instance. The next step is too create a two for loops, one nested within the other. This will enable us to produce a noise value for each texel of a texture (given the width and height):

for (int v = 0; v < width; v++)
{
x += 0.5f;
y = 0;
for (int u = 0; u < height; u++)
{
tempColor = (float)c3DPerlinNoise.fBm(x, y, z, 8, 0.45f, 1.0f);
data[v * width + u] = new Color(tempColor, tempColor, tempColor, 1);

y += 0.5f;
}
}

return data;
}

There are a few things going on here which we need to take note of. The first is that we do not use the integers created by the nested for loops input directly because if you remember, integer values produce 0 as output, so instead we use the x,y and z floats defined locally in the function, and manually increment them. We then go on to use the result of the fBm function to fill all components of a Color struct, producing a black and white image. This should be perfect for a heightmap. The output of this function can be seen above (the fBm sample).

For the Sake of Completness:

We'll quickly define some code to get the texture up on the screen in your application. This is all pretty basic stuff, so I'm not going to linger on anything. Go back into the Game1.cs class and define a Texture2d member:

private Texture2D _HeightmapTexture;

This will contain the texture that we are to create. In this tutorial we'll just set the texel data directly with the SetData function.

Now go into the LoadContent() method and add the following code:

_HeightmapTexture = new Texture2D(GraphicsDevice, 512, 512, 1, TextureUsage.None, SurfaceFormat.Color);
_HeightmapTexture.SetData
(CreateTexture.CreatefBmHeightMap(_HeightmapTexture.Width, _HeightmapTexture.Height));

This will create an instance of the Texture2D with the specified size and with a surface format of Color which has 8-bits for RGB and A. The second line fills the texture data with the Color[] array which is created and returned from the CreateTexture.CreatefBmHeightMap() function.

Lastly, go to the draw method and add this line between the SpriteBatch.Begin() and SpriteBatch.End():

_SpriteBatch.Draw(_HeightMap, new Rectangle(10,10,512,512), Color.White);

And that's that! Press F5 and you should see a fBm noise texture displayed on the screen.

That pretty much concludes the tutorial, I hope you found it interesting!

Now as this was my first tutorial, I would greatly appreciate any comments or criticism about issues, things I may have forgot or any improvements. I look forward to your feedback and I'll try and use it for my next tutorial (in a few weeks)

You can donwload the sample project here

Making Noise

Thanks,

-John

References:

Perlin's Improved noise reference