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 Material Template Library (MTL) 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 Material Template Library (MTL) File Format
Description

The Wavefront Material Template Library (MTL) file is a companion file for one or more Wavefront OBJ files. Like the OBJ format, the MTL format was used and documented by Wavefront Technologies in the 1990s in association with its Advanced Visualizer software. The ASCII-based MTL file describes surface appearance properties to be applied to polygonal facets or freeform curved patches defined in an OBJ file. 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. For example, the definition for a material might specify RGB values for the material's diffuse, ambient, and specular reflectivity, along with other characteristics such as index of refraction and transparency. 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.

An MTL file contains a sequence of material definitions, each beginning with the keyword newmtl and a name for the material. Statements in a material definition consist of a keyword, followed by keyword-specific options, values, or references to supplementary files for use as texture maps. The material definition ends either at the end of the file or at the next newmtl statement. The statements that define the characteristics of the material can be in any order. An example of a material definition is:

newmtl Wood
Ka 1.000000 1.000000 1.000000
Kd 0.640000 0.640000 0.640000
Ks 0.500000 0.500000 0.500000
Ns 96.078431
Ni 1.000000
d 1.000000
illum 0
map_Kd woodtexture.jpg

The example uses the following keywords:

  • Ka: specifies ambient color, to account for light that is scattered about the entire scene [see Wikipedia entry for Phong Reflection Model] using values between 0 and 1 for the RGB components.
  • Kd: specifies diffuse color, which typically contributes most of the color to an object [see Wikipedia entry for Diffuse Reflection]. In this example, Kd represents a grey color, which will get modified by a colored texture map specified in the map_Kd statement
  • Ks: specifies specular color, the color seen where the surface is shiny and mirror-like [see Wikipedia entry for Specular Reflection].
  • Ns: defines the focus of specular highlights in the material. Ns values normally range from 0 to 1000, with a high value resulting in a tight, concentrated highlight.
  • Ni: defines the optical density (aka index of refraction) in the current material. The values can range from 0.001 to 10. A value of 1.0 means that light does not bend as it passes through an object.
  • d: specifies a factor for dissolve, how much this material dissolves into the background. A factor of 1.0 is fully opaque. A factor of 0.0 is completely transparent.
  • illum: specifies an illumination model, using a numeric value. See Notes below for more detail on the illum keyword. The value 0 represents the simplest illumination model, relying on the Kd for the material modified by a texture map specified in a map_Kd statement if present. The compilers of this resource believe that the choice of illumination model is irrelevant for 3D printing use and is ignored on import by some software applications. For example, the MTL Loader in the threejs Javascript library appears to ignore illum statements. Comments welcome.
  • map_Kd: specifies a color texture file to be applied to the diffuse reflectivity of the material. During rendering, map_Kd values are multiplied by the Kd values to derive the RGB components.

The keywords in the MTL example above are very commonly used. The MTL specification, as published in 1995, includes a substantial number of options that are typically not supported in today's software. Some look to have been specific to Advanced Visualizer and not to have been widely used for exchange between different 3D modeling applications or for 3D printing. See Notes below for more detail on features in the MTL specification that are unlikely to be supported as of 2019.

Another potential source of interoperability problems with MTL files is the addition of new keywords for proprietary use or to support new approaches for 3D rendering. In 2015, additional keywords were proposed by Exocortex to support the "physically based rendering" approach being adopted for more realistic rendering of surfaces for 3D objects in games and for special effects in movies. The compilers of this resource have been unable to determine the degree to which the new keywords proposed are supported in 3D software applications. Comments welcome.

Despite shortcomings, the OBJ format and its companion MTL format are widely used for 3D printing and for interchange of 3D models between software applications. See Adoption in Sustainability Factors below.

Relationship to other formats
    Used by OBJ, Wavefront OBJ File Format. The MTL file provides color and texture definitions for surface objects (polygonal facets and freeform patches) as defined in an OBJ file.

Local use Explanation of format description terms

LC experience or existing holdings See Wavefront OBJ.
LC preference See Wavefront OBJ.

Sustainability factors Explanation of format description terms

Disclosure The MTL format was developed by Wavefront Technologies around 1990 and the format was openly documented in a manual for version 3 of the Advanced Visualizer software sold by Wavefront. See also Wavefront OBJ.
    Documentation MTL Material Format, excerpt from File Formats, Version 4.2 October 1995 by Wavefront Technologies.
