ARCHITECTURE

One Rust engine, two frontends

opsrocket-core

Geometry, the component model, exact shape integrals (shell volume/CG, MAC) and the materials database. ~1.5k lines, zero I/O — which is exactly why the whole engine compiles to WebAssembly.

opsrocket-io

.ork (zip + XML) reader and writer, plus the RASP motor parser. Motors are selected by reproducing OpenRocket's exact thrust-curve MD5 digest, so a file's motor resolves to the identical curve OpenRocket would pick.

opsrocket-sim

The ~4k-line heart: mass · CG · moment-of-inertia, Barrowman aerodynamics (incl. getWorstCP and tube-fin aero) and an RK4 6-DOF flight integrator with staging, clustering and recovery events.

opsrocket-view

The shared DTO boundary. One schema-driven editing surface (OpenRocket's ~40 dialogs collapsed into one generic panel), one set of view/stability/flight DTOs — consumed identically by every frontend.

opsrocket-web

A thin stateful axum HTTP API — the original /workspace backend. Every endpoint has a 1:1 WASM twin, so the same workbench runs either against this server or fully in-browser.

gui + Tauri + WASM

One React · Vite · Three.js workbench, three ways: against axum, in-process via Tauri (native desktop), or 100 % client-side on the 428 KB WASM build with the motor DB embedded — no server at all.

No server required

Because opsrocket-core carries no filesystem or network code, the entire simulator — loader, mass, aerodynamics, 6-DOF, .ork writer — compiles to a single 428 KB WebAssembly module. /workspace was verified running with the axum server killed: load a design, edit and add components, undo/redo, assign motors from the embedded database, fly a full 6-DOF simulation, and save back a valid .ork, all in the browser tab with zero network calls.

opsrocket-view is the single boundary every frontend speaks to. This site's /workspace is that workbench running entirely on the WASM build — open it and edit a real design with no backend in the loop.