Sustainability of Digital Formats: Planning for Library of Congress Collections

Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact
Format Description Categories >> Browse Alphabetical List

Wavefront OBJ File Format

>> Back
Table of Contents
Format Description Properties Explanation of format description terms

Identification and description Explanation of format description terms

Full name Wavefront OBJ File Format
Description

The Wavefront OBJ format is a format for defining the 3D geometry for the surface of one or more objects. The format was first used by Wavefront Technologies around 1990 and a specification was published to encourage interoperability. The introduction to the specification stated, "Object files define the geometry and other properties for objects in Wavefront’s Advanced Visualizer. Object files can also be used to transfer geometric data back and forth between the Advanced Visualizer and other applications." Since the mid 1990s, the ASCII-based format has been treated as a vendor-neutral format, referred to as 'Wavefront OBJ," "Alias/Wavefront OBJ," or simply "OBJ." In 2020, the format remains widely used, particularly for 3D printing of objects in multiple colors. Note: The original specification for the OBJ file employs an associated Wavefront Material Template Library (MTL) file to define both colors and textures. Textures and colors specified by name in an MTL file are invoked in the OBJ file. See 3D Model Appearance factor below.

The OBJ file format supports definition of the geometry for object surfaces using polygonal meshes or using freeform curves and surfaces. From a logical perspective, the central concept in an OBJ model is the "element." The specification lists the following as elements: point (p), line (l), face (f), curve (curv), 2D curve (curv2), and surface (surf). Elements are constructed from vertices; the vertices must be listed first in the file, so that the elements can refer to them by number, using the order in which they occur in the file. Elements can optionally be organized into groups for convenience or to guide rendering applications.

An OBJ file has a simple physical structure, consisting of lines that start with keywords. Following each keyword, appropriate options and values are specified. Lines beginning with # are comments. Long lines can be broken up, using a backslash (\) character at the end of lines to be continued. According to the Wavefront OBJ File Format Summary in the Encyclopedia of Graphics File Formats, 2nd Edition, "The most commonly encountered OBJ files contain only polygonal faces. To describe a polygon, the file first describes each point [vertex] with the "v" keyword, then describes the face with the "f" keyword. The line of a face command contains the enumerations of the points in the face, as 1-based indices into the list of points, in the order they occurred in the file." [Note: A 1-based index means that the count of vertices begins at 1, rather than 0.] The description of Alias/WaveFront Object (.obj) File Format provided by Donald H. House for a course in computer graphics is a useful introduction to the keywords used for polygonal meshes; these keywords are supported by most applications that claim to support the OBJ format. Not all 3D software applications can handle freeform surfaces, which are defined using mathematical equations. Of those that can, support may be limited to the non-uniform rational basis spline (NURBS) model, although the OBJ specification allows for a variety of models.

Here is a simple example of an OBJ file, for a cube, taken from the specification

v 0.000000 2.000000 2.000000
v 0.000000 0.000000 2.000000
v 2.000000 0.000000 2.000000
v 2.000000 2.000000 2.000000
v 0.000000 2.000000 0.000000
v 0.000000 0.000000 0.000000
v 2.000000 0.000000 0.000000
v 2.000000 2.000000 0.000000
f 1 2 3 4
f 8 7 6 5
f 4 3 7 8
f 5 1 4 8
f 5 6 2 1
f 2 6 7 3

Many more examples can be found at John Burkardt's page on the OBJ format, for example, for a Mini Cooper.

Vertices for a polygonal model in an OBJ file can have three types of vertex data. See Wikipedia entry for Vertex (computer graphics).

  • v: Defines the position of the vertex in three dimensions (x,y,z). Three floating point numbers. Required.
  • vn: Vertex normal, a directional vector associated with a vertex, used to facilitate smooth shading. Three floating point numbers. Optional.
  • vt: Texture coordinates, also known as UV coordinates. Typically two floating point numbers (u, v). These coordinates are used during rendering to determine how to paint the three-dimensional surface with pixels from a 2D texture map, e.g. an image in a format such as PNG. Optional.

For information on the keywords and options associated with freeform surface elements, see the specification and Useful References below.

