First you will need to install Blender itself. There are new versions released quite often but at the time of writing, the current stable version is 2.45 and I suggest downloading it directly from the Blender Foundation.

Installation should be simple, just use the defaults but make sure you have the following selected when the installer asks you:

I chose the installation folder of “C:\Program Files\Blender Foundation\Blender” but if you install somewhere else, that is fine – just remember where as you are going to need to install the Collada exporter plugin there shortly.

Next, you need to install Python. Blender requires you to have Python installed as it’s what most of the custom Blender import/export plugins are written in. Blender 2.45 was compiled against Python 2.5 and you need to download and install that too. The Python project releases bug fixes from time to time while maintaining compatibility and currently the latest version of Python 2.5 is actually numbered 2.5.2. If a new version is released, anything matching 2.5.x will do. Just install Python with all the default options.

When you open Blender after this, you will notice that it opens a separate window apart from the main Blender one. In this window you will see the debug output from any Python plugins. If you installed Blender and Python correctly, you should see it confirm that Python has been detected.

Finally, we need to get the Collada Export plugin for Blender. You might notice if you look at the Blender export plugins in the File->Export menu, that there is already an entry for the Collada 1.4 exporter. Don’t use it. It’s the version that comes with the Blender installer and it’s broken. It bombs out when you try to export meshes so you need to get the latest bleeding-edge version from Sourceforge, directly from the subversion repository.

Subversion?

In case you don’t know about it, Subversion is a source-code revision control system which allows developers to collaborate on the same project, checking in their changes when they are happy and updating their local copy to bring in changes from other developers working along with them. I happen to use a Subversion repository at home and at work for my professional and part-time coding projects and highly recommend it. The developers of the Collada Blender export plugin also use a Subversion repository hosted at Sourceforge. To get the latest version of the code, you’ll need to install a Subversion client to connect to and export the code to your local machine.

TortoiseSVN is the de-facto client for Windows and I’m currently running an alpha version of their up-coming 1.5.0 release. If you’d prefer not to install alpha version software, install the most recent stable version from here. I’m using this one but the instructions are the same, you just need to be aware that my screenshot will differ from yours cosmetically.

Once you have installed TortoiseSVN and rebooted, browse to the Blender installation folder. Remember, the default is “C:\Program Files\Blender Foundation\Blender\”. Then navigate to the .blender folder in there to find where all the plugins live. Right-click on the “scripts” folder and choose the option “TortoiseSVN->Export” from the context menu that pops up.

In the “URL of repository” text box, put this:

https://colladablender.svn.sourceforge.net/svnroot/colladablender/trunk

Then select the “Immediate children, including folders” option from the dropdown. It should look like this:

Hit ok and it will export the latest version of the plugin, directly from the source-code repository the developers use, into your machines Blender plugin folder. It may be slow, and do not be surprised at data transfer rates of 1k/s – luckily the plugin is very small. If it asks you if you are sure, confirm your paths are exactly as in the image above and hit yes.

You are now ready to launch Blender and start exporting Blender models into Collada files!

To do this, go to the File->Export menu in Blender and choose “COLLADA 1.4″ and be sure to select the options in the image to the right, to avoid any errors.

Choosing to export to triangles is important as Blender allows you to model using quads which, while great for modelling, is not much use to hardware rendering code which requires geometry to be passed as triangles.

Disabling physics is important as the ability to export this is still under development and will cause an error if you do not disable it.

It will export the files with a .dae extension. Visual C# Express will still display it as an XML file with collapsible nodes to make browsing it easier. It also helps identify the file when added as content in an XNA project as the BlenderXNA Content Importer is setup to be automatically applied to .dae files by default.

The image on the left is a render of Suzanne from Blender, and the one on the right is a render from within the Windows build of my current codebase. No more distortion! The distortion was caused by incorrectly creating the Quaternion rotations from the x, y and z planes in the Collada model which, when combined with my translate and scale transformations, caused all kinds of weirdness.

I would never have got this far without PIX, I think I quite like it!

The above is a screen capture from the windows version of my current code-base. Blender-heads will recognise the (slightly distorted) image of Suzanne, the built-in Blender equivalent to the teapot model.

