From IFC to GLB: A three.js Viewer for SDx Digital Twin Workflows

An IFC-to-GLB pipeline can make an engineering model usable in a browser. Its value for an SDx digital twin workflow depends on what survives that conversion: object identity, spatial context and reliable connections to engineering information.

The architecture is straightforward to describe: prepare the geometry, export a browser-oriented representation, keep a mapping to the source objects, and resolve project information through an authorised integration layer. The difficult part is making those steps agree when the model changes.

This guide is for engineering information managers, digital engineering leads and developers planning a custom 3D application around SDx. It explains the design decisions behind a viewer that lets a user select an asset, understand its context and move to the relevant information or action.

What each layer does

IFC, GLB and three.js have different jobs. Keeping those responsibilities explicit makes the integration easier to maintain.

GLB is the binary container form of glTF. The glTF specification is designed for delivering runtime assets, rather than preserving a complete authoring environment. A conversion should therefore produce both a visual representation and a deliberate strategy for the engineering information it does not carry automatically. Khronos glTF 2.0 specification

The resulting 3D application can form a visual layer of a digital twin. A rendered model alone does not establish current construction progress or operational state. Those depend on connected information and a defined update process.

1. Start with the engineering export

Before choosing a converter, inspect a representative export. Two files with an .ifc extension can require different processing because their schemas, geometry representations and available properties differ.

Record the source revision, schema and export configuration. Check whether the file contains the tags, classifications and relationships needed by the application. Inspect placements and units, then identify which representation types the converter can process.

A converter written for tessellated geometry is a valid choice for a controlled export pipeline. It should not be treated as a general IFC geometry engine. Unsupported objects must appear in a conversion report, with enough information to investigate them. Silently dropping them can leave a convincing-looking scene that is incomplete.

Use an agreed sample covering the categories that matter to the workflow, including objects with multiple geometric parts and objects with missing properties. Compare the output with the source. File creation is only one check; model completeness and correct object relationships need their own checks.

For EPC and operator teams, this establishes a practical handover contract: what the model supplier provides, which export settings are expected, and who resolves missing or unsupported content.

Choose an export that preserves geometry and engineering data

For a Smart 3D workflow, one practical route is Smart 3D to a published .vue model with object data, then Smart Interop Publisher to IFC4, using the Industry Foundation Classes export target. Specify the model scope and engineering properties as part of the request, rather than asking only for an "IFC file".

The Smart Interop Publisher 16.2 export-settings documentation names the schema option IFC2X4, alongside IFC2X3. IFC2X4 is the exporter terminology for IFC4 in this workflow. It is a concrete export choice for this route, not a schema imposed by three.js. Smart Interop Publisher export settings

The rendering requirement is a geometry representation that the application can load and render. In the pipeline described here, the conversion stage produces glTF 2.0 packaged as GLB for GLTFLoader. IFC geometry must be interpreted and converted upstream; three.js does not require the original IFC to contain one particular entity type. GLB is the delivery format chosen for this architecture, not the only format that can be used with three.js. three.js GLTFLoader

An IFC4 export containing Body / Tessellation representations, with IfcTriangulatedFaceSet referencing IfcCartesianPointList3D, provides an explicit triangulated representation. Other exports may contain faceted BREP, swept solids or mapped geometry. Those can also feed a browser workflow when the geometry-processing tools support them and generate the required renderable output. The conversion stage may therefore perform tessellation, resolve transforms or expand mapped geometry rather than simply copy triangles.

A geometry-only export can produce a visible model while losing the information needed to organise areas, identify equipment and connect business records. For Smart Interop exports, check IfcObjectProperties and relevant properties such as Name, ClassID, System Path and Design Area. These are engineering-context requirements for the intended application, not prerequisites for drawing a mesh in three.js.

Check the file produced by the export settings. The 16.2 documentation describes Export geometries as BREPs as producing faceted boundary representations, while disabling it permits solid representations where applicable. Select settings that match the capabilities of the IFC processing tools. A checkbox label alone does not establish whether an export can be converted completely and correctly.

Validate a small representative export before requesting the full model. Check geometry coverage, property coverage, scale and spatial alignment together. Source coordinates in millimetres can be converted to metres, and non-identity placements can be resolved by suitable tools. Neither millimetres, identity placements nor a particular STEP line layout is a universal three.js requirement.

2. Convert geometry and retain its provenance

The conversion stage should produce a versioned package, rather than an isolated GLB file. A useful package contains:

• The renderable model or independently loadable model partitions.
• The mapping between rendered parts and source objects.
• A manifest recording source revision, converter version, units, coordinate transform and output checksums.
• A report of converted, excluded and unsupported objects, with the grouping rules used.

Counts do not have to match one to one. One source object can produce several meshes, while several source objects may be grouped for display. Document those relationships so a reduced mesh count is not confused with lost information.

IfcOpenShell's IfcConvert is one tool to evaluate for the IFC-to-GLB stage, according to the source schema and geometry representations. Its documentation lists binary glTF output and options for coordinate offsets. The following is a command shape to evaluate with an installed version and a suitable input file, not a tested conversion recipe for every engineering export. IfcConvert usage

