ArchionLabs
An AI platform that turns a text prompt into a 3D building, simulates how people move through it, and checks it against building regulation.
Full Stack Developer · Sep 2025 – Mar 2026 · Team of 6 · Hult Prize IIT finalist
The problem
Architectural design still runs on manual interpretation. An architect drafts in 2D, then rebuilds the same building by hand in 3D. That conversion can take days, and everything downstream waits on it.
The larger gap is what comes after. There is no practical way to know how people will actually move through a space until it exists. Circulation and accessibility get judged by experience rather than evidence, so bottlenecks and compliance failures surface after construction, when fixing them is expensive.
In Sri Lanka this is sharper. Advanced simulation tools are largely out of reach, and no automated mechanism exists for testing a design against local accessibility regulation. Clients receive 3D files they cannot open without specialist software, so the people who most need to understand a design are the least equipped to see it.
- Architects spend days converting 2D drafts into 3D models
- Accessibility engineers cannot evaluate compliance without simulation, especially in public buildings
- Clients misread rigid design files or lack the software to open them at all
- Students have no accessible way to experiment with modelling, simulation, or compliance
Where existing tools fall short
We studied six tools covering the pieces of this workflow. Each solves one part well. None connects them.
| Tool | Strength | Limitation |
|---|---|---|
| Meshy.ai | Fast text-to-3D and image-to-3D generation | Inconsistent topology and limited detail on complex prompts. Not architectural: no walls, no rooms, no regulation awareness |
| Hyper3D | High-fidelity reconstruction from photos and point clouds | Accuracy degrades sharply with incomplete viewpoint coverage. Requires the building to already exist |
| MassMotion | Rigorous agent-based crowd and evacuation simulation | Requires expert parameter tuning and calibration. Behavioural assumptions oversimplify real decision making |
| Autodesk Viewer | Browser-based viewing and annotation, no install | Slow rendering on large files, limited concurrent editing, account and file size barriers |
| Spline | Browser-native 3D design with real-time collaboration | Degrades on complex scenes. Built for interactive web visuals, not buildings |
| Revit | Industry-standard BIM with a deep component library | Steep learning curve, heavy hardware requirement, poor interoperability, slows on large projects |
Nothing goes end to end. Generation, simulation, compliance, and sharing each live in a separate tool with a separate file format. The handoffs are where the time goes.
Simulation needs a specialist. The tools capable of real pedestrian modelling require expert calibration, which puts them out of reach of the architects who would benefit most.
Nothing knows local regulation. Compliance checking against Sri Lankan UDA standards existed in none of them. It remained a person reading a document against a drawing.
The solution
ArchionLabs is a browser-based platform covering the full loop: generate, simulate, check, share. Five modules, no installs, no file conversion between stages.
Archion Build
Converts a natural language prompt or an uploaded plan into a parametric 3D model.
Archion Sim
Simulates pedestrian crowds moving through that model in real time.
Archion Insight
Audits the result against Sri Lankan UDA regulation and writes the report.
Archion View
Shares high-fidelity models through cryptographically secure links.
Archion Community
Hosts crowdsourced reusable 3D templates.
My scope
I built the generation end and the behaviour engine: Archion Build in full, and the MARL engine inside Archion Sim. The navigation graph and A* pathfinding were a teammate's work.
How we built it
Archion Build
Generation runs in four stages
Claude parses the prompt and extracts room requirements, with a regex fallback if the response fails to parse. Requirements go to a LayoutSolver that uses a packing algorithm to place rooms inside the building boundary. The project and its chat history persist to PostgreSQL, then sync to the dashboard.
The detail that makes it a product rather than a demo: when an existing floor plan is passed with the request, stage one becomes a modification prompt instead. The existing plan JSON goes to Claude, which returns a revised version, bypassing the solver entirely. Generating and editing share one endpoint, and each revision is stored as a new project rather than overwriting the last.
Model choice came down to context length
Floor plan JSON runs 50KB to 200KB, and every modification prompt has to carry the whole object. Claude's 128K window is what makes conversational editing viable at all. Vision handles extraction from uploaded image and PDF plans, and in practice it returned structured JSON without Markdown wrappers consistently enough to parse directly. The service switches between model variants through an environment variable: Haiku for fast iteration, Sonnet where layout quality matters more than latency.
The 2D editor renders to canvas, not SVG
With hundreds of elements in a scene, DOM manipulation cannot hold 60fps. The editor runs a requestAnimationFrame loop at 60fps, stores all geometry in world coordinates in metres, and applies a pan and zoom affine transform at render time so the underlying model stays in real units. Eight tools run off a single Zustand store, chosen over Redux for lower overhead on a canvas that rebuilds every frame.
Two decisions mattered more than their size. Architectural symbols follow ISO 128/7519, so a door renders as a leaf line from the hinge plus a quarter circle swing arc, which is what an architect expects rather than an approximation. Those drawing functions live outside the React tree as standalone canvas functions, which made them independently testable. Undo and redo use structuredClone snapshots capped at fifty entries, so shared mutable references never leak between states.
Service boundaries and auth
Each backend is an independent FastAPI application with its own database config, Dockerfile, and test suite, communicating only over HTTP and sharing nothing but the Supabase JWT secret. A failure or deployment in one cannot affect another. Auth is exposed as two FastAPI dependencies: a strict one that raises 401 on a missing or invalid token, and a lenient one returning None for routes that tolerate anonymous use.
Archion Sim
Behaviour is learned, not tuned
The engine models pedestrians as intelligent agents with individual objectives, spatial knowledge, and decision-making capability, rather than as particles driven by hand-fitted physics constants. Deep learning models handle the high-dimensional state space required to run many agents at once, computing pathfinding and collision avoidance in real time as agents move through the 3D geometry.
The reason this matters for the product: a deterministic model only produces the behaviour you encoded, and the entire value of the tool is showing an architect something they had not predicted about their own design. Congestion and bottleneck formation have to be able to emerge rather than be scripted.
The tradeoff is real. Training time replaces tuning time, runs are harder to reproduce, and diagnosing a policy that behaves oddly is far slower than adjusting a constant.
Simulation streams instead of blocking
Running to completion before responding would leave the client waiting for the length of the run. Instead the start endpoint spawns the engine in a background thread and returns immediately. The client subscribes over SSE through the browser's native EventSource API and receives frames as they compute, each carrying the position and type of every agent. On a done event, the frontend triggers the compliance and analytics fetches and enables PDF export.
This required infrastructure work alongside application code. Nginx sits in front as a reverse proxy and had to be configured to hold SSE connections open rather than buffering them, which is the default and silently breaks streaming.
Agents are rendered procedurally
Pedestrians are generated humanoid meshes updated per frame through React Three Fiber's useFrame. Position smoothing uses frame-rate-independent exponential interpolation so movement stays natural regardless of playback speed. Walking animation is procedural: leg and arm geometry driven by sinusoidal functions on a per-agent cycle counter. That avoids shipping rigged character assets entirely.
Why the compliance engine is hybrid
Built by a teammate, not me. Worth describing because it is the architectural decision that makes the platform trustworthy.
Handing a floor plan to an LLM and asking whether it is compliant produces confident, wrong measurements. So the pipeline splits the work. Deterministic algorithms scan the 3D spatial data and compute corridor widths, door clearances, turning circles, and egress distances mathematically. Those measurements are compared programmatically against a structured JSON database of Sri Lankan UDA regulation: corridors at least 1.2m, doors at least 0.75m, turning spaces at least 1.5m diameter, ramp gradients at most 8.3%, bottleneck density at most 2.0 persons per m². Violations are weighted by severity, producing a score out of 100.
Only then does Claude enter, and only to contextualise violations that have already been established mathematically and to write human-readable recommendations. The model never measures anything. That separation is what removes hallucinated numbers from a compliance report, which is the difference between a demo and something an architect could act on.
Engineering practice
The codebase is a monorepo with five root directories, one per module. Two protected branches: main for production, develop for integration. Nobody pushed directly. Every contributor worked from a personal fork and opened a pull request for peer review before merge.
CI runs on every push and PR to both branches as six parallel jobs: three Python backend suites running flake8 and pytest against a temporary SQLite database, a Node syntax check, a matrix build of all four Next.js frontends, and a Docker build validating every backend image. CD is path-filtered so documentation-only commits do not trigger a deploy, and gated on CI passing. Deployment goes over SSH to a DigitalOcean droplet, rebuilds changed containers, prunes dangling images, then runs health checks against all four service endpoints before the deploy counts as complete.
Results
All 21 defined functional requirements passed, tested through a mix of pytest, API tests, and manual end-to-end runs. Among them: generating a valid five-room plan from a natural language prompt, extracting a plan from a scanned PDF, running a simulation from an uploaded .glb model, detecting a corridor width violation at correct severity, and producing an 11-page PDF compliance report.
| Generation, Haiku | 0s median |
| Generation, Sonnet | 0s median |
| Full JSON mode, complex plans | 0s median |
| Core structural conversion | Under 1s |
| 2D editor render loop | 0fps |
| Test coverage, Build service | 0% |
| Test coverage, Viewer | 0% |
The Build module carries 33 passing tests across generation endpoints, ORM models, and the geometry engine, including assertions that the packing algorithm produces correct output dimensions and that wall generation is geometrically valid. A shared pytest fixture swaps the FastAPI database dependency for an in-memory SQLite session so tests never touch production data. Verified across Chrome, Firefox, Safari, and Edge on macOS and Windows; Safari required a WebGL 1.0 fallback path for certain Three.js material types.
What I would change
The AI-driven simulation mode has a hard ceiling. Network latency to the inference API limits it well below what the local physics path handles. Moving waypoint inference to a locally hosted small model, even at reduced quality, removes the ceiling and the per-simulation cost at the same time. This is the first change I would make.
The compliance checker scales quadratically. An all-pairs parallelism check across wall segments audits a 150-segment building in around 0.8 seconds, which is fine, and a much larger building would not be. Spatial partitioning fixes it before it becomes a problem.
Rendering degrades on lower-end GPUs. Complex unoptimised models drop below target frame rate. Level-of-detail switching and Draco geometry compression were the planned next step and did not make the prototype.
The geometry engine only handles orthogonal space. No curved walls, no diagonals, no L-shaped rooms, no multi-storey generation with stair mapping. That is a limitation of the packing approach, not a missing feature.
Stack
- Next.js
- React
- TypeScript
- Tailwind CSS
- Zustand
- Three.js
- React Three Fiber
- GSAP
- FastAPI
- Python
- SQLAlchemy
- Pydantic
- PostgreSQL
- Supabase
- Claude API
- Trimesh
- Shapely
- scikit-learn
- Docker
- Nginx
- GitHub Actions
- DigitalOcean