Adoption

The OBJ format is very widely used for 3D printing, particularly for multi-color 3D printing with the colors specified in a companion MTL file. See, for example, STL vs. OBJ: Which Should You Use? [for 3D printing], which states, " two file formats stand supreme: STL and OBJ."

Although most CAD/CAM and 3D modeling software can import OBJ files, not all can successfully import all MTL files. See Notes below for interoperability issues that may affect adoption.

The OBJ and MTL formats have been proposed by Working Group 17 for the Digital Imaging and Communications in Medicine (DICOM) standard as the next 3D model format to be supported for encapsulation in a DICOM wrapper. See slides on Supplement 208 Extension of DICOM Encapsulation of 3D Manufacturing Models from March 2019.

The compilers of this resource are not aware of any use of the MTL format other than in association with Wavefront OBJ files. Comments welcome.

    Licensing and patents See Wavefront OBJ.
Transparency As a plain text ASCII file, an MTL file can be viewed and modified using a text editor.
Self-documentation

No support for embedded metadata. According to MTL Files Material Definitions for OBJ Files by John Burkardt, lines starting with # represent comments. Some tools that export MTL files add comments to identify the tool and version that were used to create the MTL file.

Accessibility Features

Accessibility features for 3D model formats include audio descriptions for screen readers to enable user interactivity events such as object selection, rotation and zoom, alt text for image forms, color contrast definition as well as caption and subtitle support.

MTL, like OBJ, has limited direct support, however, other than data stored as plain text which makes it more available to translate for screen readers. Some additional functionality may be supported with software implementation.

External dependencies May refer to supplementary texture map files. Most software expects these files to be stored in the same directory as the MTL file.
Technical protection considerations No concerns.

Quality and functionality factors Explanation of format description terms

Other
3D Model Geometry See Wavefront OBJ.
3D Model Appearance

An MTL file is entirely concerned with characteristics of a surface material that control the appearance of a 3D object. Keywords/statements in the MTL specification are based on the Phong Reflection Model.

A proposal to extend the MTL format with statements to express the Physically Based Rendering (PBR) model was made in 2015 by Exocortex. Some of the new keywords from the proposal can be found in MTL files available online. Some are also mentioned in documentation and help files for some applications. See Notes below on Extensions to MTL for examples. The compilers of this resource have not determined the degree to which the proposed extension is in wide use in its entirety. Comments welcome.

3D Model Scene See Wavefront OBJ.
3D Model Animation See Wavefront OBJ.

File type signifiers and format identifiers Explanation of format description terms

Tag Value Note
Filename extension mtl
Defined in specification. See also IANA registration from 2020.
Internet Media Type model/mtl
See IANA registration from 2020.
Magic numbers ASCII: newmtl
Hex: 6E65776D746C
There may be white space or comments before the first newmtl statement.
Other See note.  NARA File Format Preservation Plan ID has no corresponding entry as of February 2025.
Pronom PUID fmt/1211
See http://www.nationalarchives.gov.uk/pronom/fmt/1211.
Wikidata Title ID Q20965861
See https://www.wikidata.org/wiki/Q20965861.

Notes Explanation of format description terms

General

Features in the MTL specification not typically supported in 2019: The specification from the 1990s, originally tailored for use with a particular 3D modeling and visualization system, includes a substantial number of options that are probably not supported in today's software and are not applicable for 3D printing. For example, the specification allows the characteristics involving color to be specified in one of three ways, based on RGB, CIE XYZ, or a spectral curve in a format developed by Wavefront Technologies with a .rfl extension. The compilers of this resource have not located documentation for the .rfl format and have found software utilities that only support the use of RGB. [See, for example, the mtl.jl module of Wavefront Obj Importer.]

In addition, some of the formats listed in the specification as usable as texture maps are not recognized today. Support is not typically available for supplementary files with the following extensions: .mpc, .mps, .mpb, .cxc, .cxs, and .cxb. [See, for example, NGLParserOBJ module of NinevehGL.] Common image formats, such as JPEG, PNG, and BMP can be used for texture maps. Some tools accept images in the TGA format that was common when the MTL format was introduced; others convert TGA images losslessly to PNG on import (e.g., Sketchfab) or require that TGA texture maps be converted before import.