PIX was able to show me that I was not passing my transformation matrices to the correct parameter in the vertex shader. As a result they all defaulted to empty matrices and every vertex position output from it was then (0,0,0). I was simply telling my effect technique to use the wrong vertex shader in my .fx file, and that shader expected the “WorldViewProjection” parameter. Unfortunately, I was populating the “World”, “View” and “Projection” parameters!

After fixing the error in my .fx file, I managed to render something. And a quick Visual C# debug session later, I realised that I had a silly bug in the parsing code I use to pull the data out of the Collada files. And now I can render a monkey!

There’s clearly some work to be done to fix the distortion issues above but real progress has been made. I’ll fix those issues, tidy up the code and probably release a simple demo just for people who are interested.

I’ll be continuing the Blender and XNA series soon which should help those who wonder how I have achieved the above.

I’ve posted an update to this.

I mentioned that I was just getting the following output from my current rendering code:

I had posted on the XNA Forums that I was “completely in the dark” as to what was going on after a call to draw my model. The suggestion there was to use PIX, which is part of the DirectX SDK for Windows. Well, one 438MB download later and feeling like a challenge, it seems PIX has helped me at least identify the issue.

I am sending the position, normal and colour information to the graphics device plus the indices to tell it how to arrange that data into triangles. Well for testing purposes, I have told it to draw 1 triangle and I seem to be getting the right size vertex buffer to be passed to the graphics device but all its values are 0.

This essentially means I am drawing an object so small it has no dimensions, in black and on a black background. Working as intended then…

I am clearly missing the point somewhere when I construct my VertexBuffer in my ContentProcessor but at least PIX showed me the way!

I’ve posted an update to this.

Why Blender?

Blender is an open-source 3D modelling package which is under active development by the Blender Foundation, a non-profit public benefit corporation. It is released under the terms of the GNU Public License and is free for anyone to download and run on a wide-range of platforms, including Windows. There is a huge active community around the world currently using Blender.

It offers functionality to rival that of commercial packages, it’s very quick and it has a user interface that is centred on making your workflow as fast as possible.

Because Blender is free, there’ll be no worry that you’ll have to ditch it’s use when you one day decide to release a game. That might not be the case with using a learning edition version of a commercial package.

Exporting from Blender

Because of the open nature of Blender people can extend it to provide export tools for others to use. This is made possible by having Blender integrated with Python, another open-source package. Python is a script-based language that is often used to enable macros or scripting support in other applications.

As you can see from the image, there are quite a few different export plugins that come with Blender upon install. You might notice that XNA already supports two of the formats in this list: FBX (Autodesk) and X (DirectX). I actually don’t want to those though. I want to use Collada.

Why Collada?

Collada files are XML files, firstly. This makes them really easy to parse and also really easy to explore in Visual C# Express.

It’s an open standard which has the remit to provide a standard format for exchange of 3D assets between applications. The potential in the future is that this plugin can support all those other applications.

The Plan

By using Collada, I hope to make my ContentImporter support as much of it’s flexibility as possible. Then it would be useful just as a general purpose Collada importer for interfacing with other packages and tools you may wish to create. A level editor, for example.

It should be possible to use the plugin to read Collada files into the standard XNA Model class (which I think many users would want) but I also want to explore using it to import into custom classes. My plan is not to just use this to import meshes, but to import other things such as bounding boxes, level floor plans or skeletal animations.

The Code

Right now it is not ready for release in any form. The current status is I have written the ContentImporter, ContentProcessor, ContentTypeWriter, and ContentTypeReader and I’ve dropped a few test blender meshes into my current version of my framework:

A centred cube.

Two cube meshes in different positions and rotations.

Two instances of the same cube mesh but in different positions and rotations.

A cube made from multiple materials.

The Blender Suzanne built-in test model (pictured right).

The good news?

They all import without errors. By tracing through the whole process with the simple cube models, I can see that the data is being passed through to my rendering code. The issue I have is that I have written the full pipeline form scratch and could be introducing problems at any point. In fact the current screen display is this:

