.jpg)
This month, Sofar launched the Wayfinder Voyage Simulator, a new feature that lets captains and operators instantly test and compare voyage plans in real time. It runs full-physics voyage simulations right in your browser, using vessel models and dynamic forecast data that mirror real-world conditions. (We’ll come back to those vessel models below). You can tweak a route, change power settings, and immediately see how it affects arrival time, fuel burn, and weather exposure.
Our team built the simulation engine behind it. On paper, “simulate how a ship moves through the ocean” sounds straightforward. In practice, this meant solving a hard engineering problem: taking a high-fidelity physics engine built for the cloud — one that models ship motion, weather, and fuel use with thousands of calculations — and making it run smoothly and accurately, inside a web browser.
Running these models on the server is easy(ish). We’ve always done that for daily voyage guidance. But if a user wants to move a waypoint or change an input and see immediate feedback, cloud-based compute isn’t responsive enough. A few minutes of wait time is fine for scheduled routing but not for real-time exploration. We wanted something closer to instant.
Here’s how we made it work.
Every vessel we work with has its own Vessel Performance Model (VPM), a digital twin that describes how that specific ship behaves in different conditions.
We start with physics: how the hull interacts with the water, how propellers generate thrust, how drag and wind resistance scale with speed. Then we customize those models with each ship’s real-world data current and historical; months or years of “noon reports” paired with our historical weather archives.
By comparing how a ship actually performed against what physics predicted, we calibrate the model’s coefficients until it can reproduce the vessel’s past behavior with high accuracy. That’s the foundation for all forward-looking simulations: once we know how a ship behaves, we can predict how it will behave under tomorrow’s weather.
We knew we wanted real-time voyage simulation. The question was whether a web browser could actually handle it. During a company hackathon, we decided to find out. We managed to compile a minimal subset of our simulation logic into WebAssembly (Wasm) and integrate it into Wayfinder. To our surprise, something that used to take minutes now ran in milliseconds.
Of course, hackathon demos are the easy part. Turning that prototype into something we could ship to real users meant months of work.
First, we had to port our physics models from Python to Rust. Our original models relied heavily on libraries like NumPy and SciPy which are great for server-side math, but impossible to compile to Wasm. The Rust ecosystem gave us the speed and control we needed, but it meant rewriting thousands of lines of code from scratch, including our own numerical solvers and optimization routines.
The next challenge was data handling. On the server, we can stream in weather data as needed; browsers can’t. So we had to decide how much weather data to preload, at what resolution, and how to cache it efficiently. We worked closely with the Weather and Application teams (yes we have our own Weather team) to find the right balance between simulation fidelity and bandwidth/memory constraints.
Then there was geometry. Our simulator needs to know when a ship enters a special zone like an emissions control area or a slow-speed corridor. On the backend, we can use C++ libraries like GEOS, but since that's not available in the browser, we had to rebuild many of our geometry algorithms from scratch, leaning harder on the Rust geo crate.
Each of those steps could have been its own project. Together, they became a masterclass in simplifying complexity without losing precision.
Of course, none of this happened cleanly. Every time we solved one problem, another three appeared.
Early on, we discovered that parts of our simulation depended on Python optimization functions from scipy.optimize that had no direct Rust equivalents. Thankfully, most of those functions were used during model training, not in real-time simulation, so we could safely exclude them. Still, tracing through years of code to confirm that was its own archaeology project.
Weather data was another challenge. On the server, we can load data lazily as needed; in a browser, everything must be preloaded and managed up front. Initially, the Wayfinder web application didn’t even have access to the same resolution or variables our simulations required. Working across teams, we expanded the dataset just enough to maintain accuracy without killing performance. A balancing act for sure.
And then there were the overlapping geometry zones: emissions areas, traffic corridors, whale zones, and so on. Each imposed different rules, and we needed to figure out how they overlapped. The algorithm we used from GEOS couldn't be compiled for the browser, so we first tried a brute-force approach using Rust geo, but this turned out to be buggy and slow. Eventually, we found a workable path: calculating a constrained Delaunay triangulation of the zones' vertices and edges, and building the overlapping geometries from there. This was just fast and precise enough, and buildable using libraries we already had available in Wasm.
That’s what we mean by fractal complexity: each fix exposed new edge cases, new assumptions, and new layers of the system we had to understand.
Today, the simulation that once took minutes to compute now runs in about 100 milliseconds, performing thousands of physics calculations, weather interpolations, and cost evaluations, all inside a browser.
For users, it feels effortless: move a waypoint, change a setting, and see results immediately. Under the hood, it’s a fully dynamic physical simulation that integrates live weather forecasts, vessel models, and cost logic — the same core that powers our optimization engine.
For our team, it was a chance to rethink how far we could push real-time maritime modeling. It showed us that browser-based physics simulations aren’t just possible, they’re fast, reliable, and incredibly powerful when paired with modern compilers and smart architecture.
Here’s what I took away:
1. Real physics can run in real time. With modern compilers and smart data tradeoffs, you can get true physical modeling performance in environments that used to be off-limits.
2. Porting is a chance to reconsider and clean up. Translating Python to Rust wasn’t just about compatibility it forced us to clarify what our models actually did, tighten assumptions, and drop unnecessary complexity.
3. A fresh start is the best start. Rewriting that much core code in just nine months was no small feat. But sometimes, starting over is the answer. No one wants to do it, but it let us build something faster and more capable than we thought possible.
And if solving problems like this sounds like your kind of challenge, we’re hiring.
Otherwise check out the latest demo of Simulator
👉 Wayfinder Voyage Simulator Demo Library
Author: Andrew Pendleton
Contributors to the project: Russell White, Camille Teicheira, Bruno Vacherot, Jasper Speicher, Ryan Hamley, Julius Alexander IV