The illum statement specifies the illumination model to use for the material, using a set of codes for associated lighting and shading effects. Each code (from 0-10 in the specification) corresponds to a set of equations that would have been applied in Advanced Visualizer taking into account the interaction of light sources with object surfaces to determine the displayed color. From a mathematical perspective, they correspond to different Bidirectional reflectance distribution functions. All values other than 0 are designed to take account of sources of light when the shapes defined in an OBJ file are viewed in a context that incorporates specifications for lighting. However, an OBJ file describes only the surface geometry of an object and does not incorporate any elements related to light sources. Only a few of the illum values seem to be found in MTL files in practice to judge from resources online. For example, the abbreviated version of the MTL specification at Alias/WaveFront Material (.mtl) File Format describes only the first three options.

  • illum 0: a constant color illumination model, using the Kd for the material
  • illum 1: a diffuse illumination model using Lambertian shading, taking into account Ka, Kd, the intensity and position of each light source and the angle at which it strikes the surface.
  • illum 2: a diffuse and specular illumination model using Lambertian shading and Blinn's interpretation of Phong's specular illumination model, taking into account Ka, Kd, Ks, and the intensity and position of each light source and the angle at which it strikes the surface.

The other values listed in the specification for illum probably reflect choices that could be made by a user of Advanced Visualizer. According to Editing MTL files for color Clara.io viewing, a post from 2014, Clara.io is only interested in illum values of 0 and 1, while Maya always uses 4 on export. It seems probable that the illum parameter is ignored (i.e., assumed to be 0) for 3D printing applications.

Extensions to MTL to support new techniques for realistic rendering: The color keywords in the MTL specification that affect color shading are based on the Phong reflection model, developed by Bui Tuong Phong at the University of Utah, who described it in his 1973 Ph.D. dissertation. The model describes the way a surface reflects light as a combination of the diffuse reflectivity (Kd) of a rough surface, which typically contributes most of the color to an object, with the specular reflectivity (Ks) of a shiny surface, which yields highlights. The model also includes an ambient reflectivity (Ka) term to account for the small amount of light that is scattered about the entire scene. In recent years a model known as Physically Based Rendering (PBR) has become popular. See Wikipedia entry on Physically-Based Rendering and Physically-Based Shading at Disney, a paper from 2012. In 2015, a proposal to extend the MTL format with statements to express the PBR model was made by Exocortex and support for the new keywords added to the Clara.io product. Among the keywords proposed as new were Ke and map_Ke for emissive color equivalents to Kd and map_Kd. These two keywords may have been in use since before the Exocortex proposal, since they appear in the OBJ material section in the Python Computer Graphics Kit 2.0.0 documentation, which has a copyright date of 2009. Another keyword introduced as new in the Exocortex proposal is norm. In September 2019, the MTL loader for the three.js Javascript library recognizes Ke, map_Ke, and norm, but not the other keywords in the Exocortex proposal. Meanwhile, the Wikipedia description of MTL indicates that Microsoft has also introduced two keywords for use in the DirectX toolkit installed with recent versions of Windows.

Other potential interoperability issues: According to the Interchange section of the Lightwave 3D reference manual, "OBJs textured with image maps or numeric values in other packages will come in textured but nodal or procedural textures will not translate in either direction. Autodesk’s Maya and Max reverse diffuse and ambient, so the default behavior of LightWave now is to reverse Ka & Kd for OBJ export. If you find that textures are being transferred incorrectly, try switching this off in the Layout Preferences OBJ Tab or Modeler Preferences OBJ Tab."

According to Supported file types | 3D models | Exporting models from Dimension, "OBJ’s companion MTL file should preserve the look of your Dimension/Substance materials almost entirely, but any customization or interactivity is lost. Dimension's decals are "baked" into the textures of the underlying material which can decrease the resolution of the material. Not every 3D program supports loading MTLs to the same extent, so your exported object may look different depending on the program you take it to. Where possible, standard MTL property labels are used, but because of the limitation of the format, some uncommon properties will only load properly into Dimension."

History

Although the MTL format was documented by 1995, the date of its introduction is not known to the compilers of this resource. Documentation for the Wavefront OBJ Importer by Okino suggests 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.


Format specifications Explanation of format description terms


Useful references

URLs


Last Updated: 02/20/2025