I’m literally in the dark as to what is happening in the code. The data is passed to the graphics device and I just have to cross my fingers and hope it will work.

To investigate this, I need to use PIX the DirectX debugging tool.

I’ll put up an unsupported demo once I can iron out the rendering bugs, just so people can take a look but then the next task is to package it into more user-friendly plugins they can just drop into their existing projects.

Next time…

I’ll be looking at the Collada file format in more detail with a glimpse of some code examples to show how it will be parsed. I’ll also document progress on my work with PIX, something I think will be an interesting task.

Read part 1

When I first started playing with XNA, I was intrigued as to how XNA allows developers to get their game assets into XNA. Out-of-the box, XNA allows you to easily include certain graphics formats such as .PNG or .JPEG images and 3D file formats such as .X (DirectX) or .FBX (3D Studio Max). Great if your 3D modelling package exports these formats but not so convenient if it does not. I want to import from Blender but this is not supported directly by XNA….

However, XNA does have one pretty clever trick up its sleeve:

The Content Pipeline

This is a customisable process in which XNA can read source file formats and convert them into binary files for distribution with your game in a format that your game can then read in at run-time. Drop an FBX 3D model file into the content folder in your project and Visual C# Express will use the appropriate Content Pipeline class to parse it and package it into a binary file (an XNB file) during the build process. For your game to use it, you simple have to call the Load method in the XNA run-time content manager to pull the data in and populate a nice, clean runtime Model class.

Things get even more interesting when you realise that you can write your own Content Pipeline components to customise things to your liking. And if I want to import Blender models into my games and use them, I need to understand them.

So in this article, and subsequent ones to follow I am going to look at using the Content Pipeline to import Blender 3D models and render them in an XNA game. As this article is published, I am about 2 or 3 blog-posts ahead of what I am describing – and I’m still working it out as I go along!

What I’d like to share is what I’ve needed to learn in order to accomplish this, plus how I overcame any problems along the way. If you too are looking to create your own Content Pipeline plugins, this may be of use to you. Even if you are not, learning more about the Pipeline could open up some avenues in your game development that hadn’t really occurred to you. Let’s take a look at the Content Pipeline and its fundamental components.

The pipeline consists of 4 distinct parts:

ContentImporter, ContentProcessor, ContentTypeWriter, and ContentTypeReader.

In Visual C# Express, when you add content you can specify which Content Importer and Content Processor it should us to compile that data into your project. If you wanted to, you could create just a ContentImporter and bolt that onto an existing ContentProcessor in order to support a new file format that XNA does not support already. The flexibility is there though if you wish to go one stage further and customise the entire pipeline for a particular type of game asset.

I’ll briefly run through the components mentioned above to explain what they do.

ContentImporter

The ContentImporter parses the content file and fills a set of appropriate classes with the data it contains. XNA provides a set of content classes ready to store such data. For example, if your file contained 3D geometry, you would populate a MeshContent class. For 2D bitmap graphics, you would use a TextureContent class. These content classes can be arranged in a hierarchy so you could pull in multiple images or multiple 3D meshes and arrange them in a parent-child configuration. The important thing to remember about a Content Importer is that it does not care about what the final use of the data will be. Its job is simply to retrive information from the file the content is contained in and make it available to the rest of the Pipeline to do with as it pleases.

ContentProcessor

A ContentProcessor converts those standard data types mentioned above into something that resembles the run-time data structure. If you simply wished to support a new fileformat that XNA does not natively support, a ContentImporter would be all you needed, you could then use the built-in XNA Processors to prepare that content into one of the built-in types, such as Model . So if you wanted to support the ILBM format for textures (showing my age there), then a ContentImporter would do just fine providing it populated a TextureContent class properly ready for processing by the built-in XNA texture processor.

Conversely, if you wanted to ditch the standard XNA runtime classes, such as Model and use your own, you would need to create a ContentProcessor to spit out your custom class. You could still take advantage of the built-in ContentImporters to save you having to write a class to parse FBX files, for example.

Using your own class instead of the built-in XNA-provided ones might seem risky but it’s positively encouraged. And if Shawn Hargreaves, one of lead developers of the XNA framework endorses that approach , you shouldn’t feel too worried about going down that route also.

