The Exporter

Exporting content from Max is a pain. Invariably I will be writing and rewriting this exporter until the day I die. Why you ask? Most game studios crank out and exporter in a week or so and then perform quick touch ups only as necessary. Well I can't argue with the success other studios have but I'll try to explain my thinking.

For one the exporter is the central piece of my content pipeline. It needs to handle exporting all kinds of content and it needs to do it easily. If the exporter is a pain to use for one reason or another that will slow down dev time. If it's buggy then it's useless. If it's not expandable then I'll constantly be using win32 gui designer to relay out my widgets. All that said the point is that my exporter needs to be rock solid. It needs to support umpteen bajillion options and it needs to be fast to use.

Now the first time I created a Max exporter I used the fast and loose approach. I thought who cares about the exporter it's the game engine that I really care about. Well I was wrong and I ran into big headaches. My first shortcut was to use classes from my game engine. This leads down the rabbit hole of all the problems with early version of my game engine but I'll just say I ended up having to link my exporter to directX, deal with auto-registration errors(a new peeve), and fight other non-exporter related bugs. All that said I did get a working exporter before. It just wasn't easy to use, wasn't robust, and took forever to add or remove features.

This time I decided to create an uber exporter. I really wanted to use C# for the interface but I didn't see any easy way of doing it. I suspect many exporters are made using MFC but I read somewhere in the docs that I wasn't supposed to use MFC and I've never used it before and didn't care to learn it. So I was forced to do some win32 gui programming. Win32 gui programming is about as much fun as punching yourself in the face.

To meet my first design requirement of flexibility I decided to use a tabbed view. This will allow me to simply add new tabs as more options or categories of options become available. The drawback here is usability. Artists and game designers will now have to click through multiple tabs to get the options they want for export.

To improve the usability of my exporter I created a profiles system. On the main tab of the exporter is a combo box for selecting a given profile or saving a new one. The profiles are just a list of export options. In theory content developers will only need to create a profile once and then they can rapidly export models using that same profile over and over again.

I created the exporter as a first class app. By that I mean I created the code for it as robustly as I know how. I didn't cram multiple classes into one file or include a bunch of extraneous libraries. I'm using the xml library from my game engine and a few third party libs like boost and stdlib but for the most part I'm keeping the dependencies down. I created some rough widget helper classes to make binding data easier. All in all I've spent considerable time up front in hope that it will pay off later on.

So what exactly am I currently exporting. Well when a user clicks export he will if all options are selected generate the following files and folders

• meshes
• models
• profiles
• scenes

Ideally there will be other folders in here for other game assets like sounds and scripts and what not but currently this is what max exports.

Meshes: Is the folder containing all the meshes the game can load. This is not a flat folder but contains subfolders for specifying a particular model that a mesh belongs to. Meshes are essentially binary data. They contain a mesh header describing the data and then a long list of face and vertex data. The data itself is setup so that it can be read as one big chunk when it comes time to load a mesh.

Models: This folder contains a bunch of xml files describing a game model. So if an asset is a hierarchy of meshes with textures and shaders this xml file is the description of that. When a scene exports each top level mesh node is treated as it's own model.

Profiles: This contains xml files for the options used for exporting. So an artist may have several sets for exporting different types of models and a designer may have several more for exporting his content.

Scenes: This folder contains a list of xml files describing a particular scene. Basically it lists all game entities and their components along with position in the game world. It also lists all assets used by the game world independantly.

I'm certain more features will be added to this damn thing but that's what it does now. There's lots more to say about exporting so I'm sure I'll revist with more posts in the future.

Later.