Extracted from CAD: the assembly tree already exists in the file. High reliability — it is the designer’s own data. This is the prerequisite for Class C, and it cannot be substituted.
Platform
How MeshAR is built
Three stages, in order. For each one: what it does, what it needs from you, and where the honest limits are.
Stage 01
Ingest — mesh or CAD
Two very different sources end up in the same place: triangles and PBR materials on the GPU, packaged as glTF/GLB. Getting there is not conceptually hard, it is detailed work — units (mechanical CAD in millimetres, Unity in metres, a factor of 1000 is the first thing you will see), up-axis and handedness, pivots left wherever the designer left them, and a polygon count orders of magnitude above what a phone will draw.
What does not converge is the semantics, and that is the structural point of the whole platform. A CAD assembly already contains a graph: parts, sub-assemblies, instances with transformation matrices, part numbers. A mesh contains, at best, a hierarchy of node names decided by whoever exported it. The difference is not recoverable downstream.
Three levels of semantics, not two
A mesh authored to a declared rule: node names following a convention, glTF extras, material variants. Worth exactly as much as the discipline of whoever exports it — and it is what a configurator actually runs on.
An arbitrary mesh: photogrammetry, a marketplace download, a freehand export. Perfectly fine for placing an object in a room; you cannot address a component inside it.
Stage 02
Localization — the one common stage
Common as an interface, not as an implementation. The three classes need different anchoring strategies and they are not interchangeable: what is right for a configurator is conceptually wrong for a guided visit.
Strategies in use
-
Plane detection + tap
Class BThe user picks the spot. For a configurator this is the right answer rather than a fallback: the entire question being asked is whether it fits in their room.
-
Physical marker
Class CA sticker applied to the machine with a known offset. Cheap, robust, and precise enough for a highlight to land on the right component instead of its neighbour.
-
Model target
Class CRecognises the object from its own 3D model, with nothing applied to it. Excellent on rigid, distinctive geometry; it degrades on smooth, symmetric or reflective surfaces — which describes a lot of industrial machinery, so manual alignment is kept as a fallback from day one.
-
Geospatial / VPS and assisted manual alignment
Class AFor content that has to sit at the real place where something actually stood. Here a user tap is conceptually wrong: the visitor does not know where the wall was. It is the hardest localization problem of the three.
Stage 03
Presentation — where the classes separate
The shared baseline is not trivial: depth occlusion, credible contact shadows and light estimation are exactly what separates “a model glued onto the screen” from “an object in the room”, and they matter to all three classes. Above that baseline the three branches share almost nothing, and that is the correct outcome rather than a missing abstraction.
Class A — animated guide
A rigged character, a library of animations, and a decision layer that picks which one to play. The AI chooses the line and the gesture; it does not generate the motion bone by bone. Movement in the space is steering behaviour running locally at frame rate, with no network call in the loop.
Class B — configurator
Runtime variant and material swapping, bound to application state that lives outside the AR app. The app becomes a view onto the configurator, which makes this an application-architecture problem more than a graphics one.
Class C — procedure
Isolate, ghost, explode, highlight, with steps sequenced against sets of nodes. It needs the semantic graph from Stage 1, and it optimises for legibility rather than fidelity: knowing which part, in which order, beats a beautiful render.
Measurement
The measurement bench is part of the product
Drift, recovery time, light conditions and useful distance are not a checklist you run once. They are instrumentation: every localization strategy, in every class, is measured with the same ruler — so that “does it hold?” gets answered with a number instead of an impression.
-
Drift — ~2.7 cm median at two minutes
Five valid runs out of six between 2.6 and 3.7 cm, across very different scenes. The band is remarkably narrow: drift turns out to be robust against the scene, and light conditions do not move the verdict. The thresholds had been fixed in advance — under 2 cm meant purely visual anchoring would carry a repair procedure, 2 to 10 cm meant a configurator is comfortable and a procedure needs a physical reference. The result landed in the middle band, and the platform is built accordingly.
-
Settling — the first minute is not trustworthy
Confirmed on four separate runs: a peak of 8 to 19 cm in the first 10 to 48 seconds after placement, then a fall to the stable value. Anything that needs precision has to design around it. It is a constraint, not a defect to be fixed.
-
Recovery — the pose survives, the wait is the problem
Across three tracking-loss cycles the drift stayed flat: the anchor comes back where it was. The worst case cost 25 seconds of waiting, which makes it a UX problem rather than a tracking one — a distinction worth keeping, because they get fixed in different places.
-
Useful distance — 20 to 25 metres
A sharp and reproducible threshold, and the cause is the object becoming unreadable rather than the tracking failing: the tracking state held well beyond it. It is a content-size question, so it gets re-measured for each project with the real asset.
Samsung SM-S711B, seven runs, indoors and outdoors, August 2026.
Limits
What MeshAR does not do
Worth reading before the rest, because it saves both of us a call.
-
It does not recognise the world it walks into
A guide that describes whatever the camera happens to see is the fastest way to confidently describe something that is not there. MeshAR replaces recognition with position: know precisely where you are, then read a curated map. That works in a venue mapped in advance — a house, a museum, one specific showroom — and it does not generalise to “point the phone anywhere and explain what I am seeing”. For a defined place it is the right solution, not a compromise.
-
Native Autodesk formats cost money
Neutral CAD — STEP, IGES — is covered at zero licence cost. DWG and RVT need a commercial component, and that becomes a structural line in the estimate rather than a detail. It gets addressed when a project actually requires it.
-
Android / ARCore is the default target
iOS is a per-project decision, not an assumption. AR Foundation abstracts the common denominator, but occlusion through the Depth API and occlusion through LiDAR are not the same feature, and some localization strategies have different availability and licensing on the two platforms. For a configurator — which is a sales tool — it is a question worth settling up front.
Tell me what you want to put in the room
A scanned venue, a product catalogue, a machine with a maintenance manual. The first useful question is always which of the three classes it falls into — and that takes one email.
Get in touch →