A moment ago I said that the ContentProcessor creates something that “resembles the run-time data structure “. I don’t want to confuse the reader too much right now, but I’ll give one example of why this is necessary or useful:

You might wish to specify a particular shader or texture for your model when you import the model itself. That same shader or texture might well be used again in other models in your project. Without going into too much detail too soon, the pipeline allows you to put a placeholder in your content to refer to this other asset. The pipeline will then pull this particular asset in at runtime and plug it into every class that needs it. This ensures that you do not pull the same dependencies in more than once.

ContentTypeWriter

You only need to implement a ContentTypeWriter when you are going to use your own custom runtime class to hold your content asset. This is a surprisingly simple class to write as it simply dumps the intermediary class output from your ContentProcessor to an XNB file. An XNB file is what every item of content in the XNA framework is stored in after the project is built. You don’t need to understand what the exact format of the file is because ….. it doesn’t have one !

If you want to store 10 3D meshes in your XNB file, you can. You would simple write out the number of meshes and then follow that by writing out the meshes themselves. XNA looks after the hard part of serialising these objects into a binary format and your code just looks something like this:

output.Write(Meshes.Count);
output.WriteObject(listOfVertices1);
output.WriteObject(listOfTriangles1);
..
..
output.WriteObject(listOfVertices10);
output.WriteObject(listOfTriangles10);

I’ve simplified the above but it illustrates that you can just dump out whatever you please, providing you write the part that reads it in to use the same order. That brings us nicely to the final part:

ContentTypeReader

Again, like ContentTypeWriter, you only need to implement a ContentTypeReader class if you are not going to be using the built-in run-time classes such as Model or Texture and instead plan to use your own custom class. Using the pseudo-code above as an example, the complementary ContentTypeReader would do something like:

meshCount = input.ReadInt32();
for (i=0; i < meshCount; i++)
{
   listOfVertices[i] = input.ReadObject();
   listOfTrangles[i] = input.ReadObject();
}

The ContentReader creates an instance of your run-time custom class that will hold your game asset, populates it and returns it. When you ask the ContentManager in your game to load in your asset, the ContentManagers load method calls this ContentTypeReader and returns your custom content class ready to use in your game at runtime.

Next time…

In my next article, I am going to explain why I decided to use Blender for my game content generation and discuss the various ways to get content out of Blender. I’ll explain why I chose the export method I did and we’ll look at the file format directly so you can better understand how we actually go about pulling the data it contains into the XNA environment.

Read part 2

Who is this for?

This is for people who have an interest in learning to program games for fun but wouldn’t know where to start. I’ll assume no programming experience at all but this won’t be an in-depth tutorial on pure programming. I’ll point out the basics as we go and refer the reader to more in-depth information so they can fill in any gaps as they gain more experience.

What will I need?

Well, you won’t need any money. Everything we will be using will be free and legal. Specifically, we will be using XNA Games Studio Express to program our games.

Any reasonably powered pc from the last 5 years should be capable of building and running the demonstrations I’ll be sharing. There is also the option to run the demos on an Xbox 360. That does cost money but isn’t a requirement at all, you will be able to follow along just as well on a PC.

The official hardware recommendation from Microsoft is:

“To run XNA Framework games on Windows, you will need a graphics card that supports Shader Model 1.1 or greater and DirectX 9.0c. We recommend that you use a graphics card that supports Shader Model 2.0 because some samples and starter kits may require it.”

You’ll need a couple of downloads. These are fairly big but if you are on broadband, it shouldn’t take you too long to get them. First, download and install Visual C# Express Edition. You are also going to need the Visual C# Express Service Pack too. Install Visual C# Express Edition and then run the service pack.

Run Visual C# Express Edition and then register it. Although you can register later, you’ll need to run Visual C# Express at least once before installing the XNA Game Studio in the next step.

Finally, you need to install Microsoft XNA Game Studio Express 1.0 Refresh edition.

They are quite some download, aren’t they? While you are waiting for the files to download, read ahead and find out a bit more about Game Studio Express, XNA Framework, C# and the other new terms that are mentioned above.

