Not to be confused with the name of the file format of Nintendo 3DS game files.
|3DS Max file|
|Filename extension||.3ds, .max|
|Internet media type||application/x-3ds, image/x-3ds|
|Magic number||4D 4D (hex), MM (ASCII)|
|Developed by||Autodesk Inc.|
|Type of format||3D file formats|
It was the native file format of the old Autodesk 3D Studio DOS (releases 1 to 4), which was popular until its successor (3D Studio MAX 1.0) replaced it in April 1996. Having been around since 1990 (when the first version of 3D Studio DOS was launched), it has grown to become a de facto industry standard for transferring models between 3D programs, or for storing models for 3D resource catalogs (along with OBJ, which is more frequently used as a model archiving file format).
3ds is a binary file format.
The format is based in chunks, where each section of data is embedded in a block that contains a chunk identifier and the length of the data (to provide the location of the next main block), as well as the data itself. This allows parsers to skip chunks they don’t recognize, and allows for extensions to the format.
The chunks form a hierarchical structure, similar to an xml DOM tree. The first two bytes of the chunk are its ID. From that value the parser can identify the chunk and decide whether it will parse it or skip it. The next four bytes contain a little-endian integer that is the length of the chunk, including its data, the length of its sub-blocks and the 6-byte header. The next bytes are the chunk’s data, followed by the sub-chunks, in a structure that may extend to several levels deep.
Below is a list of the most common IDs for chunks, represented in a hierarchical fashion depicting their dependencies:
0x4D4D // Main Chunk
├─ 0x0002 // M3D Version
├─ 0x3D3D // 3D Editor Chunk
│ ├─ 0x4000 // Object Block
│ │ ├─ 0x4100 // Triangular Mesh
│ │ │ ├─ 0x4110 // Vertices List
│ │ │ ├─ 0x4120 // Faces Description
│ │ │ │ ├─ 0x4130 // Faces Material
│ │ │ │ └─ 0x4150 // Smoothing Group List
│ │ │ ├─ 0x4140 // Mapping Coordinates List
│ │ │ └─ 0x4160 // Local Coordinates System
│ │ ├─ 0x4600 // Light
│ │ │ └─ 0x4610 // Spotlight
│ │ └─ 0x4700 // Camera
│ └─ 0xAFFF // Material Block
│ ├─ 0xA000 // Material Name
│ ├─ 0xA010 // Ambient Color
│ ├─ 0xA020 // Diffuse Color
│ ├─ 0xA030 // Specular Color
│ ├─ 0xA200 // Texture Map 1
│ ├─ 0xA230 // Bump Map
│ └─ 0xA220 // Reflection Map
│ │ /* Sub Chunks For Each Map */
│ ├─ 0xA300 // Mapping Filename
│ └─ 0xA351 // Mapping Parameters
└─ 0xB000 // Keyframer Chunk
├─ 0xB002 // Mesh Information Block
├─ 0xB007 // Spot Light Information Block
└─ 0xB008 // Frames (Start and End)
├─ 0xB010 // Object Name
├─ 0xB013 // Object Pivot Point
├─ 0xB020 // Position Track
├─ 0xB021 // Rotation Track
├─ 0xB022 // Scale Track
└─ 0xB030 // Hierarchy Position
It has been pointed out that, despite its popularity, the format may not be the most suitable for 3D data exchange. Some of the disadvantages mentioned are:
- All meshes must bemade of triangles.
- All texture filenames are limited to the3 DOS format.
- The number of vertices and polygons per mesh is limited to65536.
- Accuratevertex normals cannot be stored in the .3ds file. Instead “smoothing groups“[note 1] are used so that the receiving program can recreate a (hopefully good) representation of the vertex normals. This is still a hold-over legacy for many animation programs today which started in the 1980s (3DS MAX, Lightwave and trueSpace still use smoothing groups, and Maya did up to v2.51).
- Object, light and camera names are limited to 10 characters. Material names are limited to 16 characters.
- Directional light sources are not supported.