Engineering Lightweight 3D Formats for Large-Scale AEC Models
As the AEC industry embraces digital transformation, the need to efficiently transfer and render massive 3D models has never been greater.
Whether you’re pushing models to a web viewer, a collaborative BIM platform, or a digital twin pipeline, the challenge is clear: AEC models are geometrically and semantically heavy.
To address this, we must engineer formats that are compact, fast, and scalable, without compromising data fidelity.
This post explores the core engineering principles and advanced techniques behind creating lightweight 3D formats, focusing on their application in AEC workflows.
Meshes vs B-Reps: Choosing the Right Representation
One of the foundational decisions when creating a lightweight format is the choice between mesh-based and boundary representation (B-Rep) geometry:
- Meshes (triangles or quads) are GPU-friendly, universally supported, and highly compressible. Formats like glTF and OBJ rely on triangle meshes and are well-suited for rendering and visualization.
- B-Reps, used in CAD and IFC workflows, define geometry mathematically using surfaces and topological entities. They’re ideal for precision modeling and parametric editing but are heavier to store and transmit.
For lightweight use cases like visualization, mesh geometry is preferred. Converting B-Rep to mesh during export ensures a simpler structure while reducing processing cost downstream.
Binary vs Text-Based Formats
Text-based formats (e.g., COLLADA, OBJ, or IFC-SPF) are human-readable but inefficient. They:
- Take up more space (e.g., ASCII-encoded float vs 4-byte binary float).
- Have slower parsing and loading times.
- Are harder to stream or load incrementally.
Binary formats like glTF (GLB), FlatBuffers, or Protocol Buffers excel by:
- Offering faster I/O through direct memory mapping.
- Supporting structured access via schemas.
- Enabling streaming of parts of the file without loading the entire model.
glTF + binary buffer (GLB) is currently one of the best examples of a compact, real-time optimized 3D format.
Compression: Reducing Size Without Losing Fidelity
Compression is critical when dealing with high-polygon AEC models. Two industry-standard compression methods are:
1. Draco (by Google)
- Compresses mesh geometry (vertices, normals, UVs).
- Achieves 90–95% reduction in size.
- Decoded natively in many WebGL frameworks.
2. Meshopt
- Focuses on geometry reordering and overdraw reduction.
- Compresses using specialized codecs and SIMD-friendly streams.
- Better performance for web streaming.
A practical pipeline might use Draco for geometry and gzip or brotli for JSON metadata. IFC files can also benefit from IFC-ZIP or IFC-JSON + compression. We did a more deeper analysis in our gltf post Here
Instancing: Reuse Geometry, Save Memory
AEC models often include thousands of identical objects (e.g., windows, chairs). Instead of duplicating geometry, use instancing:
- glTF supports
EXT_mesh_gpu_instancingfor reusing geometry with transform offsets. - IFC supports
IfcMappedItem, a similar concept.
Instancing drastically reduces file size and improves GPU performance, especially for repeated parametric elements.
Hashing and Deduplication
Implementing hashing techniques helps deduplicate:
- Materials: Reuse materials with identical properties.
- Meshes: Reuse meshes with same vertex buffer and transform.
- Textures: Identify identical images and avoid storing duplicates.
Use SHA-1 or MD5 hashes on serialized material/mesh data to check for duplication. Many glTF exporters use this to build efficient asset dictionaries.
AEC models often span kilometers, introducing challenges with floating-point precision:
- Store vertices in local space relative to a shared origin per node or building.
- Use quantized coordinates (e.g., 16-bit integers) with dequantization matrices to store vertex data with fewer bytes.
- Avoid absolute world coordinates during runtime rendering.
Also, normalize coordinate systems: unify unit scales (e.g., meters), Z-up vs Y-up, and left-handed vs right-handed to prevent downstream issues.
Schema & Metadata Encoding
AEC models include rich metadata: material properties, construction codes, classifications, or sensor bindings. Encoding metadata efficiently is key:
- Use binary schemas like FlatBuffers or Cap’n Proto instead of JSON.
- Embed references in binary chunks rather than separate files.
- For IFC, use IFC-JSON (early version) with schema pruning or remapping only the needed entities.
Semantic data can be separated from geometry and streamed only when needed.
Streaming and LOD (Level of Detail)
To support massive models (e.g., entire airports or urban districts), formats must allow progressive streaming:
- Split models into tiles or spatial octrees (like 3D Tiles or Unreal World Partition).
- Use multi-resolution levels for far vs near views.
- glTF can store multiple LODs via extensions like
MSFT_lod.
Streaming from cloud storage with range requests (HTTP byte ranges) enables users to explore models without downloading the entire dataset.
Comparison of Common 3D Formats for AEC Use
To understand how the different formats stack up, let’s compare the most widely used 3D data formats and serialization techniques in AEC and real-time applications.
Each format has strengths and weaknesses depending on use case (design, visualization, simulation, data exchange, etc.).
| Format | Type | Best Use Case | Geometry Type | Metadata Support | Binary | Compression | Streaming | Notes |
|---|---|---|---|---|---|---|---|---|
| IFC (STEP) | Text (SPF/EXP) | Interoperability / BIM compliance | B-Rep + Sweeps | ✅ Rich EXPRESS | ❌ | ❌ (ZIP, IFCZIP) | ❌ | ISO standard, very verbose |
| IFC JSON/XML | Text (JSON/XML) | Web-friendly BIM exchange | B-Rep (lossy if simplified) | ✅ | ❌ | ❌ | ❌ | Larger files but more dev-friendly |
| glTF / GLB | Binary / JSON | Web visualization, lightweight 3D | Mesh only | ✅ via extensions | ✅ (GLB) | ✅ (Draco, Meshopt) | ✅ | Excellent for real-time, extensible |
| USD / USDZ | Binary/Text combo | Complex asset pipelines, VFX | Mesh + B-Rep lite | ✅ Schemas + layers | ✅ | Partial (ZLib) | ✅ | Deep layering, metadata composability |
| OBJ | Text | Legacy geometry export | Mesh only | ❌ | ❌ | ❌ | ❌ | Simple but large, lacks normals/UVs sometimes |
| FBX | Binary | Proprietary asset interchange | Mesh, animation | Partial | ✅ | ❌ | ❌ | Controlled by Autodesk, reverse-engineered |
| FlatBuffers | Binary schema | Custom engines & real-time data | Arbitrary (your design) | ✅ strongly typed | ✅ | Depends on implementation | ✅ | Great for custom formats |
| 3D Tiles | Binary + glTF | Massive model tiling & streaming | Mesh | ✅ | ✅ | ✅ (Draco, gzip) | ✅ ✅ ✅ | Excellent for geospatial / city-scale models |
Key Takeaways:
- IFC is the industry standard for structured BIM data, but not ideal for real-time or mobile applications due to verbosity and parsing cost.
- glTF/GLB offers the best trade-off between performance, size, and rendering capabilities—making it ideal for streaming AEC models.
- USD shines in large, composable asset pipelines (used in Pixar and Apple’s AR), but is complex and heavier for simple use cases.
- FlatBuffers and Cap’n Proto are ideal when designing your own compact formats for high-frequency read scenarios.
- 3D Tiles is the go-to format for web-based geospatial model streaming (e.g., entire cities), combining tiling, LOD, and glTF payloads.
Comparison of Common 3D Formats for AEC Use
To understand how the different formats stack up, let’s compare the most widely used 3D data formats and serialization techniques in AEC and real-time applications.
Each format has strengths and weaknesses depending on use case (design, visualization, simulation, data exchange, etc.).
Lighter, Faster, Better: Optimizing 3D for What’s Coming
The future of digital construction lies in real-time, scalable access to 3D data.
Whether you’re building a cloud platform, a game engine-based visualization tool, or a federated BIM system, engineering a lightweight 3D format is key to performance and adoption.
By leveraging proven techniques—binary encoding, mesh compression, instancing, quantization, and schema-based metadata—you can create formats that are not only fast and small, but also flexible and future-ready.
If you’re working on such tools, consider building on open standards like glTF, or hybrid models that merge geometry in glTF with semantics from IFC or JSON schemas, balancing performance and data richness.
In future posts we will explote techniques to improve the loading times in cloud viewers using these formats.
Valentin Noves
I'm a versatile leader with broad exposure to projects and procedures and an in-depth understanding of technology services/product development. I have a tremendous passion for working in teams driven to provide remarkable software development services that disrupt the status quo. I am a creative problem solver who is equally comfortable rolling up my sleeves or leading teams with a make-it-happen attitude.