One thing that will cause glitches in XNA games is if the garbage collector kicks in at an inappropriate time so a strategy to avoid this needs to be adopted quite early on in development of your game engine.

An excellent post by Shawn Hargreaves gives an overview of two distinct strategies to reduce the impact of garbage collection on your code. By picking one of these and sticking to it, you can either ensure that when garbage collection occurs, it doesn’t affect performance adversely or avoid garbage collection altogether.

Approach 1

Don’t allocate anything. This sounds quite hard to achieve but it isn’t as difficult as it sounds. You can allocate memory still (your game will be pretty limited if you cannot) but you allocate it all up-front.

The challenge with allocating everything up-front is that you have to know before-hand in your game how many objects you will need exactly. Well that’s pretty straightforward for storing something like meshes as you will know at compile time how many you need. It’s when you want to show multiple instances of those meshes on-screen at runtime that you are faced with a problem.

For example, if you have a car model and want to show a street scene in your game, you may wish to re-use that car model to place 3 cars on the road at night but put 20 on the road at peak times. You’ll need to allocate enough of those objects during the games initialisation to deal with all possibilities.

Approach 2

Allocate what you want, whenever you want but keep the managed heap simple. Each time you create a new object and store the reference, that is one more reference the GC needs to keep track of. The more references you have, the longer GC takes – bad news during a screen update. A lot of data with plenty of references to other objects is going to slow things down come GC time and the fact you are constantly allocating means that GC will occur sooner or later – always when you least need it.

To keep references to a minimum, you could use arrays to store your object collections and use a simple integer reference to link them instead. See Shawn’s post for more details.

My choice?

I went for Approach 1 – don’t allocate mid-game. The main reasons were that Approach 2 required that I maintain references between objects using integer indexes to look-up a required object in a collection. That then means that I have to manage those references myself. I find that idea a little crazy as c# is more than capable of maintaining those references out-of-the-box and the idea that I would ditch that and implement my own reference management code sounds like a recipe for disaster! As soon as I destroy an object, I would then have to go through all my data structures looking for references to it to clean up. That sounds a lot like a garbage collector to me and I have to wonder whether the performance benefit of reducing object references would be cancelled out by my own ‘DIY’ garbage collector.

One thing that made Approach 1 easier for me was to implement resource pooling. The idea is that you allocate an arbitrary number of objects up-front and then use a resource pool class to maintain the collection. When you need a new object, rather than allocate and risk garbage collection, you simply get a ‘ready-rolled’ one from the pool.

Luckily for me, Thomas H. Aylesworth has written a pretty cool generic class to allow you to pool any type of object. The only constraint is that the object must have a parameterless constructor. The reason is that you will need to be able to get an ‘empty’ object out of this pool and fill it with your data before it can be used. If it didn’t have a parameterless constructor, the pool would have trouble allocating all the objects you need up front as it would not know what parameters were appropriate for the constructor – it is a generic class after all.

I’ve added the class to my own engine, and you can too provided you leave his copyright and license information intact as I have done.

Using the pool class

modelPool = new Pool(10);
effectPool = new Pool(5);
instancePool = new Pool(100);

This code shows how you would initialise the pool. Note, the Effect class in XNA does not have a parameterless constructor so cannot be used directly with the Pool class. I simply created my own Effect class and wrapped the XNA Effect class up in it. To ensure my code then refers to my Effect class rather than the XNA one, I add the following uses directive to the top of each source code file:

using Effect = XNAEngine.Graphics.Effect;
using XnaEffect = Microsoft.Xna.Framework.Graphics.Effect;

Then I made sure my Effect class had a parameterless constructor. This was all made a lot simpler by the fact that I wanted to customise the Effect and Model classes myself anyway and while the XNA classes are useful, your own class can be less generic than theirs and ideally faster.

Pool.Node effectNode = effectPool.Get();

This doesn’t allocate any memory. The Get() method on the Pool object simply marks one of it’s unused pre-allocated objects as ‘in-use’ and returns a reference to it. To access the Effect object itself, simply use the .item property.

