Imporing blender models to XNA as FBX

This post was meant for release on April 28th. I've been very busy in May and hadn't had much chance to update until now. Sorry.

For Space Combat Sim I've been making game models using Blender. It's powerful, it's free and it's got an active development community churning out new versions regularly. Check it out.

Like most modelling programs Blender uses its own file format for model data. XNA projects can't read these files. You normally can only add .X and .FBX files to games using XNA (though there are ways of adding your own model file importers via content pipeline extensions.) Fortunately Blender provides exporters for both X and FBX. I chose FBX due to the readability of the format and the fact the exporter worked more consistently for me.

Exporting from Blender to XNA created two major issues for me. One was ensuring the right material shaders were used. That was handled by writing a simple custom content processor. I simply named materials using "shader-name" which worked nicely. The second issue was more annoying. Blender uses a different co-ordinate system from XNA.

Huh? All modelling programs express positions using three numbers representing the object's position on three axes called X, Y and Z. Each axis represents one direction an object can move. In XNA, the X axis goes left to right, the Y axis goes from upward and the Z axis goes out from the screen (backward in the game.) In Blender the Z axis goes upward and the Y axis goes into the screen.

The result is that if I export a model and use it in XNA as is, it faces downward. Obviously that's a problem. Fortunately XNA provides a nice simple solution.

Just rotate it!

As you can see here the content processor lets you specify a rotation to be applied to the model before it's used by the game. This takes care of things nicely.

To finish, here's a list of things to watch out for.

• Scale. If you don't make your models size consistent with each other you'll need to deal with this in the content processor.
• Shaders. By default the model processor in XNA will assign the model a basic shader to render it. Not much good for fancy lighting effects and such.
• Orientation. I tended to model my ships facing along the negative Y axis keeping rotation simple. If your models aren't facing straight along an axis importing can be more painful

More Spit and Polish

The project demo is in just a few days now. So I'm going crazy with minor bug fixes and polishing to ensure the demo goes well. For example:

• The game join menu doesn't crash when no games are available


• The game join menu will poll for new games if none are available


• Beam weapons now do damage when swept through other ships


• All incomplete scenarios are have been disabled


• Fighters have photo****ed textures instead of default test patterns


• Minor damge model bugs fixed


• Thrusters flicker slowly enough to be noticable


• Sound effects fade correctly

Regarding the photo****: One thing I really wanted to do in this game was give the fighters a nice metallic look. Metal is shiny! But, if I add shininess to the game it gets choppy. Ugh. But I might have a solution. Rust! Patina! etc.

I want to avoid making the game a rusty-brown shitefest so I'm hoping to go for more of a tarnished silver/brass/bronze/copper look. If, later, I manage to get some decent shininess at decent speed I'll bring back the metal look I wanted originally.

bAAAAAAttlezone

The final project for my game development course is roughly done now. Here's a screenshot for postarity.



The real nasty part was integrating physics into a real project for the first time. I used JigLibX at first but it had several problems. The most severe being a poor selection of constraints, no forcefield support built in, buggy/broken body de-activation and poor performance (especially on the X-Box). I ended up fixing the body de-activation by hacking in a simple iteration through all of the bodies in the system to do the deactivation. No, I'm not submitting this as a patch since it circumvents what should be a superior method... eventually. I doubt JigLibX is going to see much work however since I remember seeing a post from its author about the creation/release of a new .NET physics library.

Anyway, I ended up switching to BEPU physics instead. I very strongly reccommend this engine for both its performance, which was quite decent on PC in my project, and its ease of use. I found the integration of BEPU was very simple to carry out and that tasks such as creating composite bodies, constraints etc. was very simple. This is actually somewhat inspiring since I might be able to use this for a future project I've been meaining to do. Sadly, I still have performance issues on the X-Box 360 though the game is playable if I keep the number of objects low.

Spit and Polish

Not much to say about the last couple weeks of work. I've added some new visual effects to Space Combat Sim and completed the three different fighter types. At this point the game is somewhat demonstratable but still kinda unstable and needing significant testing to improve its balance. Here's a screenshot of the new effect I added to the game.



I've been making a lot of small tweaks to the game of late. My primary objective is to be ready for the project presentation which is coming alarmingly soon. After that I need to have an open demo at the school's Tech@Work event. The most noticable changes to the game are the addition of a semi-working server selection screen, and a lobby screen. These aren't all that interesting to talk about but they produced a spectacular number of bugs during development.

The other feature in the game is the menu background. Very minor when compared with stuff I talked about earlier but it has an amazing effect on how complete the game feels. All I did was randomly spawn objects (that look exactly the same as the ships but without all of the movement code) and have them move toward and past the camera.



Much better than plain old CornflowerBlue eh?