A 3D model becomes genuinely useful at the point it stops being a picture and starts being connected to something real. 3D visualization and digital twin work is the difference between a rendering of a building and a model that shows what that building is doing right now.
What We Build
- Interactive facility models — navigate a building or plant, inspect equipment, see state.
- Digital twins — models connected to live data from the systems that run the facility.
- Product visualisation — interactive configurators and demonstrations.
- Process and equipment animation — show how something works to people who will never read the manual.
- BIM and CAD integration — start from the models that already exist rather than rebuilding geometry.
- Training environments — the same model reused for operator and technician training.
Where the Value Actually Is
The visual is the easy half. The value is in the connection — mapping model geometry to real assets and points so that what you see reflects what is happening. That mapping is unglamorous data work, and it is what separates a twin from an expensive animation.
It is also why we do this alongside SoftwarePile’s Niagara engineering: a twin fed by badly mapped or mislabelled points looks convincing and tells you nothing true.
Build It Once, Use It Repeatedly
The strongest economics come from a model that earns across its life — used for design review, then commissioning validation, then operator training, then ongoing operations. Building for one purpose and rebuilding for the next is how these projects become expensive.
Tell us what you want to model and what it should connect to and we will scope it.
Related services
- AR and VR Development — Related: AR and VR development.
- Simulation and Training Software Development — Related: simulation and training software.
From Source Geometry to a Real-Time Model
The BIM or CAD model is the starting point and stays the starting point. Nobody remodels your building from scratch, and the design geometry remains authoritative: it is where dimensions come from and where changes originate. What gets reworked on the way into a real-time engine is the object hierarchy and the render-side representation, not the design itself.
That rework is necessary because the two file types are authored for different jobs. A design model is organized for documentation, coordination, and fabrication tolerance. A real-time model is organized around what a person will click, what has to be colored or highlighted when a value changes, and what a frame has to draw sixty or ninety times a second. So the conversion regroups objects: the equipment you need to select becomes individually addressable, the surrounding fabric is consolidated, internal detail that is never visible in the finished experience is left out of the runtime scene, and lighter representations are derived for distance viewing. The source file is untouched by all of this.
Laser scan data is the other common input, and it behaves differently. A scan tells you what is actually in the space, which matters when drawings have drifted from as-built reality, but scan output carries no object identity. Nothing in a point cloud knows it is an air handler. Objects have to be separated and identified before any of them can be mapped to an asset, and that identification step is where scan-sourced projects spend their effort.
The decision that drives the rest is granularity: what counts as one object. Per room, per panel, per device, per component. That choice determines what can be selected, labeled, colored, and bound to a data point later, and it is easier to settle at the start than to retrofit once the scene is built.
Keeping the Mapping True After Handover
The mapping between model geometry and real assets and points is not a step that finishes. Facilities change: equipment gets replaced, panels get re-addressed, points get renamed during an unrelated service visit, a room changes use. Every one of those events can quietly break a link, and a broken link in a 3D view does not announce itself the way a broken link in a spreadsheet does.
For that reason the mapping is built as data, not buried in the scene. It lives as a table that ties a model object identifier to an asset identifier and to the point references it reads, and it can be opened, reviewed, and corrected by someone who knows the plant without opening the 3D tool at all. Review by that person, before the model goes into use, catches more errors than any automated check, because the errors are usually of the form "that tag is real, it is just on the unit next door".
After handover the mapping needs an owner on your side: someone whose change process includes updating it when the physical thing changes. This is the maintenance cost of a twin, and it is small if it is somebody's job and large if it is nobody's. Projects that skip naming that person tend to come back a year later asking why half the model reads blank.
Not every project needs this layer. A design review walkthrough, a configurator, or a piece of process and equipment animation has nothing live behind it and carries none of this ongoing work.
When a 3D Model Is the Wrong Tool
3D earns its place when the answer depends on location, adjacency, or physical form: where the affected unit is, what is above the ceiling next to it, which way the access panel opens, what a technician will actually be looking at. When the question is "what is this value and is it in range", a list, a trend, or a floor plan answers it faster and costs far less to keep current. Building a navigable model so that someone can find a number they could have read on a schedule page is a way to make a simple task slower.
Two other situations argue against it. If the systems that run the facility cannot expose their data through any interface, a twin has nothing to connect to and what you would be buying is an animation. And if the space is small enough that people already hold its layout in their heads, the spatial context the model provides is context they do not need.
The reuse case the page describes above still holds and is still the right way to scope this work. What it requires is an owner for model-to-building alignment. A model that carries design review, then commissioning validation, then operator training, then operations stays worth having because someone keeps it aligned with the building as the building changes. If that ownership is unsettled, the thing to resolve before scoping is who will hold it, not whether to build something narrower, because building for one purpose and rebuilding for the next is the expensive path.
What the Model Shows When the Data Stops
A value rendered in 3D looks authoritative whether or not it is current. That is the specific failure mode of this kind of interface, and it has to be designed against rather than discovered in front of an operator. Sources update at their own rates, the model refreshes at its own rate, and a connection can fail without anything on screen changing.
So the display carries the state of the data as well as the value. An object whose source has stopped reporting reads as unknown rather than holding its last good number, and it looks visibly different from an object that is reporting a normal value and different again from one in alarm. Three states, not two: good, off normal, and not reporting. Deciding what each of those looks like is worth ten minutes at the start and is painful to add later, because it touches every material and every object treatment in the scene.
The other half is load. Every live object on screen is both something to draw and something to read, and the read cost grows with how many points are visible at once. Batching reads by area of the model rather than issuing one per object keeps that manageable, and it also means the model degrades sensibly: when the data path is down, navigation, geometry, and documentation still work, and the model is still useful for showing someone where to go.
Frequently Asked Questions
What does a digital twin not do?
It is not a physics simulator: it will not predict airflow, thermal behavior, or how a machine will fail. It is not a predictive maintenance product, and it does not make recommendations about when to service equipment. It is also not a control system, so equipment is not operated through it, and it is not a system of record: the authoritative history stays in the systems it reads from. Confusing it with any of those is the most common reason a twin disappoints someone who was not in the scoping conversation.
What does the finished model actually run on?
Delivery targets are a desktop application, a browser build, a headset build for VR, or a tablet for use on site, and a project can target more than one. The build is produced in Unity, Unreal Engine, or Godot, and which engine fits depends on the target list, the rendering demands, and how the model has to be distributed and updated afterward. A browser build reaches the most people with the least installation friction; a desktop or headset build gets more rendering headroom and better access to local hardware.
What do we have to provide to get started?
Two lists beyond the source model: an asset list using the identifiers your organization actually uses, and a point list or tag export from each system the model will read. Alongside those, a named person who can confirm which physical thing a given tag refers to, because exports are frequently ambiguous about that. It is normal for the asset list to be assembled from more than one source and to disagree with itself; reconciling it is part of the work rather than a prerequisite you have to finish first.
How does a rollout proceed, in order?
Scope first: what is modeled, to what granularity, for which audience. Then geometry conversion and a navigable build with no data behind it, which is the point where people can walk through and tell you what is missing or wrong. Then the asset and point mapping is assembled and reviewed against the real facility, and a small subset of points is bound end to end and checked value by value against the source system before coverage is expanded. Delivery to the chosen targets and handover of the mapping and project source come last.
How does it integrate with systems we already run?
It reads through whatever interface each system already exposes, such as an API, a historian, or a scheduled export, and the flow is inbound to the model. Nothing new is installed on the operational side unless that interface itself requires a connector, and that decision is made with the people who own those systems. If a system has no exposed interface at all, that work has to happen on your side first, because it is a change to your system rather than to the model. Where an interface exists but is read-limited or rate-limited, the model is built around those limits rather than against them.
Who controls the data and where does it live?
The model reads from your systems and does not take custody of their records; the source of truth stays where it is. Where the build is hosted or installed, what it is permitted to reach, and who is granted access are settled with you before integration work starts, because those constraints shape how the data path is built. Ownership of the geometry, the mapping, and the project source is agreed at contracting, in line with how the rest of our engagements are handled.
What do we have to decide before modeling starts?
Audience and hardware, first, because the target sets the geometry budget for everything built afterward and is expensive to change once the scene exists. Then object granularity, meaning what counts as one selectable thing. Then the questions the model is supposed to answer, stated concretely enough that you could check whether it answers them, since that is what determines which points are worth mapping and which are noise.
Can a model built for operations be reused for VR training later?
Yes, and that reuse is the reason to build this way rather than commissioning separate models per purpose. What makes it work is naming the intended uses at the start: if a headset build and training scenarios are on the list from the outset, the geometry budget, the object granularity, and the interaction points are set to carry them. Uses added later can still be served, but they are a change of scope rather than something already provided for, so the list of intended uses belongs in the initial scoping conversation.