Simam AI Lab Our applied AI research division is now open. Visit the lab

Client delivery under NDA / Construction technology

Routing a person across a construction site that has no map.

A browser application that renders a real construction site as a drone-captured Gaussian splat and computes walkable routes across it in real time — on a phone, with no plugin and no app install. It holds several captures of the same site taken at different points in the build programme, so a route can be compared against how the site looked weeks earlier.

Photoreal site capture, routed on in the browser

Walkability derived from raw scan geometry, not hand-authored

Multiple captures of one site, switchable to compare progress

The problem

Large sites change faster than the drawings describing them.

A construction site changes weekly. The plan drawings are already stale, the site is not on any consumer map product, and the people who need to move around it — site managers, inspectors, contractors, safety officers — are navigating from memory, radio and paper.

Need 01

“How do I get from here to there, today?”

Not the route on the master plan. The route that is actually walkable given this week’s excavations, deliveries and closures.

Need 02

“What changed?”

Progress reporting is photographs in a slide deck. Stakeholders who are not on site have no spatial sense of movement between one month and the next.

Need 03

“Where can’t I go?”

Hazards, active zones and vehicle movements need to be visible in the same view as the route, not in a separate document.

The question the prototype set out to answer: can you route a person over a raw, unedited, photoreal site capture — in a browser — without first hand-authoring a navigation map?

Why a photoreal capture rather than a 2D map.

The conventional answer is a 2D map product with a GIS routing backend, and it is a perfectly good answer. But it discards the thing site teams respond to most strongly in a demo: recognition. A polygon labelled “Sector 4” means nothing to a foreman. A photoreal render of the concrete they poured last Tuesday means everything.

Capture is cheap and repeatable

A drone pass produces the asset

No modelling step, no retopology, no artist in the loop. That is what makes weekly recapture economically possible — and weekly recapture is what makes the progress comparison real rather than a mock-up.

It survives messy geometry

Scaffolding and fencing do not break it

Mesh fencing, foliage and cabling destroy conventional photogrammetric meshes. Gaussian splats degrade far more gracefully.

The trade-off

A splat is purely visual

It carries no surface, no collision and no notion of “ground”. You cannot walk on it or raycast against it meaningfully. Everything functional has to come from somewhere else.

The build in use

Tap two points, get a route you can actually walk.

Selection is disambiguated from camera panning by a movement threshold, raycast against the collision mesh, then snapped to the nearest walkable node — or rejected outright with clear feedback when there is no reachable surface under the tap.

Phone layout showing a smoothed route drawn across the site, with an estimated walking time of three minutes over 254 metres — A computed route drawn across the capture, with its distance and walking time. The phone layout was the target, not an afterthought — the person who needs this is standing on the site.

Site capture seen from above with selectable points of interest and a route-found confirmation — Selection points over the capture, and the confirmation that a route was found. Each capture carries its own date and its own set of points.

Phone layout showing a vehicle hazard card marked as no pedestrian access — Hazards are a distinct, non-navigable class: they can be inspected but never used as a route start or destination.

The engineering problem

A scan is honest about reality, and ignorant of it.

Every game-engine routing library expects a curated navigation mesh, authored by hand. What a drone produces is a triangle soup in which a floor and a car roof are indistinguishable. Rather than force it into a navmesh library, the build treats the mesh itself as the graph: walkable triangle is a node, shared edge is a connection, distance between triangle centres is cost.

The hard part is deciding what “walkable” means. Scan meshes melt — walls slump, trees become cones, debris becomes ramps — and a melted surface is a gentle slope, and a gentle slope looks exactly like a path. Without defences, the router will happily send someone up a tree and along a roof, because geometrically that is a perfectly good route.

Per triangle

Face normal within ~37° of vertical

Rejects walls and steep debris before they can ever enter the graph.

Per connection

Traversal slope limit ~31°

Rejects step-ups between surfaces that are adjacent in space but disjoint in reality.

Layer filters

Local height, depression, dominant ground

Drops rooftops, slab tops and pit floors that would otherwise read as walkable ground.

Connectivity

Largest connected island only

Isolated surfaces become unselectable rather than mis-routable — a rejection is safer than a wrong answer.

Path cost

A* penalises vertical movement

Given a level option and a climbing one, the router prefers level ground.

Post-validation

Reject implausible elevation spans

A final check against a fraction of the site diagonal catches anything the earlier five filters let through.

Stated plainly: walkability over a raw scan is a heuristic stack, not a solved computation. Six independent filters, none sufficient alone. The failure mode of this approach is not the imperfection — it is pretending the imperfection is not there.

Two results worth recording, including one that cost time.

A case study that only lists wins is not useful to anyone deciding whether to commission similar work.

Reverted

The filter that seemed obviously right

A height-above-local-ground filter was implemented and then removed. On a site with deep building interiors and a large excavation pit, “local ground” is ambiguous, and the filter carved away legitimate walkable surface near every edge. The cheaper heuristics performed better on the real data.

Unreliable

Auto-detecting solid obstacles

Detecting a parked vehicle that should block a route, directly from the scan, proved unreliable: photogrammetric noise is geometrically indistinguishable from the top of a real box. The dependable answers are to cut the obstacle’s footprint out of that capture’s collision mesh, or to declare a hazard zone in configuration.

Graph construction over a multi-million-triangle mesh is not something to do on a site manager’s phone while they wait, so the graph is baked at build time into compact adjacency data and fetched ready-made. The example capture bakes to roughly 10,500 nodes and 14,200 connections. The runtime validates that bake against the loaded mesh’s triangle count and falls back automatically if they disagree — closing the classic failure where someone edits a collision mesh, forgets to rebake, and the app silently routes over last week’s layout.

Case study decision record

The commercial case, in one view.

What the project was intended to prove, what it demonstrated, and what it deliberately does not claim.

Business challenge: People working on large, fast-changing construction sites navigate from stale drawings, memory and radio, because the site exists on no map product and changes faster than any drawing describing it.
Why the project mattered: Site teams engage with a view they recognise. A photoreal capture earns attention in the first thirty seconds in a way an abstract plan does not — and that engagement is a product property, not a graphics one.
What Simam Digital designed and built: A browser application rendering drone-captured Gaussian splats of a live site, with routing computed over a navigation graph derived from the raw capture, points of interest, a non-navigable hazard class, and switching between captures taken at different points in the programme.
Important engineering decisions: Separate what you see from what you route on, absolutely: the splat is never routed on and the collision mesh is never rendered to users. Bake the navigation graph at build time and validate it at runtime. Choose the mature rendering path — WebGPU is better technology, WebGL shipped.
Delivered: A working, deployed, static-hosted TypeScript application built in a four-day core build: site rendering, two captures with asynchronous switching, points of interest with information cards, tap-to-route with rejection feedback, A* routing rendered as a smoothed map-style path, route distance and time, and a responsive phone layout verified on device.
Honest limitations: Walkability remains heuristic. Route cost is straight-line distance plus a vertical penalty, with no accessibility, surface-type or congestion weighting. Solid obstacles are authored rather than detected. Routes do not persist across reloads. This is a proof of concept, not an authoring or content-management platform.
Where it goes next: Capture as a scrubbable time series rather than two states; deriving collision directly from the splat to close the alignment problem at source; quantified change detection between two aligned captures as a reporting product in its own right.

Have a site, an asset or an environment that nobody can see whole?

The valuable asset here was not the renderer or the pathfinder. It was the demonstrated pipeline from a drone flying over a site to a person on a phone being told how to walk across it, as it was on any given week.

Start a project brief Back to case studies