The Search for the Next Model Exchange Format

3D as an industry has seen rapid change since its inception. Buyouts, mergers, and takeovers often mean that products can often outlive the companies that created them. Asking a question as simple as ‘who made .obj?’ is a story in itself, and, while researching this piece, took me through a trip of the history of the 3D industry – one that is often overlooked and is quickly becoming forgotten. Working as a 3D artist, you have to master dozens of tools, with many going from new to outdated at a rapid pace. When you’re working against a deadline, your concern is usually focused on what file format a client wants the model delivered in, not where that file format came from. The next time you boot up 3ds Max, Cinema 4D, or Blender to make a model, it might be worth asking ‘who made this product and why?’ – you might be surprised!

This article looks at the history of some of the household names of file formats in the 3D industry and the circumstances that made them what they are. Although there are dozens of formats that were (or are) competitors to those described in the article, these three are good representatives for their eras. Many 3D industries (such as film, medical, manufacturing, and games) have their own specific formats that have seen strong adoption in their categories as they serve the needs of specific workflows. This article will cover a number of popular interchange formats that are generally used in film and real-time environments. Finally, it’ll look at the future of 3D file formats on the cutting edge of innovation!

The stars aligned for OBJ to become the defacto standard interchange format to build against.  

In the Beginning: OBJ

Quick history: OBJ was originally a UNIX file format created by Wavefront Technologies, a software company founded in 1984 that focused on film effects. Wavefront OBJ was the model format for The Advanced Visualizer, the 3D modeling and animation software used on such films as The Abyss, Terminator 2, and Jurassic Park. TAV was their flagship product through the 1980’s and 90’s. In 1995, Wavefront merged with a company named Alias to become Alias|Wavefront, releasing a new modeling package called Maya in 1998, effectively ending TAV’s mainstream use. When Alias|Wavefront rebranded to Alias in 2003, the most lasting mark of Wavefront in the modern 3D industry became a prefix for the OBJ file format.

The modeling package interface in TAV (Image credit: foetz)

How it’s used today: Wavefront OBJ is a beautifully simple model description format. For undergraduate computer science majors taking 3D classes, understanding the basics by writing an OBJ model viewer in something like OpenGL is an early semester assignment. The ASCII (plain text readable) version is well documented, and even quick searches for ‘obj’ will return dozens of results from educational institutions on how the files are structured as part of course notes. Storing vertex, UV, face, and normal data is incredibly straightforward and is a good introduction to the way modern 3D graphics work.

With a strong pedigree, data stored in a way that’s easy to understand, and the format being created at the birth of the modern 3D computer graphics industry, the stars aligned for OBJ to become the defacto standard interchange format to build against.

The file format isn’t without its limitations. The OBJ file only stores mesh data; in order to get material information- even simple material and texture names- the OBJ requires a companion .mtl file, a format that was never universally standardized. OBJ doesn’t store any kind of animation data- bones and vertex skinning aren’t at all supported- let alone concepts like keyframe deformations or node based hierarchies.

 

A simple box exported to OBJ. Vertices, normals, UVs, and faces are clearly stored.

Despite all that, OBJ is, at some level supported, by just about every 3D app on the market today. It lives on not due to its robustness, but because of its simplicity. Compatibility is easy for programmers to write in, and many are already familiar with it from an academic standpoint.

The Present: FBX

Quick history: in 1996, a file format was created for Kaydara’s FiLMBOX software called FBX. It was initially designed to store and transfer animation data, which was the tool’s primary function in the production pipeline. FiLMBOX would later become MotionBuilder – a name people may be more familiar with, as it was the name of the suite when it was acquired by Autodesk (and is still the name it holds today). Before it became part of Autodesk’s suite in 2005, FBX plugins were available for various 3D packages, being provided first by Kaydara and later by Alias.

 

The FBX 6.0 exporter dialogue in 3ds Max 2005.

After the acquisition by Autodesk, they realigned both MotionBuilder and Maya to integrate with the rest of their packages. Although FBX was available as a 3rd party plugin for Autodesk software before the acquisition, the company now owned the format and made it the spearhead for an exchange container to move 3D data between their content creation suites. Although capable of handling mesh data since its creation, it was still an ‘animation first’ file format. Autodesk also grew out the capabilities of the file container, going from a dialogue with around a dozen options for exporting mesh and animation data (above) to its current release with over forty settings to tweak in over a dozen mesh, animation, and scene categories (below).

The FBX 2016.1 exporter dialogue in 3ds Max 2017.

