GLB for Web & AR: A “Compiled” BIM Deliverable

glTF/GLB isn’t a smaller BIM — it’s a runtime asset meant to load fast and render reliably across browsers and phones. The key choice isn’t “can we export,” but what trade-offs you accept: direct exports are quick, IFC-based pipelines are often more repeatable, and both force decisions on tessellation, level of detail, and coordinate handling that can make the difference between smooth playback and an unshippable file.

The payoff comes from being intentional: preserve element identity if you need interaction, expect BIM materials to be interpreted into real-time PBR rather than preserved perfectly, and treat GLB like a build artifact with validation and viewer testing — especially when using compression.

Common Questions

Q: If GLB is “runtime-first,” what should stay in BIM/IFC and what can move to GLB? A: Keep compliance, coordination, and authoritative data in BIM/IFC. Push to GLB what you need to see and experience: geometry, basic categories, and only the metadata required for selection and simple filtering.

Q: When would you choose a direct Revit → GLB export over an IFC → GLB pipeline? A: Direct export is great for speed and “what-you-see” fidelity from a curated 3D view. IFC → GLB is better when you want a repeatable, automatable, tool-agnostic publishing pipeline — especially for consistent releases over time.

Q: What’s the most common reason BIM-to-GLB files become “unshippable”? A: Uncontrolled tessellation and excess detail. Curves, small features, and MEP complexity can explode triangle counts, which then hits download size, memory, and mobile performance.

Q: How do you prevent losing “what element is this?” after optimization? A: Decide your interaction contract early. If users need element-level picking, preserve stable IDs (like IFC GlobalId) through the pipeline — often via node naming, extras, or a sidecar index — before you start merging meshes.

Q: Why do materials often look different after conversion, even when the geometry is correct? A: BIM materials aren’t authored for real-time PBR. After conversion, “material preservation” usually becomes “material interpretation”: keeping color, transparency intent, and roughness/metalness assumptions consistent enough for the target viewer.

Q: Compression sounds great — when can it backfire? A: When viewer support or decoder setup isn’t consistent across your targets, or when decode cost becomes a bottleneck on low-end phones. Compression should be a product decision backed by testing, not a default switch.

Q: What’s a simple QA loop that catches most issues before publishing? A: Validate the GLB, then test in your real targets (web viewer + AR path). Look specifically for scale/orientation surprises, transparency problems, missing faces/normals, and whether required IDs still map to selectable parts.

Q: What’s one “extra” question teams should ask before committing to a pipeline? A: “Do we need interaction or just visualization?” If the answer is interaction at scale, you may need stricter scene structuring and metadata rules — and in very repetitive models, more deliberate instancing/batching strategies than generic exporters provide.
Contact Elf.3D to explore how custom mesh processing algorithms might address your unique challenges. We approach every conversation with curiosity about your specific needs rather than generic solutions.

*Interested in discussing your mesh processing challenges? We'd be happy to explore possibilities together.*

From BIM to Browser: Practical Paths from Revit/IFC to glTF for Web & AR

BIM authoring tools excel at meaning: parametric geometry, relationships, classifications, and property sets. Real-time viewers (web, mobile, AR) excel at playback: fast loading, predictable shading, and stable performance. When teams export a BIM model to glTF/GLB, they’re effectively “compiling” an authoring-rich model into a runtime asset.

That framing matches the intent of glTF itself. The Khronos specification describes glTF as an API-neutral runtime asset delivery format, designed for efficient transmission and loading. As of 2026, the current glTF major version remains 2.0, with patch updates (e.g., 2.0.1) providing clarifications and backward-compatible fixes. Khronos also notes that glTF 2.0 became an ISO/IEC standard (ISO/IEC 12113:2022), underscoring its role as a broadly adopted delivery format.

The practical question for BIM teams isn’t “can we export to GLB?” — it’s: what do we keep, what do we drop, and how do we make the result reliable across viewers?

When GLB is the right target (and when it isn’t)

GLB shines when your success metric is time-to-view and portability: quick stakeholder walkthroughs, lightweight design review, marketing previews, or AR “place it on site” demos. Google’s documentation positions <model-viewer> as a straightforward path for web viewing, with AR handoff options on supported devices; it explicitly supports gltf/glb models.

GLB is a weaker fit when the workflow depends on BIM’s deeper semantics: rule checking, compliance/audit trails, model view definitions, or robust relationship queries. In those cases, IFC remains the backbone of open exchange, and buildingSMART’s IFC 4.3.2.0 documentation is published as the version sent to ISO with matching content. A useful mental model: IFC is for exchange and data integrity; GLB is for distribution and experience.

Pipeline choices: Revit → GLB vs IFC → GLB

There isn’t one “best” pipeline — there are three common routes, each optimizing a different priority.

Route Strengths Typical gaps
Revit → GLB (exporter) Fast turnaround; matches a curated view Metadata conventions vary; tool/version lock-in
IFC → GLB (conversion) Repeatable and automatable; open interchange Appearance may need remapping; geometry can bloat
IFC → DCC → GLB Maximum cleanup control (LOD/material polish) More steps; harder governance and repeatability

