3D formats overview: OBJ

In the ninth part of the series, we take a look at the effectively standard format for 3D graphics

Anton Larin
Anton Larin
4 min read
Share:

Other formats overview:

IGES

STEP

ACIS

Parasolid

JT

STL

VRML

X3D

IFC

Introduction

Fig. 1. OBJ format is widespread in the 3D graphics space, so it is often used for digital art assets.
Fig. 1. OBJ format is widespread in the 3D graphics space, so it is often used for digital art assets.

OBJ, also known as Wavefront OBJ, was created in the 1980s by Wavefront Technologies. Its Advanced Visualizer, a 3D animation software package, consisted of a few narrowly focused tools each targeting a specific task - modeling, animation, particle animation, etc. OBJ was among the file formats used to represent the project data and move it between these tools. Later Wavefront Technologies went through a few mergers and acquisitions and Advanced Visualizer no longer exists. But the OBJ, being an open format, ended up widely used and supported by all kinds of 3D graphics software. Now it is effectively a standard 3D format, commonly used for data exchange both by end-users and in automated processing workflows.

Technical details

OBJ is a text format and each line hosts an item definition. Items include things like vertices, texture coordinates, normals, faces, and groups. The items in each category are numbered implicitly starting with 1, making it possible, for example, for face definitions to reference vertices, texture coordinates, and normals. To apply colors, materials, and textures to items, these have to be defined in a separate MTL file, which can be referenced from the OBJ file (notice mtllib on Fig. 2). The MTL file is structured similarly, but the items here are materials and their parameters. Both OBJ and MTL files can contain comments, they are marked with pound (#) character. These are typically used to store the identification of exporting software and also some application-specific information (see that on Fig. 2 the exporter used the comment to define the units the model was written in).

Fig. 2. Left: contents of an OBJ file. Right: contents of an associated MTL file. The OBJ file begins with definition of a group and definitions of two faces inside it. The MTL file defines several colors.
Fig. 2. Left: contents of an OBJ file. Right: contents of an associated MTL file. The OBJ file begins with definition of a group and definitions of two faces inside it. The MTL file defines several colors.

Strengths and weaknesses

Time-proven, simple and universal

OBJ is a mesh format with a solid base. It's got the indexed triangle sets for efficient storage of meshes and preservation of connectivity and line sets for the wireframe geometry. It supports vertex attributes - normals and texture coordinates. It can assign materials (similar to OpenGL's fixed-pipeline materials) and a variety of textures (diffuse, bump, reflection, etc.) to the geometry.

OBJ has a simple structure and is text based, so it's easy to tinker with. It's also easy to create an exporter from scratch and even extend the format with your own types of data in a similar fashion. The simplicity and openness of the format have allowed it to catch on and now it's hard to find software importing or exporting 3D data that doesn't understand OBJ.

Feature limitations

Being an older format, OBJ lacks many features that are now standard in other 3D formats: animation data (skeletons, morph targets), lights, LODs, advanced materials. OBJ doesn't feature any built-in compression/encoding to ensure manageable file sizes on large models that are so common today.

Importantly for CAD data exchange, OBJ lacks proper structure support with nesting and instancing. Instead, OBJ only provides a simple grouping of the geometry, so the conversion of any sufficiently complex CAD model will result in inflated file size due to the explicit copying of instanced parts (see Fig. 3). Another missing feature important for export from CAD is the support for metadata.

Fig. 3. Left: structure of the original IFC model is nested, with levels representing site, building, floors, and elements on each floor. Right: model exported to OBJ lacks the nested structure; all the parts are now siblings.
Fig. 3. Left: structure of the original IFC model is nested, with levels representing site, building, floors, and elements on each floor. Right: model exported to OBJ lacks the nested structure; all the parts are now siblings.

The wide software support also has a few caveats. OBJ capabilities range in popularity and frequency of use from strictly necessary to effectively ignored. So, the support of OBJ varies between software (and often depends on the software's own capabilities) and some data in the file might be ignored. If the OBJ model was written by software that extended the format to store some of its own special data, other software is unlikely to take advantage of this extension. Another important point is that OBJ doesn't specify used length units and up-axis orientation. Different software uses different conventions here and the importers and exporters usually present a list of options for these properties of the model. An automated data processing workflow will have to be wary of the differences in the interfacing software and apply scaling and rotation appropriately.

Summary

Because of the limited scope of data OBJ is not the first recommendation, whether you're working with CAD or 3D graphics. For CAD the biggest issue is lack of nested structure, for 3D graphics - a lack of many types of data that comes standard in other formats. In general, it's better to first consider more feature-rich mesh formats, such as FBX, glTF, or USD. OBJ remains a good fallback option though. It can prove useful when doing software MVPs to save time on the design of data workflow. 

Example model:

Further reading

CAD Exchanger SDK / OBJ converter

...
Anton Larin
Software Engineer

Get the CAD Exchanger Newsletter

From us to your inbox weekly.