3DS (3D Studio) format: legacy 3D mesh interchange — export OSM buildings to .3ds

3DS is a binary 3D format that appeared in 1990 with Autodesk 3D Studio v1.0 for DOS. Technically it's been legacy for years: the native file of 3ds Max (the successor since 1996) is .max, and production pipelines moved to FBX, glTF, and USD. But .3ds still surfaces in three contexts: importing 90s and early-2000s scenes, cheap legacy model libraries (TurboSquid free archives, Cosmo, DAZ Studio props), and universal mesh exchange with CAD/visualization software that understands nothing else. On osm2cdr.ru threeds_exporter.py takes OSM buildings from PostGIS, extrudes them via Building3DExporter, and writes a chunked binary .3ds with automatic mesh splitting to fit the format's 65535-vertex limit per object.

History of 3DS and Autodesk

3DS history starts not with Autodesk but with a group of independent developers. In the late 80s Gary Yost and the Yost Group — a small California team — wrote 3D software for IBM PC under the name 3D Studio. That was extraordinary: professional 3D software at the time ran on SGI workstations for $50K, but Yost packed a renderer with shadows, materials, and animation into a DOS box that worked on regular 286/386 hardware. Autodesk got interested and in 1990 shipped the product under its own brand — 3D Studio Release 1, with Yost Group staying as contract developers.

The 1990 release came with the .3ds format — a binary scene file describing geometry (triangle meshes), materials, cameras, lights, and keyframe animation. By late-80s standards it was a complete production format for commercial visualization: ad spots, TV title sequences, early game assets (Wing Commander, Doom prerender textures, many 3D cutscenes 1991-1995).

By 1996 Autodesk and Yost Group parted ways. Autodesk released a fully rewritten Windows product — 3D Studio Max (later just 3ds Max). The native format changed to .max — closed, versioned, tied to a specific product release. The .3ds format stayed as export-for-compatibility with old DOS scenes and third-party software. By the 2010s the industry moved on to FBX (which Autodesk has owned since 2006 via the Kaydara acquisition) and gradually to glTF / USD.

Today .3ds lives in legacy mode: it gets read to keep 90s archives accessible, and written as a fallback export for software whose plugin loader never learned anything newer.

Inside .3ds — chunked binary

3DS is classic chunked binary in the IFF / RIFF style. The file is made of nested chunks, each with a 6-byte header: 2 bytes uint16 chunk ID and 4 bytes uint32 length (including header and payload). Chunks can contain other chunks recursively — giving a tree scene structure.

Chunk topology: - 0x4D4D MAIN3DS — root container of the file - 0x3D3D EDIT3DS — edit section (the whole static scene) - 0x4000 NAMED_OBJECT — object with an ASCII name (max 12 chars in the strict spec, many implementations ignore the limit) - 0x4100 TRIANGULAR_MESH — mesh of a specific object - 0x4110 POINT_ARRAY — vertex array (3 × float32) - 0x4120 FACE_ARRAY — triangle array (4 × uint16: three vertex indices + flags) - 0xAFFF MATERIAL — material with diffuse/ambient/specular color (3 × uint8 each, 24-bit RGB) - 0xB000 KEYF3DS — keyframe animation section (camera path, object transforms)

The core technical limitation falls right out of the uint16 in FACE_ARRAY: a vertex index is 16 bit, so max 65535 vertices per object. A large OSM neighborhood easily exceeds that — threeds_exporter.py splits the mesh into multiple NAMED_OBJECT entries inside one EDIT3DS, each with its own vertex pool up to 65535. The spec also implies 24-bit RGB colors (8 bits per channel, no alpha, no HDR), ASCII-only object and material names, no quads (everything triangulated by the writer), and flat normals (smoothing groups via a separate optional chunk that many readers ignore).

The format is proprietary but widely reverse-engineered: Martin Reddy's canonical community spec (martinreddy.net/gfx/3d/3DS.spec) and Paul Bourke's docs (paulbourke.net/dataformats/3ds) describe nearly every chunk in the wild. Parsers in Blender, MeshLab, Assimp, and lib3ds are built on top of them.

Use cases in 2026

Archive restoration. A client has a 1990s 3D scene archive — ad spot, early architectural viz, training material. Importing .3ds into modern 3ds Max or Blender is the only way to open it without losing geometry.

Cheap stock models. TurboSquid, Free3D, Archive3D hold huge legacy catalogs in .3ds. Free and low-cost models of furniture, cars, buildings still ship in this format — conversion to modern FBX/glTF happens on the user side.

CAD exchange with old software. Some specialized CAD packages (especially in mechanical engineering, furniture, sign-making) and old SketchUp versions understand only .3ds among 3D formats. For them, exporting OSM buildings to .3ds is the only city geometry import path.

Educational courses. Computer graphics textbooks often use .3ds as the canonical chunked binary example — simple structure, a parser fits in a two-hour lecture. Students write readers as lab assignments.

Strengths and weaknesses

Strengths. Simple chunked structure — a parser is a one-day project. Universal legacy support — practically any 3D software released before 2015 reads .3ds without plugins. Compact binary — 50-100 KB for a typical scene of a thousand triangles. Stability — the format hasn't changed since 1996; a 3D Studio R4 file opens fine in Blender 4.5. Community-side documentation is thorough (Martin Reddy, Paul Bourke).

