Code Repository Setup

I have always tempted fate when it has come to backing up my coding projects. Trusting that my computer hard drive would not fail me and that all my precious hours, blood, sweat and tears that I put into the code would not disappear into thin air. However as I grow older (and more synical) I'm begging to realise that eventually this will come back to bite me.

So after months of saying I'll do it and never getting around to it I have now finally uploaded all my development stuff into an online code repository and version control system, namely Google code. Now this is not my first attempt I actually created the account and repository over 2 years ago but I never actually uploaded any code to it (Which makes it pretty useless).

This time however some code has finally made it into Google Code, you can find my repository here http://code.google.com/p/bsx11mt/ if you're interested in having a look as per Google Code's requirements the code is completely free and open source.

So far I'm liking the version control for my game development stuff, the ability to trace out the development of indiviudal features and files is really interesting. You can see how stuff evolves over time or at what point it all started to go wrong.

I highly recommend Google Code and Tortoise SVN for any individual or small team of developers out there who are looking for something a little better than swapping and reserving files.

Assimp Loading Library

The Open Asset Import Library, or Assimp for short, is a portable Open Source library to import various well-known 3D model formats in a uniform manner. Written in C++, it is available under a liberal BSD license and there is also a C API as well as bindings to various other languages.

Assimp loads all input model formats into one straightforward data structure for further processing. This feature set is augmented by various post processing tools, including frequently-needed operations such as computing normal and tangent vectors.

I think the strength in the use of the Assimp library is that you don't limit your game meshes to be created in just a single format or program. You might have an artist who likes 3DS Max for making structures and buildings, while another prefers Blender for producing humanoid characters with animations. With Assimp you can accept all file formats but still have a consistent from inside your game engine.

I plan to have future posts on how my effort to integrate this into my Brainstorm engine goes. In the mean time you can download the Assimp library from here: http://assimp.sourceforge.net/main_downloads.html

PART II: Terrain Rendering with a Scene Graph

In the previous post we discussed some of the issues of Terrain rendering and started to improve and evolve our Terrain rendering system. Part II kicks off right from where Part I left off and it might actually cover some scene graph stuff this time.

So we discovered that a constant number of visibility checks can still be a limiting factor. It's Quad tree to the rescue. Instead of just cutting the grid up into 256 even bits by going across and down 33 verticies we could actually be clever in the way we build the patches.

Starting from the highest level we could divide it into 4 equal child parts which would result in 4 patches that are 257 X 257 vertices. Four patches is not enough so lets divide each of these patches into four more child patches. Now we have 16 patches, still not enough but if we continue to divide down a few more levels eventually we reach 256 patches that we add as leaves to the quad tree. If we keep this dividing information in a tree (Quad Tree to be exact) we can make assumptions that can help us with our visibility issues. Note none of the higher level nodes contain any Terrain information, only the leaves of the Quad tree.

For example because each level of children exists completely inside the bounding volume of the parent by definition we then know that if the parent node fails the visibility test then so will all the children. So no need to bother testing their visibility. Worst case all 256 patches would be visible and we'd still do 341 visibility tests but on average we should achieve about 64 tests instead of original 256. A great improvement on the efficiency of our algorithm for no change in the visual experience of the user.

In the previous version of my Brainstorm game engine this was the complete extent of my Terrain rendering code and it has done the job quite well, however there are still a number of issues with this implementation that I think I can improve on. Specifically there is no handling of level of detail, there is still wasted effort when parent nodes are completely visible inside the viewing frustrum and Tree and Grass rendering don't take any advantage of the terrains Quad Tree, each of the systems uses their own quad tree visibility checking.

Keep an eye out for Part III of this series that will try and cover these issues in more detail.

DirectX 11 Up and Running!

Success! I have managed to set up and compile my very first DirectX 11 App. This is an evolution from my previous game engine and I've tried so hard to get the structure correct from the start.

But funnily enough the more I programmed the more the elusive "correct structure" changed. Never the less I will push on with the hopes to come back and refactor and clean up things later.