OBJ files that contain only face elements and the associated vertex data are widely supported by 3D software applications, for import and for export. Nevertheless, there can be interoperability problems associated with applying colors and textures using an associated MTL file. An OBJ file refers to the MTL file in an mtllib declaration and definitions for objects (polygonal or freeform) within the OBJ file can refer to a particular named material definition with a usemtl statement. Some applications simply do not support the MTL files. The original Advanced Visualizer application required the MTL file to be in the same directory as the OBJ file and any texture map files also to be in the same directory. Some applications accept paths to files in other directories and others export the component files in separate directories and users have to move them before they can be successfully employed. Another potential source of interoperability problems with MTL files is the use of keywords not defined in the original MTL specification for proprietary use or to support new approaches for 3D rendering. For more details, see MTL.

A convention for representing colors in an OBJ model without using an MTL file is supported by several applications. This convention supports a technique, known as per-vertex coloring, in which a color is associated with each vertex and pixels on a mesh face are colored by interpolation based on distance from the face vertices. This approach is of particular value for certain applications. When 3D models are derived by scanning (e.g., for a pathology specimen) or photogrammetry (e.g. for a 3D cultural heritage artifact), it is feasible to generate a single file which includes accurate color information. Another situation where this approach is valuable is for models that use basic colors to identify parts of a design model, or convey other information using artificial colors, for example, for an anatomical model. Having a single file can simplify workflows and storage for situations where texture maps are not needed. For more detail on the convention and its support in applications, see Note on per-vertex coloring below.

Production phase The OBJ format can be an initial-state format, created by a 3D scanning process. It often serves as a middle-state format, created as output from software that supports 3D design. An OBJ model will often be input to a 3D printing process or to more advanced 3D modeling software to include in a 3D scene or animation. Models are often shared for re-use in the OBJ format.
Relationship to other formats
    May have component MTL, Wavefront Material Template Library (MTL) File Format. An associated MTL file can define colors and texture for applying to the surface of the objects whose surface geometry is defined in the OBJ file.

Local use Explanation of format description terms