For an open, repeatable approach, IfcConvert (IfcOpenShell) is a widely used command-line option; its documentation lists GLB among its supported output formats. This matters operationally: CLI pipelines can be automated, versioned, and tested like any other build step — especially valuable when “publish to web/AR” becomes routine rather than exceptional.

Geometry conversion: why files get big fast

Most BIM geometry is not authored as triangles; it’s authored as solids, sweeps, and procedural descriptions. Exporting to GLB involves tessellation (turning curved and analytic surfaces into meshes). The danger is not tessellation itself — it’s uncontrolled tessellation.

A quick intuition:
GPU vertex memory ≈ V × (position + normal + UV + extras)
When V (vertex count) explodes, you pay three times: download size, runtime memory, and draw/processing cost (especially painful on mobile).

Two recurring pitfalls show up in real pipelines:

  1. Detail that matters in BIM doesn’t matter at runtime. Tiny fillets, threads, dense MEP components, and hidden layers can dominate triangles while adding little value to a walkthrough.
  2. Large coordinate systems and offsets can cause precision issues. Many conversion tools expose options to recenter geometry; IfcConvert’s usage docs include centering and offset-related options. In practice, teams should confirm these behaviors per tool/version — users have reported version-specific quirks around centering/offset behavior in IFC→GLB conversion workflows.

Our rule of thumb: define use-case LOD early (review vs AR vs marketing), then bake that into export settings and model scoping (views, filters, element suppression) so optimization is deliberate, not reactive.

Scene structure and element identity: don’t lose “what is this?”

If your web/AR experience is purely visual, you can treat the model as a single drawable object. But if you need selection, filtering, or “click to see properties,” you need an identity strategy.

In IFC-based workflows, teams often treat GlobalId as the stable key. The tricky part is that performance optimizations — mesh merging, batching, LODs — can easily break a clean one-element-to-one-mesh mapping unless the pipeline is designed to preserve linkage (e.g., via node naming conventions, extras, or a sidecar index). This is a common pain point in real IFC→GLB usage: people convert the whole model, then struggle to retrieve the mesh corresponding to a specific GlobalId in the resulting glTF scene.

So: decide the interaction contract up front. Are you selecting elements, systems, or just levels/zones? The right granularity drives how you structure the glTF scene graph and what metadata must survive optimization.

Materials: BIM appearance vs real-time PBR reality

glTF 2.0 standardized a PBR-based material model, with the goal of consistent, portable appearance across runtimes. BIM materials rarely map 1:1 to that model, so “preserve materials” usually means “preserve intent”: base color, transparency, and broad roughness/metalness defaults.

Where design options matter, glTF supports material variants via extensions, but AR handoff paths may not behave uniformly. For example, maintainers have noted that Scene Viewer doesn’t support in-AR variant switching in the same way that WebXR can. This is one of those places where setting expectations early prevents frustration later.

Performance toolkit: compression, instancing, and compatibility

glTF’s performance story is largely extension-driven:

  • KHR_draco_mesh_compression enables Draco geometry compression.
  • KHR_texture_basisu enables KTX2/Basis Universal supercompressed textures.
  • EXT_meshopt_compression provides buffer compression tailored to glTF data.

Viewer support varies. three.js’ GLTFLoader documents supported extensions, and teams often need to explicitly enable decoders (Draco, KTX2, meshopt) depending on the chosen compression strategy.

Lever Typical win Risk When to use
Mesh simplification Smaller + faster Visible artifacts Mobile/AR, early review
Instancing Fewer draw calls Hard to detect automatically Repetitive families/panels
KTX2 textures Smaller textures Toolchain variance Web delivery at scale
Draco / meshopt Smaller geometry/buffers Decode/support trade-offs Large static scenes

In narrow, high-throughput scenarios — very large models with heavy repetition — tailored instancing/batching logic can reduce overhead compared to generic exporters. But for many projects, off-the-shelf conversion plus a disciplined “scope + compression + QA” routine is sufficient.

Web + AR delivery: align format decisions with deployment

On the web, operational simplicity often wins. <model-viewer> deliberately supports only glTF/GLB, which encourages teams to standardize on GLB for deployment and caching. For AR handoff, Google’s Scene Viewer workflow includes a validation step that expects a glb or glTF (plus associated assets if needed).

This leads to a pragmatic recommendation: treat GLB like an artifact you build, not a file you export once. Put it behind a repeatable pipeline, with validation gates and known targets (web viewer + AR path).

QA that doesn’t feel heavy

Two lightweight steps catch a surprising number of issues:

  1. Run the Khronos glTF Validator (web tool, CLI, or npm) to catch structural errors and collect asset stats.
  2. Cross-check in at least two viewers: your target web stack and your target AR handoff path. Viewer differences often surface transparency, double-sidedness, compression support, and texture edge cases.

A “minimum viable GLB” checklist (as of 2026):

  • Clear use case and LOD target (review vs AR vs presentation)
  • Controlled scope (filters/views to avoid exporting irrelevant detail)
  • Deliberate compression stance (none vs Draco/meshopt + KTX2)
  • Coordinate strategy tested (recentering/offset verified in your chosen toolchain)
  • Element identity preserved if interaction requires it (IDs and categories survive optimization)
  • Validator pass + target viewer render parity

References