I'd normally post a screen shot to celebrate but as it's nothing more than a black window it seems a little pointless at this stage. But don't worry as more interesting stuff starts to happen I will post screenshots.

Next on my list of things to convert over from my old engine is the sky rendering.

My CPU is melting! (well it nearly did)

I was having some issues with my computer last week where it would just restart for no apparent reason. I suspected that there were some temperature issues but I needed to be sure before I started ripping the case apart.

 

A quick run of 3DMark 11 and watching the temperatures inside SpeedFan I quickly worked out why my computer was shutting down. The CPU temperatures were through the roof, SpeedFan listed one of the cores as reaching a maximum of 94degC during the test!

 

Needless to say I shut it down as quickly as possible and gave it a quick cool down before rushing out to buy myself a new CPU cooler before my i7 melted. Lucky for the motherboard protecting the chip I guess. It's forgiven for shutting down and losing me a bunch of code.

 

I settled on the Artic Freezer 13, pictured below. It's nothing super special but heaps better than the Intel stock cooler that I was running.



I originally built this computer at the start of 2010 and it has been super reliable, when I opened the case I found the CPU cooler buried under dust and when I pulled the stock Intel cooler off, I found that the thermal paste had been reduced to thermal dust. Needless to say I don't think it was working too well anymore after 3 years.

The Artic Freezer 13 absolutely dwarfs the stock Intel cooler, it was a bit squeezy installing it amongst all my other components but I managed unscathed.

With the new cooler in place I've since re-run the 3DMark 11 test and I'm delighted to say that temperatures peaked at only a little over 50degC, so I'm chalking that one up to a win and who knows maybe I might dabble in some overclocking now.

PART I: Terrain Rendering using a Scene Graph

Now that I finally have my head around the concept of a Scene Graph the ideas of how best I can use it in my Brainstorm game engine has been keeping me awake at night. Here's hoping that getting my idea out on paper (well blog form actually) lets me sleep. I'm going to start from scratch and explain the evolution of my design.

So how does one represent a terrain in computer graphics? Well there are actually a number of ways, each with their own pros and cons. I'm not about to start a war of philosophies on this subject but to simply tell you that for my implementation I have chosen to use a regular grid heightmap because it suits my design best.

A regular grid heightmap has points that are evenly spaced in 2D with the height of them varying to represent the peaks and troughs of a terrain. In my case I'm using a 513 X 513 grid of heights. Each grid is 1 meter apart, giving a total area of 512m X 512m. Why 513 you might ask? Well it actaully makes it easier to divide up later as smaller grids always need to share a side of vertices to make them match up nicely. You can get to these numbers by taking 2^n + 1 eg. 2^9 + 1 = 513. I'll explain it a bit more later.

Now if we took a brute force approach to rendering this grid we would have 263,169 vertices and 524,288 triangles to attempt to render! Crickey that's a lot especially when if we're a character standing on the terrain we probably aren't actually able to see very much of the terrain at all (could be less than 10%). So that's a lot of wasted effort to render vertices and triangles we can't even see and our frame rate will suffer badly.

So the first step is to divide our large grid up into a series of smaller parts or patches. In my case I've divided it up into 256 individual terrain patches to represent the full 513 X 513 grid. That gives us patches that are 33 X 33 verticies across. This time to render the terrain we can check which patches are visible and only render those ones. It's a much better solution we now have 256 visibility checks and we only draw the terrain that is visible. But we will always have 256 visbility checks even if 3/4 of terrain is clearly behind us and not visible, can we do better?

Old Demo Video

Just reminising about my old game engine and what I managed to achieve. You can go check it out on Youtube, it's a Stargate based demo and the video shows a bit of a walk through the SGC before heading off world to play with the PhysX of wooden boxes.

I'm hoping my new generation game engine will eventually be able to pcik up where this left off and maybe one day turn it into an actual playable demo for people to enjoy.