Weaknesses. Hard 65535-vertex limit per mesh — modern high-poly models require manual or automatic splitting. No PBR materials — only diffuse/ambient/specular as 24-bit RGB, no roughness/metallic/normal maps. No skeletal animation — only keyframe transform (position/rotation/scale). ASCII-only names with 12-char limit in the strict spec — Unicode and long names get lost in strict parsers. No UV textures in the modern sense — textures via filename reference, no embedding inside .3ds. Quads not supported — everything triangulated. Plain flat normals by default — Gouraud shading needs a separate smoothing chunk.

3DS vs FBX vs OBJ vs glTF

All four live in the "3D mesh interchange" zone but solve different jobs:

• 3DS (1990, Autodesk) — legacy. Simple chunked binary, 65k vertex limit, no PBR, no skeletal. For old-software compatibility and archive recovery.
• OBJ (1991, Wavefront) — ASCII text format for static geometry. No vertex count limits, simple parsing, materials via a separate .mtl. Still alive as the "3D ASCII lingua franca" — every renderer reads OBJ.
• COLLADA / DAE (2004, Khronos) — XML-based open standard. Full pipeline: meshes, materials, skeletal, animation, physics. Heavy, verbose, but open.
• FBX (1996, Kaydara → Autodesk 2006) — modern industry standard. Binary, supports skeletal, blend shapes, animation curves, PBR materials. Closed format, but Autodesk's binary SDK is free.
• glTF 2.0 (2015, Khronos) — modern "JPEG for 3D". JSON + binary buffers, web-friendly, native PBR, web and AR support. The future of interactive 3D.

Recommendation: if at all possible — FBX or glTF. Pick .3ds only when the target software understands nothing else, or when working with a legacy archive.

Workflow in OSM2CDR

Exporting an OSM area to .3ds on osm2cdr.ru is one POST request to /api/render:

curl -X POST https://osm2cdr.ru/api/render \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $OSM2CDR_KEY" \
  -d '{
    "bbox": {"min_lon": 37.6173, "min_lat": 55.7558,
             "max_lon": 37.6273, "max_lat": 55.7658},
    "formats": ["3ds"]
  }'

Pipeline inside:

1. Building loading. PostGIS returns building polygons from planet_osm_polygon via ST_AsBinary — WKB fast-path, skipping GeoJSON parsing (10-50× speedup).
2. Calculate height. Per-building height comes from tags in priority order: height (meters) → building:levels × 3.0 m → building-type fallback (apartments 15 m, house 5 m, skyscraper 100 m, default 6 m).
3. Extrusion. Building3DExporter uses trimesh.creation.extrude_polygon to turn each 2D polygon into a prism with triangulated walls + flat roof + flat floor.
4. Auto-split under the 65535 vertex limit. After triangulation the exporter sums total vertices. If it exceeds 65535 — buildings are grouped into multiple NAMED_OBJECT entries (greedy bin-packing), each with its own pool under the limit.
5. File assembly. Nobody writes binary chunks by hand — libraries build the file: threeds_exporter.py in src/worker/renderer/ packs each building group into a trimesh mesh, writes the scene to an intermediate OBJ and converts it to .3ds with the assimp CLI; the fallback, when assimp is unavailable, is a direct trimesh write. In the resulting file the groups sit in the format's usual NAMED_OBJECT → TRIANGULAR_MESH chunks. Default material — beige diffuse RGB (192, 180, 158).

Coordinates — meters, Z-up axis, origin at the south-west corner of the bbox. That matches the 3ds Max convention (Z-up) and simplifies downstream scene work.

FAQ

Does 3DS support textures? Technically — yes, via the MATERIAL chunk (0xAFFF) with a child TEXTURE_MAP chunk (0xA200) referring to an external file by name. But the texture isn't embedded inside .3ds — you need to ship a .bmp / .jpg next to it. Our export currently writes flat-color materials without textures; for textured export use FBX or glTF.

What's the vertex limit? Hard limit — 65535 per single NAMED_OBJECT (uint16 in FACE_ARRAY). At the file level there's no limit — tens of thousands of objects in one .3ds are fine. threeds_exporter.py automatically splits large OSM areas across multiple NAMED_OBJECT entries.

What should I use instead of 3DS in a new project? Depends on target software. For modern DCC apps (Blender, Maya, 3ds Max, Cinema 4D) — FBX (binary, polished) or glTF (open, web-friendly). For static archviz — OBJ still works. For web and AR — glTF 2.0 hands down. For open scientific pipelines — COLLADA.

Can I import 3DS into Blender in 2026? Yes. Blender ships a built-in 3DS importer (enable via Edit → Preferences → Add-ons → Import-Export: 3D Studio (3DS) format). Import is fast and reads geometry and basic materials correctly; keyframe animation is partially lost.

Conclusion

3DS is a format-era. Since 1990 it survived DOS, the move to Windows, the 3D Studio → 3ds Max rebrand, and two 3D industry paradigm shifts (static render → realtime → AR). Today it's chosen rarely and intentionally: for archive, for specific legacy software, or as an educational chunked-binary example. If you have a concrete target that reads only .3ds — our exporter delivers a correct file with auto-split under the 65k limit. In every other case prefer FBX or glTF.

Full parameter list and examples on the format page: /formats/3ds/. Related formats: FBX, OBJ, COLLADA.

Sources

• Wikipedia, .3ds — en.wikipedia.org/wiki/.3ds
• Martin Reddy, 3DS file format spec — martinreddy.net/gfx/3d/3DS.spec
• Paul Bourke, 3DS data format — paulbourke.net/dataformats/3ds
• Wikipedia, Autodesk 3ds Max — en.wikipedia.org/wiki/Autodesk_3ds_Max
• lib3ds (open-source C parser) — code.google.com/archive/p/lib3ds