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.

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