IfcConvert sample.ifc sample.glb

This command does not by itself define your SDx object mapping, preserve every property in an application-ready form or connect construction data. Those are separate parts of the pipeline. Changing conversion tools or settings requires rechecking the geometry-to-object mapping because the output hierarchy and naming may change.

Local conversion can keep that processing step within a selected environment. Hosting, model delivery, API access, logging and optional external services still need separate data-flow decisions. An offline conversion step is not evidence that the entire application is offline.

3. Treat coordinates as part of the contract

Coordinate errors often appear as integration errors: an overlay floats away from its equipment, two disciplines do not align, or a selected object is outside the camera view.

Define the source units and axes, the target units and axes, and the transform used to reach a shared local origin. glTF specifies metres for linear distances and a right-handed coordinate system with positive Y up. Conversion must account for the source convention. glTF coordinate system and units

Large engineering coordinates may call for a local rendering origin. If multiple units or disciplines are loaded together, use a shared reference and retain the reversible transform. Independently centring every file without retaining its transform can destroy the alignment between models.

Apply the same transform to geometry, annotation positions, sensor markers and saved viewpoints. Include transformed bounds in the package checks. A useful acceptance exercise is to compare a small set of known reference points across the source model, the rendered scene and any overlays.

4. Preserve identity through optimisation

The most important relationship in the viewer is often:

Rendered part -> application element -> source object(s) -> SDx record(s)

IFC rooted objects carry a GlobalId. Retain this source identity where available, together with the model namespace and revision. Check how the exporter behaves across revisions instead of assuming that every re-export preserves every identifier. buildingSMART IfcRoot definition

An IFC identifier, an equipment tag and an SDx OBID are different identifiers. A generated string with an OBID- prefix does not establish a connection to a real SDx record. Resolve that relationship through the agreed data source, and leave unknown or ambiguous matches explicit.

The following is an illustrative application manifest, not an IFC schema or an SDx API payload. Its labels and references are synthetic; the source identifier placeholder must be replaced by the actual exported value.

{
  "modelRevision": "sample-r1",
  "elements": [
    {
      "elementId": "sample-element-a",
      "sourceObjects": [
        {
          "modelNamespace": "sample-model",
          "ifcGlobalId": "<source-global-id>"
        }
      ],
      "renderNodeKeys": ["sample-part-a", "sample-part-b"],
      "sdxObjectIds": [],
      "mappingStatus": "unresolved"
    }
  ]
}

Define how each render key is stored and recovered. A controlled exporter may use node metadata, for example through glTF extras, with a matching loader convention. Another application may need an explicit primitive or instance lookup. Do not rely on a scene traversal index, a display label or an optimiser-generated name as a durable business identifier.

Optimisation can merge geometry, rename nodes or change the hierarchy. Rebuild or preserve the selection mapping deliberately, then verify it against the final output. A smaller file is not a successful optimisation if selecting one valve returns another asset's documents.

5. Load the GLB and build predictable interactions

three.js provides GLTFLoader for loading glTF assets. Depending on the asset's extensions, the application also needs the appropriate decoders, such as Meshopt or Draco. Align the exporter settings with the loader configuration and pin the dependencies used by the application. three.js GLTFLoader documentation

In this architecture, the browser receives GLB and application data; IFC processing happens upstream. This is a design choice, not a claim that browsers cannot process IFC.

After loading, build a lookup that connects selectable geometry to application elements. Define what happens for a multipart object, an instance, an object without geometry and a record that has no reliable match. The interface should distinguish a failed lookup from an empty selection.

Useful interactions include focusing the camera on selected objects, highlighting a result set, isolating an area and opening an information panel. Preserve the original visual state when removing a highlight. If meshes share a material, changing it for one selection can affect other objects unless the highlighting strategy accounts for that sharing.

Display explicit loading, error and unavailable-data states. When a user changes models, prevent an earlier asynchronous response from populating the new model's panel. Release resources when they are no longer needed, with clear ownership for shared geometries, textures and materials.

6. Connect the viewer to the deployed SDx environment

A custom viewer needs a defined contract with its host: what selection it receives, how it obtains authorised data, and which actions it may expose. It does not need to duplicate every function of the host application.

Start with the exact deployed product and update. Octave currently identifies InConcert Core as the product formerly named HxGN SDx. Product naming alone does not establish compatibility with a particular extensibility interface or with SDx2. Octave InConcert Core

The integration design should cover three paths:

1. Host to viewer: receive the selected object references and model context, resolve them through the mapping, then focus or highlight the corresponding geometry.
2. Viewer to data: retrieve permitted attributes or document references for a selected object through supported interfaces.
3. Viewer to host: expose only the navigation or actions that the deployed host interface supports.

Use the vendor documentation for the selected environment when implementing API calls. The SDx Integration Web APIs guide provides the relevant starting point; this article does not prescribe tenant-specific endpoints or invent a universal dataset for risks, shipments or progress. SDx Integration Web APIs reference