effectPool.Return(effectNode);

This code returns the node back to the Pool, ready for re-use later. It isn’t destroying the object though, it’s there waiting if we need it again!

Conclusion

As Shawn said, “you must pick just one path and follow it to the bitter end”, which I plan on doing. I don’t think I ever would have taken the Approach 2 path he describes, but there may come a time when I need it so it’s nice to know the option exists.

I stumbled across the website of Benjamin Nitschke after reading an article about a Microsoft competition to write an XNA game in 4 days. I think you’ll agree that the results are staggering! So, it’s Ben’s book I decided to buy and here is a mini-review of it. The book is available now and I got it at Waterstone’s for £26.99.

Who is it for?

The book is aimed at newcomers to XNA but NOT newcomers to programming. In my opinion, this was a good move. There are a lot of C# books out there that cover the basics and I would have been disappointed had this book dedicated the initial chapters to re-iterating the basics and leaving less room for XNA goodness.

If you are a beginner, I would still recommend the book if you are interested in games programming as the initial chapters focus on simple games that could serve as an excellent way to brush up on your programming skills – much more fun than “Hello World!” It would be wise to have another text on pure C# programming though.

What it covers

Subjects covered (and this is an abbreviated list) are:

• Setting up the development environment.
• Using the Agile Method to develop games.
• Simple 2D games such as Pong and Breakout.
• Displaying a simple 3D model.
• Using shaders, normal mapping and other techniques to produce professional visuals such as bloom, motion blur, glass effects etc.
• Sound.
• Landscape design and implementation.
• Physics.

What’s refreshing is that by leaving out elementary basics, Benjamin is able to dedicate a large chunk of the book to advanced topics.

Each chapter tends to focus on a particular topic by showing how to implement it in a real game. There are a number of games created in the book ranging from the simple 2D games mentioned earlier, up to a fantastic 3D racing game in which you throw your car around a track that snakes in and out of a realistic rocky landscape.

Ben says early on how much he prefers XNA to DirectX programming and in fairness to him, he delivers the goods to back up his claims. The games he creates throughout the book certainly have that professional polish and don’t feel amateurish or compromised in any way.

How to use the book

The author does not list the code for each game in its entirety. Instead, he chooses to focus on the really important snippets of code that illustrate his point, leaving it up to the reader to download the source code from Wrox and read through to gain more insight. I think this is a good move on his part as I would have been just as disappointed with the book being ‘filled’ with code dumps, as I would if it dedicated chunks of pages to explaining how variables work.

When it comes to 3D, he focusses more on how to get XNA to do what you need it to do rather than explaining every single aspect of 3D, such as matrices. I’ve always found such texts on 3D very dry and at least with this method, you can actually get something done and become more comfortable with the concepts. It’s always less frustrating when you can actually experiment with real code to get instant feedback.

Agile

Benjamin is a big fan of the Agile Method and it really suits game development on XNA. I must admit I was initially shocked to see it promoted so much in the book but as I have progressed, the benefits have been realised. I won’t explain it in full but the process goes a bit like this:

• Think about a part of the game you want to implement (eg drawing the paddle in breakout and moving it around).
• Write a unit test which calls some (as yet uncoded) methods to accomplish this task.
• Write the methods which actually do the work.
• Run the unit test until you get the required result.

It’s a useful way of working as you focus on just one thing at a time and gradually tick off all the functionality your game requires. At the end you still have your unit tests so you can quickly identify any new bugs you have inadvertently created by just running each in isolation. I’ve always coded by dividing a problem into small chunks but this way formalises that a bit and really helps you focus on solving one problem at a time while doing it well.

Verdict

As you have hopefully gathered from this article, I like the book. It’s excellent value for money as it doesn’t re-iterate programming basics, doesn’t pad out the book with endless listings but does take you from being a beginner with XNA to being able to handle some very advanced topics. My gut instinct is once you have exhausted this book, you’ll be a pretty accomplished XNA games developer in your own right.

Thankfully, someone else has written a nice tool to create the intermediary bitmap for you. All you then need to do is select the white characters in photoshop and start applying effects!