Today I was contacted by a developer from the jMonkeyEngine team who was interested in spreading the word about the OPENGEX format among indie developers, and I agree completely with the goal.
Before I even get in to OpenGEX, it’s helpful to first look at the alternatives available for 3D import/export. Moving 3D assets between software packages and into game engines has long been a challenge and there have been a number of popular formats as a result. Let’s take a quick look at the more popular choices.
COLLADA is probably the monster in the segment now, standing for COLLAborative Design Activity, ranking up there amongst the most contrived acronyms I’ve ever encountered. COLLADA started life at Sony and was later submitted to Khronos, the party responsible for OpenGL, for standardization. Several major players in the industry signed on to support COLLADA, pretty much everybody actually, but most importantly, all the big boys signed on, including Alias ( Maya ), Avid ( Softimage, at the time anyway… ) and Autodesk ( 3D Studio Max ).
COLLADA was designed primarily as an interchange format between tools, allowing you to for example use Max and Softimage in your art pipeline rather seamlessly. For the most part it worked too, the industry came together and interchange was probably better than it’s ever been.
Obviously there is a but, or I wouldn’t be writing this, I would just say “hey, we should all use COLLADA!” and be done with it. So, time for the but… and what a big but it is. ( sorry… ) First off, COLLADA is a huge, some could say bloated format, that is ill suited for games. Again, it was designed for communication between authoring tools, ease of use and performance certainly weren’t priorities. Being controlled by the Khronos board certainly couldn’t help either, and it didn’t. The format became convoluted over time.
The next major problem is a change in the industry… you see, Autodesk bought everything. So suddenly most of the software this open standard was designed to work with are owned by a single company. Now with each new version released, things are broken, often needlessly. For a large company like Unreal or Unity, supporting a complicated and constantly moving target isn’t a big deal, they can frankly just throw money at it. For smaller, indie or open source game engines, this isn’t a solution.
The FBX format started life in a product called Filmbox, made by a company known as Kaydara. Filmbox started life as a motion capture suite and obviously needed to support various software packages, so they created the FBX file format. In the early days, well before the rise of COLLADA, it was supported by pretty much all of the common 3D packages of the day ( 3D Studio Max, Lightwave, Softimage, Power Animator ( Maya’s precursor ), Cinema3D, etc ). Well, Filmbox was eventually renamed MotionBuilder, a product that exists to this day and it was acquired by Alias, the makers of Maya and PowerAnimator before it. Remember how in the COLLADA write up I said Autodesk bought everything? Well, that wasn’t really an exaggeration… in 2006, Autodesk purchased Alias and with it gained control of MotionBuilder and the FBX file format.
So, fast forward to today and Autodesk controls Softimage, 3D Studio Max, Motion Builder, Softimage and more. FBX is the format they use internally to communicate between their own tools. So at the end of the day, if you are working entirely in the Autodesk ecosystem it’s the easiest and safest route to go.
For game developers though, it’s a bit of a different story. Once again, the large guys can easily support FBX, just like COLLADA. Perhaps most importantly, Autodesk make available an SDK for working with FBX. Some game engines make use of this SDK such as LibGDX’s fbx-conv tool. There are limitations on this license however on of the biggest is that it is incompatible with GPL, meaning Blender and similar tools can’t use the SDK. ( although I would put this on the awfulness of GPL instead of Autodesk’s license, but that’s splitting hairs ). This means Blender uses a “clean room” implementation of FBX and this means that the FBX support in Blender is, well, pretty crappy.
FBX however is not a game friendly format either, once again, it’s designed for communication between game tools, not for fast and efficient storage. So even in the case of tools like LibGDX that support it, they ultimately just use it as a source and convert it to their own internal format. This means each time you change your asset in your modeling tool, you have to convert it again and again.
OBJ, 3DS, MD2, DXF, etc
This is a catch all category, but it’s worth noting the above. Open Source game engines commonly support some of the older simpler formats, one of the most common being OBJ. These were the file export formats from popular 3D applications from years ago ( OBJ = Alias, 3DS = 3D Studio, DXF = AutoCAD, MD2 = Quake Engine ). The reason they are supported is the formats tend to be fairly simple with a large body of code already available.
On the other hand, they are also ancient and incredibly limited, especially when it comes to animation data. If you have simple requirements, a simple format should do the trick and frankly you will often see OBJ format supported when animation data isn’t needed ( such as by Mixamo Fuse or Poser, for model data ), but once you start adding complexity, these formats start to show their age.
I am mostly mentioning them for completeness only.
So, a TL;DR summary of the negatives of each format:
- bloated and complicated format
- run by Khronos group ( this is a good and bad thing )
- fragile between versions, breaks easily
- not game engine friendly
- proprietary file format
- controlled by Autodesk
- not open source friendly license
- not game engine friendly
- poor animation support
- limited functionality
This brings us at last to OpenGEX ( Open Game Exchange ), an open 3D file format targeted specifically at game developers for use in game engines. It was created by Eric Lengyel originally for the C4 Game Engine and was funded by a successful IndieGoGo campaign. Essentially you can think of OpenGEX as a stripped down, game engine focused version of COLLADA. Instead of being XML based, it uses OpenDDL (Link).
(Edit to fix JSON error)
The easiest way to understand the value of OpenGEX is to compare the format to COLLADA. Fortunately the OpenGEX site provides just such an example. Looking at the OpenGEX format, it’s quite clean, very reminiscent of OBJ, but with support for modern features. The purpose behind OpenGEX’s creation is nicely captured in this comment:
The OpenGEX format was created because Collada, the open standard that we all hoped would provide a well-supported asset exchange format, has proven to be an unreliable mess. The most common source of problems has been the poor quality of the Collada export plugins available for software such as 3D Studio Max and Maya, and we attribute this to Collada’s over-engineered design and its mutating under-specified format.
Now of course, a format is of little use if no tools support it, and this is where OpenGEX shines. There are already exporters for Max, Maya and Blender. Additionally there is an Import template available for implementing OpenGEX in your game or engine. It’s basically a Visual Studio 2013 project with the code used by the C4 Engine to load OpenGEX files.
If you are interested in learning more, you can read the PDF spec here.
So what’s the value in all of this to you as an indie game developer?
Well, if you are working with Unity or Unreal Engine, very little actually. They have the resources to support the COLLADA, with all of it’s quirks, breaks and other warts. If however you are working with a open source or smaller game engine, moving to a much more sane format can make everyones life easier.
As is the nature of any format, the more it’s used, generally the better it becomes ( unless of course committee bloat sets in ). Basically, the less time smaller developers have to spend on content pipeline tools, the more time they have to work on improving their engine. Additionally, the less headaches the game developer suffers getting assets in their game, again, the more time they have to work on the game.
There has been some recent movement in regards to supporting OpenGEX.
First off, the developer who contacted me from the jMonkeyEngine has recently made a Java library on Github available for handling OpenGEX files. This could potentially enable other popular Java based game engines *cough*LibGDX*cough* to support OpenGEX.
It was recently announced too that Ogre3D is working to support the OpenGEX format as well. Again, the developers words perfectly capture why this is important:
Partly to address that I’m planning on adding support for the OpenGEX format.
Because of two reasons:
- The format is actually really good, easy; and contains everything we need. It’s basically our XML mesh and skeleton format, but in JSON.
- Joint effort. There are already plugins. Open Source plugins. Which are being used for the C4 engine. If Ogre adopts the same format, we can share the burden of maintaining 3D asset exporters. Those are hard to maintain given Autodesk always releases a new version every year with partically no difference but breaking many plugins on the way. It should also empower more adoption of the OpenGEX format, and hopefully get others in. Unlike Collada, OpenGEX is good.
That second reason sums it up perfectly. If a number of indie game engines all adopt the same format, the burden of maintenance is spread across a number of developers instead of each developing their own proprietary format and all the support that entails. It also makes creating game tools that work across game engines a much easier task. Finally, it helps break Autodesk’s chokehold on the industry!
So mostly it’s a matter of trying to spread the word and gain support. One critical component would certainly be getting support into the Assimp ( Open Asset Import Library ), an open source model importing library that is the underpinning for many game engines importers today. There is already an open feature request, so if you feel an open game friendly COLLADA option would be useful, that would certainly be a good place to start.