Spatial data simulation for district redevelopment

Traffic and access, before you rebuild.

Digital Twin Simulation models the street network of one district and simulates what happens when you redesign it. It runs inside your own environment, on the data you already hold, and connects to no external service.

Request a pilot See the demo
Demo visual — replace Simulated flow — district street network
What you are looking at: walkability simulated across the street network of a single district. The simulation covers that district, not an entire city — and the network itself is generated by the engine from map data rather than drawn by hand.

Rendering: this capture is displayed in Cesium over Google Photorealistic 3D Tiles. The aerial imagery is a backdrop for the visualisation only — it is not part of the simulation, contributes no data to it, and is not required to run it. The tiles shown in the simulation are generated by Digital Twin Simulation.

Google Maps Cesium ion Imagery © Google, Maxar Technologies and other contributors · © Cesium GS, Inc.
How it works

The world is built from your data, then set in motion

Four steps, in order: bring in your datasets, build the world from them, change it through rules, and run it independently of whatever draws the picture on screen.

  1. Bring in vector datasets

    The engine takes vector data directly — roads, buildings, water, land use, boundaries. OpenStreetMap works out of the box, but so does your own GIS export or an internal dataset. Nothing has to be redrawn by hand first.

    vector dataset input
    use the map data you already have

  2. Build the world: Wave Function Collapse plus cellular automata

    Wave Function Collapse assembles the area from pieces that fit together, so the layout follows the real geography instead of being modelled tile by tile. It also fills the gaps: where your dataset is incomplete or silent, WFC infers what belongs there from the surrounding constraints, so a partial map still produces a complete world. Cellular automata then give that structure behaviour — each cell acts on its own and on its neighbours. The two work together: one builds the world, the other sets it in motion.

    WFC + cellular automata
    the world assembles itself, then behaves on its own

  3. Inject changes through rules and utility scores

    This is how you alter the world. A rule says what a location does or what may happen to it — close this street, cap the traffic here, let water through. A utility score expresses how desirable something is at a given spot, so competing options can be weighed rather than hard-coded. You add a scenario without rebuilding the model.

    rules + utility scores
    try a change by describing it, not by rebuilding

  4. Simulation independent of display

    The simulation itself does not depend on any particular renderer. Unreal Engine is one integration we have built, not a requirement of the architecture. Today it is the only integration we support — see current status.

One engine, several domains

The same engine, on a completely different problem

We put it on an astronomy problem: no city, no street network, a different data source. Two things follow. The core generalises, and the physics holds within the model's resolution — accurate, not merely plausible-looking.

Demo visual — replace Same engine · different domain · different data source
Not a product feature — but a real physics result. A gravitational simulation, used to show that neither the geography nor the urban domain is baked into the engine. The deformed grid is the spacetime fabric: mass curves it, and everything else follows that curvature.

The effect to watch for in the capture: when the central mass is removed, the Earth does not leave its orbit straight away. It keeps orbiting as if nothing happened, and only reacts once the change in gravity actually reaches it — which is what really happens, and is the kind of causal correctness a simulation has to get right before its results can be trusted.
Application

Redevelopment decisions, tested before they are built

A plan is normally judged on how the new street or building looks. What it does to the streets around it — where the traffic goes instead, which neighbourhoods become harder to reach — is a separate study, and often a later argument. This is the model for that second question.

The problem

Closing a road, adding a school, opening a new residential block or removing parking all redistribute movement through a district. The effects show up on streets that were not part of the plan, and they are usually discovered after the decision instead of before it.

Where it helps

Accessibility, redevelopment impact, traffic flows and cut-through routes — the questions that come up in council papers, resident objections and internal review, and that currently need a specialist study to answer.

Questions you can put to the model

  • Which streets gain or lose traffic after this redesign?
  • Which neighbourhoods become harder to reach, and by how much?
  • Where does cut-through traffic move if we close this road?
  • What changes if this street becomes one-way, or loses a lane to green space?
  • Does the queue at this junction move, or grow, under the new layout?

Worked example

Placeholder — supply your real case. The structure document asks for one city, one question and one outcome. Suggested shape: the question that was asked, the two scenarios compared, and the streets where the outcome was not what the plan assumed.

What the outcome looked like

Placeholder. Add the finding, the visual and — if you can — what the municipality did with it. One concrete case is worth more here than any further explanation of the engine.

Where this is going

