An Even Better Blender Exporter - by Taha - Lotus Spring
Lotus Spring
SubscribeSign in
An Even Better Blender Exporter<br>A short tale and a progress update.
Taha<br>Jun 16, 2026
Share
This is going to be a short tale of a significant improvement that I made to the realtime Blender exporter.<br>So the way the exporter was set up was that the entity and level file format were all hard-coded in the code. When I first wrote this exporter, it was sensible since it was the simplest thing to do. But sometime later, when I was part of a game project for a very short time, I also wanted to set up the realtime exporter as a level editor, but because that game was different than mine, it meant that I had to change the entity properties, and the level formats. And that meant that I couldn’t reuse my blender executable, and had to set up and compile a whole new instance.<br>Then my friend Daniel told me how Valve uses a text file as a sort of schema/format to tell the level editor the type structure, and definitions of the entities. As soon as I saw this, it quickly became obvious that this was a great idea and just made a lot of sense to do. This meant that I could use the same Blender instance for multiple game projects, and also make changes to the level data structure without needing to touch Blender.<br>But I hesitated, and slept on the idea for a good while, never sitting down to do it mainly because I was not sure how to set the text file up without causing more complications. I saw this problem being split into two parts. One part would be the serialization code which is all implemented in C, and the other part would be the UI bits which is unfortunately in Python.<br>The serialization part was crystal clear to me, because the code just needs to extract the vertices, and important data that the engine needs like the entities, types, and enums, flags, … and serialize it to disk/engine. But then on the UI side, there are things that are needed like min and max values for int/float sliders, and description texts for each property. Integrating this second part into a textual format that is human readable and easy to parse was a question mark for me.<br>It is of course possible to go with a JSON-like file format where every parameter is optional, but I generally hate those formats since they are neither easy on the human eye, nor easy to parse, and I immediately get flashbacks to the terrible time that I had writing a glTF file format parser and loader.<br>For the longest time, I decided to take it on the chin, and accept the misery that every time I wanted to make a change to the level file format, like adding a new field for an entity, or adding new types of entities, or changing material property fields, I had to recompile Blender and endure the atrociously long compilation times. And not just that, I had to manually update the code in like 4 to 6 different places for each one of the things.<br>So while my frustration was compounding, I saw an interview Casey did with Marc Leblanc, one of the programmers that worked on Thief: The Dark Project and Thief: The Metal age (which is my favorite stealth game). He was talking about how they were having the exact same problem that they had really long compile times for the engine, and it was rather annoying that every single time a designer wanted to add a new entity type or change the “behavior hierarchy” they had to go to a programmer and ask them to recompile the engine with the requested changes. And they wanted to maximize the amount of work a designer could do without needing to recompile the engine.<br>About a week after watching the interview, I decided that I’ve had enough and seeing Marc talk about their work left me filled with a rather strong motivation to just start working on this even though I still didn’t know how I was going to solve the problems.<br>Well here we go, fast and loose.
My plan was to write all the C parts for this system to work, and I would worry about the UI bits later. So I started to work and somehow, in a single evening, I had the entire thing working. A text file that specifies the entity and level data, a parser, and all the C side code needed to retrieve those values from Blender and serialize it to the engine.
Example of how the entity definitions text file looks. I had to remove a bunch of stuff here because of spoilers :)<br>So with the C side being done, the only thing left is the UI. The text file format is very simple and I prefer it to stay that way. It’s very human readable and also very easy to parse. And every line pretty much comes down to having a name, a type, and an optional default value, and that’s the bare minimum I need for the exporter.<br>I was very adamant about wanting to keep this file simple, both for when it comes to parsing it, and when it comes to having it be human readable, so I was very resistant to adding any extra thing to this file. And then I had an epiphany as I realized I could actually leave this file alone… the extra...