Spatial Architecture Visualization System
An architecture-focused system design explored how a flat floor plan could become a shared spatial visualization without asking every participant in the conversation to wear a headset.
Architecture · 3D visualization · WebGL · Gesture interaction
The problem
Architecture visualization creates friction on both sides of a client conversation. Producing 3D renders in specialist tooling takes an architect substantial time, and the client may still struggle to translate a 2D plan or a static render into an intuitive sense of the space.
Headsets solve the second half and make the first half worse. They isolate the wearer, so the conversation stops being shared, and they add hardware to a meeting that had none. The design goal was to narrow the interpretation gap for a group of people standing in one room.
What we delivered
A three-layer system design, with the prototype boundary drawn deliberately narrow:
- Interaction. A gesture-control layer captures simple movement and relays interaction commands to the renderer.
- Software. A JavaScript flow accepts and edits structured 2D floor-plan information, translates it into a 3D scene, and renders it through WebGL, with a desktop runtime around Electron and Node.
- Visualization. The rendered scene is split into the views a reflective pyramid arrangement needs, so a spatial model appears that several people can inspect at once.
The workflow
Take the plan in
A 2D interior floor plan is uploaded and editable as structured information, not as a flat image.
Translate it
The structured plan is mapped into WebGL geometry, which is where a 2D drawing becomes something with height and depth.
Prepare the views
The scene is projected into the four synchronised viewpoints the reflective display geometry requires.
Hand over the controls
Simple gesture commands manipulate the model, so the person talking is the person moving it.
Engineering decisions that mattered
- A reflective display rather than headsets. Headsets solve the spatial problem and break the conversation: they cost more, and they isolate whoever is wearing one at the moment several people need to be looking at the same thing.
- The plan is structured data mapped into WebGL geometry, not a model rebuilt by hand. Anything a person has to re-draw after an edit stops being used after the second edit.
- Plan editing, rendering, display and gesture are four replaceable layers. A different output format reaches one of them and stops, which is the only reason a prototype like this can survive a change of display hardware.
- Gesture hardware relays to the renderer through its own boundary, so the interaction method is a layer rather than a dependency.
- The prototype scope was drawn narrow on purpose. Exterior design, headset VR, true laser holography and complex gesture combinations were all left outside it, because the thing worth proving first was whether the core interaction worked at all.
Operational outcome
The deliverable established a coherent architecture for the whole path from floor-plan input to interactive spatial visualization, across the software, display and interaction layers a practical prototype needs. What was deliberately left outside that boundary is as much of the result as what was inside it:
- exterior building design
- VR and AR headset integration
- true laser holography
- complex multi-input gesture combinations
- broad cross-platform continuity
Scope and status
System design and prototype architecture. It was not deployed to production and there are no commercial performance figures. The architecture practice it was designed for is not named here.
The capability this draws on
See the thinking behind it
See the interface studies and rendered visualisations
Other work
Bring the problem, not a specification
Send a paragraph about the workflow that is not working. We reply within two working days with questions, a rough shape, and an honest answer on whether we are the right people for it.
Discuss a problem