Egress

Egress is a real-time building design platform using entirely deterministic simulations to visualize crowd flow and congestion, with AI analyzing layouts and suggesting improvements.

Comment

Egress

Egress is a collaborative building design platform that uses deterministic pedestrian simulations and AI-powered analysis to help understand how people move through physical spaces.

How It Started

Our original idea was actually quite simple: if a fire or another emergency happened in a building, could everyone safely evacuate within a certain amount of time? How much does the layout of the building affect that outcome, and could we use AI to intelligently suggest improvements?

That led us to a much bigger question -- how do we realistically simulate people moving through a building in the first place?

We didn't want to create an animation of dots following predefined paths. We wanted each person to make their own decisions, respond to congestion, and interact with the environment around them. We also wanted to be able to change the building and measure the difference without introducing randomness that made comparisons meaningless.

That's where Egress started taking shape.

Building the Simulation

We started by creating our own pedestrian simulation engine in TypeScript, drawing from simplified social-force models of pedestrian movement. Some of our earliest ideas came from watching pedestrian and particle simulations on YouTube. What really interested us was realizing that we could describe much of the movement using relatively simple differential equations.

At its core, our model calculates each pedestrian's acceleration from three influences: their desired direction of movement, repulsion from nearby people, and repulsion from walls.

$$ a_i = \frac{v_i^0 \hat{e}_i - v_i}{\tau}

  • \sum_j A e^{(r_i+r_j-d_{ij})/B} \hat{n}{ij}\phi{ij}
  • A_w e^{(r_i-d_w)/B_w}\hat{n}_w $$

The first term moves someone toward their preferred walking speed and direction. The second represents interactions with nearby pedestrians, and the third prevents people from walking into walls. We integrate these forces at a fixed timestep, with additional collision handling and capacity limits for doors and exits.

Each pedestrian is treated as an individual simulated agent, with their own position, velocity, preferred walking speed, destination, and behavioral characteristics. They navigate using shortest-path distance fields, while their movement responds to the surrounding environment.

One of the more interesting problems we encountered was how people decide which exit to use.

Initially, our simulated pedestrians would repeatedly switch between exits as queues formed, sometimes creating entire crowds that changed direction at once. Technically, they were following the shortest expected route, but the behavior wasn't particularly believable.

We ended up developing a weighted decision system around three characteristics:

  • Attention span: How frequently someone reconsiders their route. Not everyone notices congestion or changes their mind at the same time.
  • Patience: How long they're willing to wait before seriously considering another exit.
  • Waiting weight: How strongly someone values avoiding a queue compared to taking a longer walking route.

We use those characteristics to calculate a perceived cost for each available exit:

$$ C_e(i)=\frac{D_e(x_i)}{v_i} +\kappa_i W_e(i) \left(1+\mathbf{1}_{e=e_i}\min\left(1,\frac{w_i}{P_i}\right)\right) $$

In simpler terms, the cost combines walking time and perceived waiting time. The waiting penalty depends on the person's individual waiting weight, how many people are already committed to that exit, and how close they are to running out of patience. Attention span determines when they reconsider that decision.

These characteristics vary between individuals using seeded distributions. Pedestrians also develop some commitment to their decisions instead of immediately switching direction whenever another route looks slightly faster.

The result is a more interesting crowd simulation where congestion and individual decisions can influence one another.

Just as importantly, the engine runs at a fixed 10 Hz timestep and is deterministic for the same inputs. This lets us rerun scenarios with identical starting conditions and isolate the effects of changes to the building.

It's still an experimental model, not certified evacuation software; we're interested in understanding and comparing how layouts behave.

From Simulation to Egress

Once we had the beginnings of the simulation engine, we needed an environment for it to operate in.

That led us to build a custom geometric building editor. Users can draw walls, create rooms, place doors and exits, and modify the layout directly in the browser. We use the same underlying building model for both our 3D editor and the simulation, translating its geometry into a computational grid when needed.

From there, other features started emerging naturally.

We needed to see where people were getting stuck, so we added density and congestion heatmaps. We wanted to understand how problems developed over time, so we added simulation replay and a timeline. We wanted to test different initial conditions, so we added population distribution controls.

And because designing a building is often collaborative, we built the application's backend around SpacetimeDB. It manages projects, synchronized edits, permissions, simulation jobs, and saved results. Our simulation worker performs the actual calculations, while SpacetimeDB keeps the application and its users synchronized.

A lot of what Egress eventually became came from solving problems we encountered while building the original simulation.

Bringing AI Into the Process

The other half of our original question was how we could intelligently improve a building's design.

We decided that an AI model shouldn't be responsible for inventing simulation results. Instead, it should be able to use the simulation engine as a tool.

Using NVIDIA Nemotron, we built an analysis workflow that can inspect a layout, investigate congestion, test possible structural changes, and compare their measured effects.

For example, in one of our development scenarios with 150 simulated occupants, Nemotron proposed widening an exit from 1.2 to 1.8 meters. Running the modified geometry through our simulation reduced the modeled evacuation time from 113.8 seconds to 73.7 seconds -- roughly a 35% improvement.

The interesting part is that Nemotron didn't predict those numbers -- it tested the modification using the same simulation engine we built. The user can then review the proposed change and decide whether to apply it.

That distinction became central to how we approached AI in Egress. We wanted something that could investigate problems using real tools, rather than just explain what might happen.

Where We Want to Take It

Our initial interest in fires and emergencies is still a big part of where we want Egress to go.

We're interested in extending the simulation to model fire spread, smoke, airflow, and HVAC systems, eventually allowing us to analyze how these factors interact with the people inside a building.

We also want to explore more advanced human behavior and multi-floor evacuation, and eventually move beyond simply analyzing existing layouts.

The longer-term idea is to let someone describe what they want a building to accomplish -- whether that's evacuating a certain number of people within a target time or reducing congestion in a busy corridor -- and let Egress help explore designs that satisfy those constraints.

We started by asking whether a building could be evacuated quickly enough. Over the hackathon, that turned into a much broader experiment in making the behavior of physical spaces something we can visualize, measure, and improve.

Built With

TypeScript, Next.js, React, Three.js, Node.js, SpacetimeDB, NVIDIA Nemotron, custom geometry processing, pedestrian simulation, and real-time visualization.

Sponsor Challenges

SpacetimeDB: We use SpacetimeDB as our application's authoritative backend for collaborative edits, project persistence, permissions, simulation coordination, replay data, and AI proposals. Its real-time subscriptions allow connected users to work with the same building and observe shared simulation results.

NVIDIA Nemotron -- Beyond a Chatbot: Nemotron powers our tool-using analysis agent. Rather than generating hypothetical answers, it inspects geometry, identifies problems, tests design modifications using our deterministic simulation engine, and presents measured improvements for user approval.

Built With

Share this project:

Updates

Submission history