Everything below runs on the same engine. What differs is how much of it we have built — the list is ordered by how close each one is, not by how interesting it is.

  1. Full map editing

    Editing the network itself inside the simulation, so a redesign can be drawn and tested in one place rather than exported between tools. Closest to what exists today.

  2. Environmental systems — heat, wind and other forces of nature

    Continuous fields rather than discrete movement, so the modelling differs from traffic. It is conceptually simpler than it sounds, and it shares its structure with a wider family: heat, wind, water, greenery and the way they interact. That family is where this goes next.

  3. People

    Pedestrian and cyclist movement as a modelled flow, on top of the traffic simulation. Named last because it needs the traffic layer to be solid first — the flows interact, and modelling walkability on a network that is still moving is not worth much.

Local & EU

Your data does not leave your network

Digital Twin Simulation is designed to be run in the customer's own environment. That is an architectural decision, not an add-on — and for a public body it is usually the reason a project can be approved at all.

  • Runs in your environment

    The simulation runs on your infrastructure. Your map data, your network data and your results stay inside your own network instead of being uploaded to a third party.

  • An EU-established company

    D8Diffusion is established in the EU with no parent company outside it. We state this separately from where data is hosted, because they are two different things.

    To be straight with you: our own website hosting and email currently run on Cloudflare and Google, which are not exclusively EU-based. That affects this website, not the simulation — which is designed to run inside your environment. The privacy statement names both providers.

  • No hard dependencies — optional add-ons only

    Running a simulation needs no external map service, no third-party tile service and no cloud provider. Those are options, not requirements: imagery and rendering services can be connected when they add something, and left out when they do not.

    The walkability showcase on this page is one such optional layer — it is rendered over Google Photorealistic 3D Tiles in Cesium, purely as a backdrop. It is not part of the engine and computes nothing, and the same simulation runs without it. See data sources for the attribution it carries.

  • The data sources are yours to choose

    OpenStreetMap, your own municipal data, or internal systems — tags can be set by any of them, and combined. OpenStreetMap is where we start, not a restriction.

  • No vendor lock-in

    Your data and your scenarios remain yours. The engine is not tied to a renderer, and the outputs are not held inside a service you cannot take elsewhere.

  • What you build stays yours to open — indefinitely

    You pay to use the tool, not to look at your own work. A map or scenario you have built can be loaded again and inspected at any time, at no further cost, for as long as you keep it. There is no per-view charge and no expiry on your own results.

    This covers what you build and keep on your own infrastructure. Any hosted or cloud features we add later would be a separate, optional service.

We keep this website simple: no advertising, no third-party analytics, no tracking. The only things it stores are your language and your light or dark preference.

Status and pilot

Where the project actually is

Proof of concept Not yet Updated: 16 October 2026

What we can show you today

  • A working proof of concept for simulation tiles — the cell-based world model runs and can be inspected
  • The gravity demonstration, as evidence that the engine is physically accurate rather than merely plausible — within its resolution, but correct in the behaviour that resolution captures
  • A walkability showcase for a district — one area, one question, end to end
  • Maps built automatically from real geographic data, not hand-modelled, including where the source data has gaps

Not yet

  • A validated traffic-flow simulation for a district. What exists is a proof of concept, not a calibrated model.
  • Support for running it without Unreal Engine. The architecture allows it; we do not support it yet.
  • Full map editing inside the simulation
  • Pedestrian and cyclist flows
  • Environmental systems — heat, wind and other forces of nature
  • A finished product. This is R&D with demos that work.

The pilot: one district, one real question

We are looking for a small number of design partners. You bring a district and a question you genuinely have to answer; we run it and show you the result.

What we ask of you

  • One district or area — a neighbourhood is enough
  • One real question you currently have to answer
  • A few hours from someone who knows the area and the data
  • Permission to describe the case afterwards, if you are happy with it

What you get

  • The simulation run at no cost
  • Influence on what gets built next
  • The results, and the reasoning behind them
  • No lock-in and no obligation to continue

Get in touch

Tell us what you are working on and which area you have in mind.

Pilot or demo request General enquiry

Pilot requests go to [email protected]. Everything else goes to [email protected].

What to include in a pilot request

The district or area and roughly how large it is, the decision you are preparing for, your timeline, and who else would need to be involved. That is usually enough for us to give you a useful first reply.

What happens next

We reply within a few working days. If the question fits, we will ask for whatever data you can share and agree on what a useful result looks like — before any work starts. If it does not fit what the engine can currently do, we will say so rather than take the pilot.

We are in R&D. A pilot is a collaboration on an unfinished product, not a purchase — and it is free.