On top of improving mesh storage and transfer options, Autodesk released an FBX SDK starting with their 2005 release, making it possible for 3rd parties to write their own plugins. With a plaintext readable version of the format and an SDK that allows application developers to access the file, FBX has become a mainstay exchange format between 3D modeling packages, and is the defacto standard for many end applications like game engines including Unity, Unreal, and Lumberyard.

The same simple box exported to FBX ASCII.

Although FBX is generally robust, it holds onto a great deal of legacy baggage. For example, material support is rather basic by today’s standards; FBX natively supports map assignments for lambert and phong shaders, but with the rise and standardization of newer, more physically accurate shader methods, these material models are outdated in most situations. Material transfer with texture maps has to be handled separately depending on the art pipeline. It’s hard to simply add, deprecate, or reassign these materials since that would break backwards compatibility. On top of that, it is solely maintained and wholly owned by a single company. Although it has an available SDK, the file format itself is not officially documented and closed source. Open source projects that wish to use the SDK must prompt end users to download the closed source plugin separately.

In short, 3D needs its own .jpg, not another .psd.

The Future: The Search for the ‘JPEG’ of 3D

Technology-centric industries are often fast to change- not just in tools and formats, but in fundamental approaches to problems- and the 3D industry is no different. The modern problem the industry believes it has now isn’t the exchange of mesh and texture data to be used between projects; instead, the hurdle they see is the native viewing and interaction with 3D content without the need for the end user to have expertise in content creation packages. In short, 3D needs its own .jpg, not another .psd. We can currently hand off models between professionals for editing and use in larger projects, but it’s still quite clunky to share individual models in the same way you’d share photos or videos with people outside the industry

Much like FBX was an answer to OBJ’s incapability of dealing with animations, efforts are being made to answer problems that were never considered when FBX was created and matured. Although FBX serves the needs of artists and professionals for moving data from package to package, it usually needs additional work from the end user to achieve true parity – think of it as a box that you’re expected to spend time unpacking and rearranging the contents of before they’re ready to use. On top of that, almost any modern model format needs to be compiled into a different, native format for GPUs to read, which is a requirement for applications that load models in real-time.

One contender for a modern exchange format is the Khronos Group’s GL Transmission Format (glTF) specification. Focused primarily on the nativization of 3D objects and scenes for the web, it is attempting to not just act as a container for meshes and textures, but perform much of the preprocessing that is done by end applications to load model data directly to the GPU. glTF is unique in that it is trying to stay completely platform agnostic and easily extensible, with no single end application in mind. At the same time, the spec is providing a set of modern standards for material definition (version 2.0 of the spec has adopted PBR metalness) and a rich set of data necessary to recreate framing for a scene, like FOV, perspective, and aspect ratios for cameras, as well as animation at both the skinned mesh and object levels.

The end goal of glTF is to make 3D data readable by end devices the same way image, audio, and video files are today. The idea is that 3D will see an explosion of new content if models can become easily sharable viewable, much like what .mp3 did for music or the H.264 video codec and Youtube did for video. With the advent of new technologies like mixed reality platforms that rely heavily on 3D content for even basic user experiences, there is going to be a demand for 3D like we’ve never seen before, and many industry leaders believe that the tools we have at hand don’t meet all the needs of this potential future.

Instead of creating a new and better exchange format, TurboSquid took a different approach with the introduction of StemCell models. In case you haven’t heard, StemCell allows 3D artists to upload a model created in one format to TuboSquid’s servers, where perfect conversions are automatically generated to several other formats. It creates an ideal scenario where customers and artists both win. Customers feel like they’re working with a native file in their preferred app and artists can focus on creating awesome new work without the hassle of converting their models to other formats.

So, how does it work? It actually starts at the beginnings of model creation. In a nutshell, an ideal StemCell submission consists of clean geometry and texture-based materials for standard specular and PBR workflows.

TurboSquid provides a ton of guidance StemCell’s modeling workflow so an artist can create models according to the specs, and the results are absolutely stunning. There’s very little difference across a variety of applications.

With a library of over 1,000 assets and more added every week, it looks like StemCell could be just the thing to solve the exchange format dilemma permanently.

References:

People Behind the Pixels | The History of Computer Graphics

OBJ:
FileFormat.info | Wavefront OBJ File Format Summary

Wikipedia | The Advanced Visualizer

Wikipedia | Wavefront Technologies

Software Guide | Wavefront Advanced Visualizer

Nekochan Net Forum | [Review] Wavefront Advanced Visualizer (TAV Images)

Wayback Machine Internet Archive | About Alias

FBX:

Wikipedia | FBX

Autodesk | FBX Overview

Autodesk | FBX SDK Programmer’s Guide

Banex Developer Blog | Useful Tips for a Game Developer

GLTF:

Github | glTF – Runtime 3D Asset Delivery

Khronos Group | glTF Overview