3D File Formats

This document is a collection of information on various 3D File Formats and the level of support by Core SDK. While it is not an exhaustive discussion, the advantages and limitations of each format are discussed. Please note that file format specifications are often containing many more elements than are used in practice. For example, the OBJ format can store NURBS surfaces but most importers/exporters do not support it. We try to mark which parts of each format are supported and what to look out for.

Import Support by Core SDK

Yes (supported by our importers), no (not supported by format), not supported (currently not supported by our importers)

Export Support by Core SDK

Yes (supported by our exporters), no (not supported by format), not supported (currently not supported by our exporters)

Detailed Information

Alembic

Alembic (see: project website, wikipedia article) is a fairly new (2011) format and it is specifically designed for geometry exchange in a multi-tool pipeline. As a consequence, it for example bakes animations into per frame key points which provides a robust way to import and play the animation but does not lend itself to further editing.

Support by Core SDK: Basic geometry, no animations, no materials.

COLLADA

COLLADA (see: project website, wikipedia article) has – undisputed at least until Alembic arrived – become the gold standard for exchanging polygonal scene data. It is an XML-based format, can store complex scene graphs with transformations and multi-instancing, multiple U/V-sets, animations and so forth.

We highly recommend COLLADA but there are a couple of downfalls: for one, the COLLADA spec is quite extensive and over the years has kept growing to even to at some point even include parametric surfaces with plans for much more. As a consequence, most importers only support a partial feature set and there are multiple things that one can easily misinterpret on a first read. The result is that quite a number of application actually export incorrect COLLADA files but import them correctly themselves because exporter and importer are misinterpreting the same thing. Even worse, due to the large feature set, most importers/exporters only support a subset and it is hard to tell what “COLLADA support” really means. A lot of programs store their own, application specific information into COLLADA meta tags which makes it hard for other programs to interpret files correctly. To top it off, since the format is XML based, there can be precision problems and the file size is huge plus parsing XML is slower than importing a binary format such as JT.

Support by Core SDK: full polygonal and scene tree support, no animations yet, no parametric surfaces (most exporters don’t support this).

Cosmo 3D Binary

CSB is as a format a bit antiquated. It had its high point as primary format of SGI’s Optimizer and Performer toolkits but lacks many features of modern file format. It can store polygonal data and a scene graph but not much more. Note that there are multiple applications out there that use custom, proprietary modifications of the CSB format to store additional data such as parametric surfaces, texture generation information, advanced material information and so forth but of this actually is not part of the format specification

Support by Core SDK: polygonal information, groups and basic material. No proprietary extensions supported.

FBX

FBX is a proprietary file exchange format owned by Autodesk® that is primarily used for scenes containing polygonal meshes with optional animations. For many users, it has basically become the preferred solution to exchange polygonal data, overshadowing open source formats such as COLLADA and Alembic.

There is no publicly available specification, just the FBX SDK which only exists in compiled form. While the format and API are quite extensive in functionality, they lack some basic things like progress reporting during the import. To sum it up, FBX is a great format from the user-perspective but can cause problems from a developer-perspective.

JT & PLMXML

JT (see: project website, wikipedia article) is a modern 3D CAD Visualization format. It supports advanced format features such as delayed loading of geometry, heavily relies on compression, assembly support and so forth. One major advantage of JT is that starting with V8.0, Siemens published specifications and even got official ISO certification for some specific versions. As such, anyone if free to implement it, although their is also the JT Open consortium which provides toolkits for reading/wrting JT.

There are two disadvantages to JT to keep in mind: It is a still evolving format and just because your CAD application can export the latest version of JT does not mean that another tool might support such a recent version. Also JT contains multiple ways of storing parametric information. For example, the so called XT-Breps are basically the Parasolid format embedded in a JT file which requires vendors to not only import JT but also write a second, also quite complex importer for XT. There is even yet another parametric surface format inside it which is optimized for fast rendering. So while JT is a very powerful, the question is what the programs further down the pipeline can do with it.

A format that is often associated is the PLMXML format. It is used to store assembly information (basically the scene structure without the actual geometry) which reference part files in JT format which contain the actual geometry.

Support by Core SDK: V8.2 (Mesh & Brep) and a basic PLMXML-support only, No XT-Brep or ULP/Libra support yet, V9.5 support is in development.

STereoLithography

STL is a very simple, text based format that can only store triangles without normals or U/V-sets. However, it in recent years has gained popularity since a lot of 3D printer use it as their primary input format.

Support by Core SDK: Full.

Wavefront OBJ & MTL

The .obj format (see: wikipedia article) is sort of the tried and true standard for exchanging polygonal information. It can store triangles, quads and n-gons with normals and texture coordinates. The great advantage of .obj is that it is simple enough that most programs support it and importers cannot make many mistakes. However, it does not support multiple texture coordinate sets and no scene graph structure or assembly structure. No animations are supported. While .obj in principle also supports parametric surfaces such as NURBS, the support of importers for this is so rare that one hardly ever sees a file containing such higher order surfaces.

A separate format that is often associated is the .mtl material library format for storing material information. Again, it is rather limited and only supports the standard Phong lighting model parameters and textures.

Recommendations for 3D File Formats

As a rule of thumb, we recommend using OBJ for purely polygonal data (because it works in every software due to its simplicity), COLLADA for full scenes of polygonal data, IGES for basic CAD data (the format is so old that most programs support it fairly reasonable) and JT for CAD data exchange (probably the most powerful format in the list, but the level of support by 3rd party applications varies).

Supporting Additional Formats

If you are interested in a particular format that we currently don’t support, you might be able to help us add official support for it! There are three main things we need to implement an importer:

1. Specification of the file format
2. A sufficient number of example files
3. Testing & feedback

This also applies for existing importers. For example, there are so many possible combinations of IGES entities within an IGES file, there is a chance you have a file that does not work 100% because it requires an element we never encountered before and therefore did not implement. If you have a problem, please first verify that the file isn’t corrupt by importing it into the application you exported it from. You would be surprised how often we have scene files which are the result of an incorrect export code. Once that is ruled out, feel free to contact our support and arrange something how we can get the problematic file.

Propriety formats

For a number of widely used formats such as .model or .fbx, no specification is publicly available and/or the files are even encrypted. While it is unfortunate for the user, the reasoning from the manufactures perspective is quite sound: writing a specification and maintaining it while the format evolves costs a lot of time and effort plus a “secret” format ties in the user into that manufactures ecosystem of products. There are also companies that take an existing, public format and modify it in a proprietary way to add additional information (e.g. add NURBS-support to CSB which can only handle polygons). Both of these scenarios make it difficult (or next to impossible) to import your data.

While there are companies that specialize in reverse engineering such formats, we are not one of them. If your files are in such a format, check if the source application offers an export format that is suitable for your needs (e.g. IGES, COLLADA). If this is not an option, an alternative is to license a 3rd party conversion library and integrate it into Core SDK via the file I/O extension point. Note however that such libraries can easily cost thousands of Euros per machine they are used on and per format that is used! If you are interested in having us develop such a solution for you, please contact our support.