LC experience or existing holdings The OBJ format has been used in a pilot workflow for 3D capture of artifacts from the Kislak Collection.
LC preference The Library of Congress Recommended Formats Statement (RFS) includes OBJ as an acceptable format for Scanned 3D Objects (output from photogrammetry scanning.

Sustainability factors Explanation of format description terms

Disclosure

The OBJ format was developed by Wavefront Technologies around 1990 and the format was openly documented before 1995 as Appendix B1 of a manual for version 3 of the Advanced Visualizer software sold by Wavefront. This appendix has been made available in several places on the Internet and the Wikipedia entry for Wavefront .obj file states, "The file format is open and has been adopted by other 3D graphics application vendors." The originators were indeed happy to share the specification and the format is indeed supported in almost all CAD software. However, from a legal standpoint, the specification is probably proprietary to Autodesk; see Notes on History and Useful References below for details on the chain of mergers and acquisitions.

Note that a binary equivalent, with a .mod extension, is mentioned in the introduction to the specification but was not documented.

    Documentation A specification for the Wavefront OBJ format was published in Appendix B1 of a manual for The Advanced Visualizer in the early 1990s. See Format Specifications below for additional copies of the same appendix.
Adoption

The Wavefront OBJ format is widely used for 3D printing. See, for example, question 40 in 3D Printing Guide: Basics and Most Common 3D File Formats from All3DP; and Working in 3D: Designing and Saving for 3D Printing, a guide from Auraria Library. According to OBJ File Format – Simply Explained for CAD and 3D Printing from All3DP, OBJ has wide export and import support among CAD software and in recent years, has become "the de facto file format for multi-color 3D printing because the otherwise standard 3D printing format STL does not support color and texture information."

Most CAD/CAM and 3D design applications can import and export polygonal meshes in the OBJ format. The compilers of this resource have not determined which widely used 3D software applications can work with freeform surfaces. See the 3D Model Geometry factor below for more detail.

As of 2019, with 3D models in wide use for video games, online product information, 3D printing, and in archaeology, medicine, and other professional disciplines, the simple, openly documented formats developed over 20 years ago, such as STL, OBJ, and PLY are supported in new contexts. For example, recent versions of the Windows and Mac operating systems come with basic tools that can render 3D files in a small number of formats, including the OBJ format. Windows 10 includes Paint 3D, which can open files in PLY, STL, OBJ, 3MF, FBX, and GLB (the binary variant of glTF_2_0) formats. In April 2017, Microsoft announced support for 3D formats (3MF, FBX, OBJ, PLY, STL) in OneDrive for Business. The version of Preview shipped with versions of Mac OS since 10.11 (El Capitan) has also been able to render 3D models in a number of formats. For example, Preview in Mac OS 10.14 (Mojave) supports PLY, OBJ, STL, USD (Universal Scene Description), ABC (Alembic), and possibly more.

3D modeling applications and conversion tools that can import, export, or convert OBJ files include: MeshLab, a widely used open-source software system for manipulating 3D mesh models, maintained by the Visual Computing Lab of ISTI-CNR; Blender, another popular free and open-source 3D creation suite, supported by the Blender Foundation, an independent non-profit public benefit corporation, established in the Netherlands; Mathematica; Rhino; Aspose.3D for Java; Assimp (Open Asset Import Library); quick3D and HOOPS Exchange SDK. Products from Autodesk that support the OBJ format include: Alias; Maya (import); Maya (export); Maya LT; and 3DS Max.

Recently, GIS applications have begun to integrate 3D support. Models in the OBJ format can be used in Esri's City Engine and via some extensions to ArcGIS Pro: ArcGIS Data Interoperability and 3D Analyst. The Feature Manipulation Engine (FME), which is widely used with GIS products, offers support for importing or converting the OBJ format.

Examples of software tools that have been developed specifically to read and write files in the OBJ format include: PyWavefront in Python; OBJloader.js in javascript, part of threejs toolkit; and file-format-wavefront for .NET.

Cultural heritage institutions and archaeologists have used the Wavefront OBJ format when scanning 3D artifacts from their sites or collections. However, many museums also use 3D formats that offer more advanced features. For example, the British Museum offers a queen from the Lewis chessmen for download from SketchFab in STL and OBJ, but also in glTF. SketchFab is used by many museums for making 3D models available. Wavefront OBJ is supported for uploading models to SketchFab and is one of the preferred formats listed at Supported 3D File Formats. The UK Archaeology Data Service lists the Wavefront OBJ format in a table of "common" formats, and describes it as "suitable for preservation."

Digital Imaging and Remote Sensing Image Generation (DIRSIG) is a specialized system that can be used to test image system designs, to create test imagery for evaluating image exploitation algorithms and for creating data for training image analysts. DIRSIG software has been developed over the course of over two decades for use by NSF, NASA, DoD and Intelligence community contractors and by universities doing research for these organizations. In addition to a custom format, the software will read the Alias/Wavefront OBJ file format directly. Other geometry formats must be exported to the Alias OBJ format for importation into a DIRSIG scene. DIRSIG support is only for meshes with faces with three or four vertices. See Alias/Wavefront OBJ File Format |Feature Support in DIRSIG. Another specialized system that uses OBJ and MTL files is the Channel Annotation Package (CHAP), a research tool for "functional annotation of novel ion channel structures that provides information on the biophysical properties of the ion permeation pathway by utilising molecular dynamics simulations." See Contents of the OBJ and MTL Output Files.

A recent development is the approval in early 2020 by Working Group 17 for the Digital Imaging and Communications in Medicine (DICOM) standard, of Supplement 208: DICOM Encapsulation of OBJ Models for 3D Manufacturing and Virtual Reality. See slides in Supplement 208 from 2019, and DICOM Supplement Overview.

Faced with interoperability problems in getting some 3D software to import the OBJ and MTL files together and yield an appropriate rendering, some users may choose a workflow that avoids the OBJ format. For more on sources of interoperability problems, see MTL.

    Licensing and patents

There was no formal statement by Wavefront Technologies or by any of its succeeding corporate entities that the OBJ format may be used without a license. However, the original publication included the informal statement, "The .obj appendix is for those who want to use the .obj format to translate geometric data from other software applications to Wavefront products. It also provides information for Advanced Visualizer users who want detailed information on the Wavefront .obj file format." Comments welcome.

Transparency

The OBJ format is in plain text, and thus easy to view with basic editing tools. Use of freeform curves and surfaces rather than polygonal facets will yield statements that may be hard to interpret without an understanding of the mathematics that enables efficient representation and rendering of free-form surface patches. See Useful References below.

Self-documentation There is no support for embedding structured metadata in an OBJ file. Comments, indicated by lines with a leading # character, can be included anywhere in the file.
External dependencies For full rendering with color and textures as intended, an OBJ file may need one or more associated Material Template Library (MTL) files and supplementary texture files.
Technical protection considerations The OBJ format has no internal capabilities for encryption or other technical protection.

Quality and functionality factors Explanation of format description terms

Other
3D Model Geometry

The OBJ file format can encode surface geometry of a 3D model, using a polygonal mesh and/or freeform geometry using any of a number of techniques to define curved surface patches: basis matrix; Bezier; B-spline; Cardinal spline; or Taylor expansion. See section on Freeform curve and surface types at page 65 of the specification for more detail. See also Useful References below for some links to explanations of the underlying mathematics.

The compilers of this resource have been unable to determine how widely the more complex freeform modeling options are in use in OBJ files and how widely the techniques are supported in CAD software. The Wikipedia entry for Wavefront .obj files states, "The most common elements are geometric vertices, texture coordinates, vertex normals and polygonal faces." Comments welcome.

OBJ File Format – Simply Explained for CAD and 3D Printing from All3DP states that in general, the most common freeform surface technique in use is NURBS (Non-Uniform Rational B-Spline), a particular variant of B-spline that the OBJ format does support. Alias from Autodesk does appear to handle freeform surfaces. However, the help for 3DS Max, also from Autodesk only mentions the use of meshes on import. Blender appears to have partial support for curved surfaces defined by NURBS, but converts them to meshes on output. Another example of limited freeform curve support is in NURBS-Python (geomdl), a cross-platform, object-oriented B-Spline and NURBS library written in Python, which can output OBJ files.

3D Model Appearance

Appearance characteristics such as color and texture can be defined in companion Material Template Library (MTL) files. The MTL file is a "library" that can contain one or more named material definitions, each of which can specify color, texture, and reflection characteristics. An OBJ file refers to the MTL file in an mtllib declaration and definitions for objects (polygonal or freeform) within the OBJ file can refer to a particular named material definition with a usemtl statement.

The original specification for OBJ had no support for per-vertex color information. However, a convention has emerged, as described in the Geometric vertex section in the Wikipedia entry for the OBJ file format. For more detail on the convention and its support in applications, see Note on per-vertex coloring below.

3D Model Scene An OBJ file can define several objects, but not a scene incorporating lighting positions or pre-determined viewing positions.
3D Model Animation The OBJ format does not support pre-determined animation sequences or skeleton structures (assemblies of bones and joints). A 3D viewer that can render models in the OBJ format will allow rotation and zooming.

File type signifiers and format identifiers Explanation of format description terms

Tag Value Note
Filename extension obj
Defined in specification. See also IANA registration of 2020.
Internet Media Type model/obj
See IANA registration of 2020.
Pronom PUID fmt/1210
See http://www.nationalarchives.gov.uk/pronom/fmt/1210.
Wikidata Title ID Q2119595
See https://www.wikidata.org/wiki/Q2119595.

Notes Explanation of format description terms

General

3D Model Characteristics: The quality and functionality factors used above are based on an analysis from 2008 in An Overview of 3D Data Content, File Formats and Viewers, a technical report (ISDA08-002) from the National Center for Supercomputing Applications (NCSA). According to this analysis, the key aspects of a 3D model are: geometry, appearance, scene, and animation. For brief descriptions of these factors, see the table for 3D model formats under Quality and functionality factors. The descriptions there are drawn from the 2008 report and from 2019 Most Common 3D File Formats (an article from All3DP), which includes the OBJ format and uses the same factors to distinguish the capabilities of formats.

All 3D formats support some method for representing the geometry (the shape) of an object; support for other aspects is optional depending on the primary use of the format. Table 3 in the 2008 report, An Overview of 3D Data Content, File Formats and Viewers, compares nine popular 3D formats in use in 2008, including OBJ, based on these four aspects of 3D models.

Potential interoperability issues: The Wikipedia entry for the Wavefront .obj file notes that "OBJ files, due to their list structure, are able to reference vertices, normals, etc. either by their absolute position (1 represents the first defined vertex, N representing the Nth defined vertex), or by their relative position (-1 represents the latest defined vertex). However, not all software supports the latter approach, and conversely some software inherently writes only the latter form (due to the convenience of appending elements without needing to recalculate vertex offsets, etc.), leading to occasional incompatibilities."

Documentation for the Wavefront OBJ Importer by Okino indicates that before the introduction of the MTL format, an earlier method for applying a texture map to a surface object was via a usemap statement in the OBJ file. The Okino importer would create equivalent MTL-style definitions for any texture maps referenced in this way. Comments welcome.

Another source of potential interoperability issues is in associated MTL files. Some extensions to the MTL format have been introduced by software vendors or open source projects based on developments in computer graphics techniques for rendering surfaces. For example, in 2015, Exocortex proposed Extending Wavefront MTL for Physically-Based Rendering through adding new statements, e.g., for defining roughness and clearcoat thickness. See MTL for more details.

Per-vertex coloring in OBJ format: The per-vertex coloring technique, which is supported in many 3D modeling applications, associates a color (usually based on RGB) with each vertex and renders colors for the pixels on a mesh face by interpolation based on distance from the face vertices. See On the storage of Color in meshes and What is a vertex color?.

The Geometric vertex section in the Wikipedia entry for the OBJ file format describes a convention for storing colors for vertices in an OBJ model, listing color values immediately following the vertex coordinates. Three colors, in RGB order, are expressed as values in the range 0 to 1. For example, “v 1220.094482 -572.500000 177.713943 0.984314 0.000060 0.000050” demonstrates a vertex with color information near true red. Note that this convention allows coloring (but not texturing) of a 3D model without the need for an associated MTL file. There are advantages and disadvantages of using per-vertex colors depending on context and intended use. In one context, A game of Tricks II – Vertex Color explains how vertex colors can improve performance in video games. For a discussion of the complex choice between using per-vertex colors and texture mapping in the context of a cultural heritage artifact, see the tutorial video MeshLab Basics: Color encoding. Having the entire model in a single file can simplify workflows and storage organization, but consideration must be given to the importance of geometric precision and color accuracy, and effects on file size and computational efficiency for rendering and manipulation in the intended use. One example from the medical field where per-vertex coloring can be advantageous is for 3D scanning of a pathology specimen; the scanning operation can capture surface color information. Per-vertex coloring can also be useful for applying discrete colors or identifiers via color information on an anatomical model or a model for an assemply of parts. Comments welcome.

Support for this convention for per-vertex coloring in the OBJ file format is provided by several applications, including Meshlab (see video on MeshLab Basics: Color encoding), Unity ProBuilder, Sketchfab, the Open Asset Import Library (Assimp), and the threejs library. See How to display and use Vertex Color from OBJ model for an informative discussion and evidence of support in Assimp. Versions of Adobe Photoshop since 2018 have been found to recognize colors on importing OBJ files using this convention for per-vertex colors. The Preview app on Mac OS also recognizes and renders the colors appropriately. See Useful References below for links to resources about per-vertex coloring, also termed "color per vertex" (CPV). Note that the convention described here is not the only mechanism that has been implemented to encode per-vertex colors in an OBJ file, but it is the most widely supported. Comments welcome.

History

The OBJ format was developed by Wavefront Technologies for the Visualizer products that it developed in the late 1980s and early 1990s. The compilers of this resource have not been able to determine an exact date for the first use of the format. The company history reveals that in 1988, Wavefront released its first desktop product, known as Personal Visualizer, for the Silicon Graphics (SGI) workstation. In 1989, came the Data Visualizer, intended for industrial design applications. Since a Programmer's Project Guide for the Advanced Visualizer was published by Wavefront Technologies in 1990, The Advanced Visualizer (TAV) software came out soon after. The origin of the specification that is widely found is Appendix B of a manual for Advanced Visualizer 3.0; and includes an implication that the OBJ format had been used in the previous version, but not documented. This specification indicated that "The curve and surface extensions to the .obj file format were developed in conjunction with mental images GmbH. Berlin, Germany, as part of a joint development project to incorporate free-form surfaces into Wavefront’s Advanced Visualizer." By 1995, the Advanced Visualizer User's Guide, Version 4.2 was published. By 1998, a user guide for scientific visualization on workstations at Georgia Tech indicated that version 4.3 of the Advanced Visualizer was installed, soon to be replaced by the first version of the successor product, Maya, which also used the OBJ format.

On February 7, 1995, Silicon Graphics had announced that it would purchase Wavefront Technologies and Alias Research. SGI merged the two companies to create Alias|Wavefront, later simply Alias. In 2004, SGI sold Alias to a private equity firm, Accel-KKR, with the support of Alias management. See Alias | About: History. In 2006, Alias was acquired by Autodesk. See Wikipedia entry for Accel-KKR and a news release from Autodesk.


Format specifications Explanation of format description terms


Useful references

URLs


Last Updated: 09/11/2020