For an embedded application, validate the message source and origin and use the supported authentication flow. Keep tokens out of model files, URLs and browser logs. Enforce access to geometry as well as to metadata: hiding an equipment row in the interface does not protect a model that the browser has already downloaded.

Acceptance should include expired sessions, forbidden records, unresolved objects and unavailable documents. Also verify any return-to-host action in the actual environment. A custom viewer embedded beside the platform is not evidence that the platform's native 3D viewer can be controlled through the same interface.

7. Add 4D and dashboards through shared data definitions

A 4D view relates geometry to time. A construction sequence needs a planning or status source, object-to-activity relationships and rules for how dates change what is visible. These do not follow automatically from the geometry.

Separate planned, actual and forecast dates. Define whether one activity covers several objects or one object participates in several activities. Decide how missing links, partial completion, revisions and reporting cut-offs are represented. Show unknown states as unknown rather than assigning them a reassuring colour.

A progress dashboard and a time-based model view should use compatible definitions. Document the reporting date and whether progress is based on quantities, hours, weights or milestones. A simple count of visible objects is not automatically a meaningful project progress measure.

The same principle applies to logistics and risks. A late shipment can be connected to affected objects when the relationship exists; a risk can be located in the model when its affected assets are identified. Neither relationship should be inferred solely from similar names.

Document revision is another useful connection. A team reviewing an object may need its current technical documents, including multilingual document workflows in SDx. Geometry, reporting and document access can share context while retaining their own sources and permissions.

8. Measure performance against the workflow

Model file size is only one part of the experience. Transfer, decompression, parsing, CPU memory, GPU memory, draw calls, material changes and picking can each affect usability.

Measure the time until users can perform the intended task, not only until a loader finishes. Test initial display, selecting an object, isolating an area, applying a status overlay and switching models on representative devices.

Consider partitioning by area or task, reducing unnecessary material variation and loading detail when needed. Instancing may help repeated geometry; level-of-detail strategies may help distant objects. Both require a selection and identity strategy that survives the optimisation. Choose them from observed bottlenecks rather than a generic object-count threshold.

Keep a repeatable baseline: model revision, device, browser, viewport, cache state and operations performed. Compare an optimised build with the same baseline and verify that all required objects remain selectable. There is no universal element count that guarantees a usable viewer across devices and models.

What to validate before connecting a live workflow

Common questions

Does converting IFC to GLB create a digital twin?

It creates a renderable representation. A useful digital twin workflow also needs object relationships, connected information and a defined update process. The required level of synchronisation depends on the decisions the system supports.

Are IFC properties automatically available in three.js?

That depends on the export and conversion pipeline. Define which properties must survive, where they are stored and how the viewer retrieves them. Retaining geometry does not prove that engineering semantics have been preserved.

Can the conversion run locally?

Yes, a suitable converter can run in a controlled local environment. Validate its supported inputs and dependencies. Decide separately where the resulting models, application and connected services are hosted.

Can a GLB file provide construction progress?

The format can carry application metadata, but reliable progress requires a dated source and an agreed calculation. A model's appearance does not establish the construction status of the real asset.

Build around the decision your team needs to make

VBTech develops custom SDx integrations and industrial digital twin applications that connect models, documents and project information around a team's workflow.

Start with the decision: locating an object, checking its information, understanding a delay or coordinating a response. From there, define the model contract, identity mapping, data sources and acceptance criteria needed to support it.

Discuss your SDx and digital twin integration.

Try the complete pipeline on an open IFC sample

The example below starts with Building-Architecture.ifc, an IFC4 educational model published by buildingSMART International Ltd. under CC BY 4.0. It is a building sample, not an industrial client model or an SDx deployment. Original model and repository

For this example, we used IfcOpenShell 0.8.5 to process the source geometry, write a GLB and extract property sets keyed by GlobalId. All 14 products with a representation were converted. The original IFC is 142,325 bytes; the resulting GLB is 33,648 bytes, with 1,167 triangles. These figures describe this sample only. The properties JSON is a separate file and is not included in the GLB size.

The downloadable conversion script uses IfcOpenShell's Python geometry iterator and glTF serialiser. This is the tested route for the example, distinct from the illustrative IfcConvert command earlier in the guide. IfcOpenShell geometry serialisation

To reproduce it, download the source IFC and script below, install the pinned dependency in a Python environment, then run:

python -m pip install ifcopenshell==0.8.5
python convert_example.py Building-Architecture.ifc output

The output folder contains building-architecture.glb, properties.json and conversion-report.json. Select an object in the preview to follow its source identity into the displayed properties. Geometry is converted before this page is opened; the browser loads the resulting GLB with three.js. This example does not upload or convert a visitor's own file.

The MIT License

Copyright © 2010-2026 three.js authors

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Attribution: Building-Architecture IFC sample, buildingSMART International Ltd., CC BY 4.0, repository revision 80d976a. The IFC download is unchanged. VBTech converted the geometry to GLB, extracted properties and added this viewer. The viewer recentres the scene, initially frames the building rather than the distant reference markers, and hides space and zone volumes until selected. No SDx identifiers, construction dates or operational statuses have been invented.