FAQ
What does Loft do?
It imports an OpenRocket .ork design and simulates the flight in your browser — apogee, velocity, Mach, stability, and recovery — and compares against the numbers OpenRocket stored in the file. No accounts, no ads, no tracking.
Can I build a rocket from scratch, without a file?
Yes — press Start a new design. Loft opens a stable 54 mm sport rocket on a common 29 mm H motor, already flying: a healthy ~1.5-caliber static margin, a real apogee, mass, and recovery. From there the same edits an imported design gets — nose shape and length, body length and diameter, airframe material, fin size, count, sweep, thickness, position, cross-section and material, nose ballast, motor swap, motor cluster count, parachute size — reshape it and re-fly instantly. Fin position slides the fins fore or aft along the airframe: moving them aft moves the centre of pressure aft and stiffens the static margin, the classic trim complement to nose ballast (which shifts the centre of gravity forward). You can also add a boattail (a tail cone: set a length and an exit diameter narrower than whatever the tail presents — the field states that limit) to cut the base drag, the single largest drag source on a blunt-based rocket, add a payload / av-bay mass — the electronics, tracker, or nose weight a real rocket carries — at a station of your choice (leave the position blank and it sits mid-body), which adds to the loaded mass and moves the CG toward it, or switch to dual-deploy recovery (set a main-deploy altitude and a drogue diameter): the main then opens low over a drogue that controls the fall from apogee — the standard high-power setup that lands soft while cutting how far the wind carries it. Give it a name in the field beside Import another, and that name becomes the results title and the saved .ork filename. A design you build enters the exact same internal model and solver an import does, so every tool (sweeps, Monte-Carlo, the second-opinion engine) works on it just the same. The from-scratch builder grows from here; today it starts you from a sound baseline to tailor rather than a blank slate.
My design has several body tubes or fin sets — which one do the edit fields change?
The one you pick. Click a part on the side-view diagram, or its row in the parts table beneath it, and the fields that describe that kind of part aim themselves at it: Body length then resizes that tube and no other, and the fin fields describe and change that fin set. Most real designs are several tubes end to end — a payload bay, a coupler, a motor mount, a booster — so without this every tube but the longest was out of reach, and every fin set but the frontmost.
When there is more than one to choose from, the editor says which part it is holding— by the design's own name for it where that name tells it apart, and otherwise by where it sits on the airframe, since real files tend to call every tube “body” and every fin set “fin set”. Two edits are deliberately wider than one part, and both say so: Body diameter reads the tube you picked but scales the whole outer airframe to that caliber, so the mould line stays faired rather than stepping at one tube; and Fin position slides every fin set together, keeping the design's spacing. Picking a part to read it never moves an edit you already set on another — the aim only follows a pick for the fields that part drives — and the aim is saved with your session, so a reload comes back pointed at the same part.
You can also remove the part you picked, and put it back: the panel offers to remove it by name, and a Restore control brings the last one back — named too, because the part is no longer on the diagram to remind you what you took. A removal carries everything mounted inside the part, so deleting a body tube takes its motor mount, fins and parachute with it. The one thing Loft refuses is removing the last body tube, and it says why rather than flying a rocket with no body.
Is my design uploaded anywhere?
No. Parsing, the motor database, and the whole simulation run on your device. Nothing about your design leaves the browser. The one optional network call is the “re-fly for today's weather” feature, which sends only a launch-site latitude/longitude to Open-Meteo — never your design.
Does Loft remember the design I had open?
Yes — the last design you opened, the units you chose, the motor configuration you were flying, and any what-if edits are kept in this browser's own storage, so a reload or a tab the phone reclaimed picks up where you left off. That matters most at the pad, where re-importing means finding the design file on a phone that may not have it. It is stored on your device only, alongside the theme choice — there is no account and nothing is uploaded. Loft says so on screen when it restores a session, and Start fresh (or Import another) ends that session immediately — but not irreversibly: the import screen then offers to pick that design back up, with the what-ifs you had set on it, until you leave another one. One level, so it is a way back from a mis-click rather than a history to curate. It does not carry today's weather, which no saved session does — a reload loses that too.
Separately, the last few designs you have ever opened stay on a shelf under Your designs on the import screen, so a build with several variants on the go can be picked back up without the files. Those are the designs themselves, not your what-if edits, and they outlive Start fresh — each has its own to remove it, and clearing site data removes the lot. Same rule as everything else here: this device only, never uploaded.
Can I trust it for a waiver or a cert flight?
Treat every figure as an estimate to verify independently, not as authority. Loft shows the numbers and their assumptions; it never issues a go/no-go. The motor's printed data and your RSO are authoritative. See the limitations log.
Will my fins flutter?
Loft estimates it. Fins have their own stiffness, and past a critical airspeed — the flutter boundary — they start to oscillate and can tear off, a leading cause of lost fins on fast flights. The stability panel shows a Fin flutter (est.) speed and the margin — how much headroom there is between that speed and the fastest the fins actually go — and Loft cautions when the margin is thin (keep it ≥ 1.5×) or warns outright when the peak airspeed is past the estimate. It uses the fin's planform, thickness, and material stiffness, checked against the real air density at every altitude the rocket climbs through. It's a preliminary-design estimate (the simplified NACA TN 4197 method), good to roughly ±20% — so treat it as a “design your fins with room to spare” heuristic, not a guarantee. When the margin is thin, Loft doesn't just say “thicken the fins” — it names the thickness that would reach a healthy 1.5× margin (the flutter speed rises with the 1.5 power of thickness, so it's a direct calculation), erring a touch thick so the flown result lands just above the target; a shorter span or a stiffer material gets there too. Neither OpenRocket nor RockSim reports any of this. See Methods.
Why doesn't my apogee match OpenRocket exactly?
Mostly the drag model. Loft's subsonic drag buildup is simpler than OpenRocket's, so it usually predicts a slightly higher apogee. Fast (transonic) flights differ more and are flagged as extrapolated. The Validation page shows the comparison on your own file; Methods explains the model.
Which motors and file formats are supported?
OpenRocket .ork files (and gzip-wrapped or raw OpenRocket XML), RockSim .rkt files, and RASAero II .CDX1 files. Neither format embeds the motor's thrust curve — it's referenced by manufacturer and designation — so Loft resolves it against a bundled set of real ThrustCurve.org curves. If your motor isn't in the set, Loft tells you rather than guessing. A RASAero design carries no materials or per-part masses — it is an aerodynamics tool, and the flyer types in one launch weight and CG — so Loft flies the weight and CG the file states, with the motor's own mass separated out. RocketPy import is planned, not in yet.
How does a RockSim .rkt import differ from an OpenRocket one?
The flight itself is identical — both formats are translated into one internal model that the simulator flies, so the physics doesn't know which tool you drew in. The one difference is mass: a .rkt stores RockSim's own per-part masses, so Loft flies those exact figures rather than recomputing them from geometry (an .ork stores no per-part mass, so there Loft computes it). A deliberate per-part CG override is carried through as well — a nose trimmed to a measured centre of gravity flies with that CG, and so the right stability margin, the same way an OpenRocket override is honoured (a value RockSim merely cached, or one that falls outside the part, is ignored as not a real trim). Each RockSim stored simulation becomes a selectable motor configuration, just like an OpenRocket flight configuration. See Methods.
My design has several motor configurations — can I compare them?
Yes. When a .ork carries more than one flight configuration (OpenRocket's stored simulations — say the same airframe on an H128W and a G40W), Loft shows a motor configuration picker above the results. Each entry is labelled with its motor(s) and the apogee OpenRocket stored for it; choosing one re-flies that configuration and compares against its own stored numbers, so you can see how each motor changes the flight. Two entries never read alike — where the motor and apogee coincide, the run's own name and its position in the file are added — and an entry whose stored run the tool marks outdated or not run says so, since that figure describes an earlier version of the rocket rather than the design on screen. The bundled “Motor comparison” example shows it.
Can I try the design on a different motor?
Yes. In the Design workspace, the Motor picker lists the bundled motors of the same casing as the one this design already flies, grouped by class. That casing demonstrably fits the rocket; a mount's stated bore would not establish the same for every motor that would physically go in it, so the narrower claim is the one made. Choose one and Loft re-flies the same rocket on it, so you can compare apogee, speed, rail-exit velocity, and stability across motors without editing the file — the classic “what would a J do here?” A cluster keeps its motor count. A compact What-if vs design panel above the results shows each figure as the design's own value → the swapped value with the change, so the effect is legible at a glance. Because it's a hypothetical change, the OpenRocket comparison is hidden while a swapped motor is selected; pick “Design motor” to fly the original again.
How are the results laid out?
Once a design is flying, the results split into four workspaces, each at its own address — /flight, /design, /sweep and /validate — on one row of links under the design summary. Each is a focused view rather than one endless scroll, and each is a real page: you can bookmark one, share the link, and use the browser's Back and Forward between them. Flight holds the simulated flight: the summary numbers, the trajectory and the plots. Design is the rocket — the to-scale, editable side-view and the part-by-part mass & balance. Sweep is for varying one thing and seeing what it does: the motor and parameter sweeps and the Monte-Carlo dispersion. Cross-check is every “does anything else agree?” surface in one place — the numbers the file's own tool stored, its step-by-step flight overlaid on Loft's, and the independent RocketPy second opinion, which used to be a workspace apart from the other two. The design summary and any flight warnings sit above that row, shared by every view — and moving between workspaces never interrupts them: a dispersion left running keeps running while you look at the diagram.
Can I compare all the motors that fit at once?
Yes. In the Sweep workspace, Compare fitting motors flies your airframe on every bundled motor of the same casing it already flies — all at once, on your device — and lays them out highest-apogee first: apogee, max speed, rail-exit velocity, thrust-to-weight, stability margin, fin-flutter margin, and the optimum ejection delay for each, with your design's own motor marked. It's the fast way to answer “which motor gets me to my target?” and to see the trade — a bigger motor climbs higher but sits heavier at the tail, trimming the stability margin, while rail-exit velocity and thrust-to-weight show which motors clear the rail cleanly and the flutter margin flags a punchier motor that would fly the fins toward their flutter speed. The delay column is the burnout-to-apogee time for each motor, so you can see at a glance which delay to buy or drill — a faster motor coasts longer and wants a longer one. Any active nose-ballast or geometry what-if is applied to every motor, so you're comparing the design you're actually looking at. Each row is a ballistic ascent under the launch conditions in force — the design's own stored setup, with whatever you have changed under Conditions on top, so shortening your rail moves every rail-exit figure in the table. Surface wind is the one that does not: a ballistic ascent has no recovery to drift, so the rows are identical with it set and unset. These are estimates to check against the motor's printed data and your rail, never a go/no-go.
Can I see a whole range at once — a response curve?
Yes. In the Sweep workspace, Sweep a parameter varies one variable — fin span, fin thickness, fin position, nose length, body length or diameter, or nose ballast — across a range and plots how a metric responds: apogee, max speed, rail-exit velocity, stability margin, or fin-flutter margin, switchable on the y-axis. A marker shows the design's own value, so you can see at a glance where more span buys stability (and what it costs in apogee), how a longer body trades altitude for margin, how sliding the fins aft stiffens the margin at almost no apogee cost, exactly how much nose weight buys the margin you want — or, sweeping fin thickness against the flutter margin, the thinnest fin that still clears the flutter boundary with room to spare. It's the response curve behind a single edit — every other active what-if (a swapped motor, the other dimensions) is held fixed, so the curve isolates the one variable. Every point is a real ballistic flight run on your device; read them as estimates to verify, not a go/no-go.
How high will it really go, and where will it land?
In the Sweep workspace, Flight dispersion (Monte-Carlo) flies the design a few hundred times with the motor impulse, dry mass, aerodynamic drag, rail angle, and wind jittered around their nominal values, and shows the spread instead of a single number: the apogee band you can expect (5th to 95th percentile), the peak-speed band, and the radius from the pad that contains 95% of the landings — the recovery area to plan for. It flies the launch conditions in force — the design's stored setup with whatever you changed under Conditions on top — and you set the one-sigma spread on each input, so the answer reflects your own field. The physics is the same trusted flight each time; the only thing that varies is the inputs, so it's an honest way to see how much your apogee and landing point move under real-world variability — a good gut-check against a waiver ceiling or a field boundary. Enter your altitude limit and it tells you the fraction of the dispersed flights that topped it — the chance of busting your ceiling — so you can size your margin. It runs entirely on your device, and the same design with the same spreads reproduces the same result. It propagates only the inputs you set, layered on top of the model's own limitations (see the drag note), so read the bands as a spread, not an absolute guarantee.
Will it land too hard — and how big a parachute do I need?
Loft reports the descent rate, ground-hit speed, and the landing kinetic energy (½·m·v²— the recovery-adequacy figure many flying fields and waivers quote a limit for, in joules or foot-pounds-force), and flags a firm (>25 ft/s) or hard (>35 ft/s) landing under an undersized canopy. When it does, it also names the fix: the canopy drag area (Cd·A) — and an equivalent diameter — that would bring the rocket down to a gentle ~5 m/s. It's a closed-form goal-seek (the terminal velocity where drag balances weight) using the descent mass, the air density at your field, and the same body-drag term the flight itself descends with, so a canopy sized this way actually lands at that speed. The drag area is the unambiguous answer; the diameter assumes a typical flat-canopy drag coefficient (0.8), so match it to your own chute's rating. A bigger canopy lands softer but drifts farther — the Monte-Carlo above shows how far.
To try a size yourself, use the Recovery size (×) what-if under Design workspace: it multiplies every deployed chute's drag area, so 2 flies a canopy twice as draggy and 0.5 one half the size. Loft re-flies the descent, and the descent rate, ground-hit speed, and drift all move with it — as does the Monte-Carlo landing scatter — while the ascent and apogee stay put. It's the open-ended companion to the sizing readout: the readout names the size for a gentle landing; the what-if lets you explore the trade against drift and deployment speed.
When you've settled on a size, set it for keeps with Main chute Ø under Design workspace: unlike the multiplier, this resizes the design's own main parachute to a real diameter — its heavier (area-scaled) canopy mass and all — so it becomes part of the design and rides along into the exported .ork. Type the diameter the sizing readout named and the rocket flies down at about that gentle speed.
Can I see what adding nose weight would do?
Yes. In the Design workspace, enter a nose-ballast mass and Loft re-flies the design with that weight added at the nose cone — the classic trim for a marginally stable rocket. You'll see the centre of gravity move forward, the stability margin rise, and the apogee drop as the rocket flies heavier, so you can find how much weight buys the stability you want. A What-if vs design panel above the results spells out the trade — how many calibers of stability you gained and how much apogee it cost. Because it's a hypothetical change to the design, the OpenRocket comparison is hidden while ballast is set — the stored numbers describe the original rocket, not the ballasted one.
You don't have to hunt for the number: when the static margin is thin, the stability panel names the nose ballast that would trim it to a healthy 1.5 calibers directly — a closed-form goal-seek, the inverse of reading it off the sweep. And if the fins are too small or too far forward for ballast to ever reach that margin, it tells you so rather than suggesting an impossible amount of weight — the honest fix there is bigger fins or moving them aft, not more lead.
Can I change the design's geometry and see what happens?
Starting to. In the Design workspace, the Fin span, Fin count, Fin root, Fin tip and Fin sweep(the trapezoidal fin's chords and leading-edge sweep), Fin thickness, Fin edge (square, rounded, or airfoil profile), Nose length, Nose shape (ogive, conical, ellipsoid, or a low-drag Haack / Von Kármán), Body length, and Body diameter fields start from the design's own dimensions; change any and Loft rebuilds the rocket and re-flies it — mass, drag, and the centre of pressure and stability all update, and a longer nose or body stretches the whole airframe (everything downstream shifts). Bigger fins — or more of them — move the CP aft and raise the stability margin (the classic trade against nose weight); reshaping the fin chords changes its planform area (and so its drag and centre of pressure); sweeping the fins back carries their lift aft, adding stability without any extra area; thicker fins drag more but raise the flutter margin sharply (it climbs with the cube of thickness), so it's the first knob to reach for when the Fin flutter estimate warns; streamlining the fin edge from square to rounded to airfoil sheds the head-on edge pressure drag, a real apogee gain for the cost of some sanding; and the Fin material picker swaps the stock (balsa, basswood, plywood, G10, carbon, or aluminium), which sets both the fin mass and the stiffness the flutter estimate reads — so if the Fin flutter tool warns, you can see directly what stepping up to a stiffer stock buys; a finer nose (a cone, or a Von Kármán) trims drag — a little subsonically through wetted area, more noticeably as the flight nears the speed of sound where nose shape drives the wave drag; a longer body adds material and weight; and widening the Body diameter scales the whole airframe to a new caliber (keeping the same fins, nose profile, and motor) — a fatter tube has more frontal area and skin, so it drags more and flies lower, and the fixed fins are proportionally smaller, trimming the stability margin. A Surface finish picker sets the whole airframe from mirror-smooth to rough — skin friction is a big share of subsonic drag, so “what does a good paint job buy?” can move the apogee noticeably. The results, the What-if vs design delta, and the RocketPy second opinion all reflect the edited geometry. It's the first step toward a full in-browser builder — editing a component's dimensions and re-simulating live. Because it's a change to the design, the OpenRocket comparison is hidden while any edit is set.
Can I see where my rocket's mass comes from?
Yes. In the Design workspace, expand Mass & balance for a part-by-part breakdown of the design's dry mass — every structural component with its weight, its share of the total, and its centre of gravity from the nose, heaviest first, adding up to the dry total and CG. These are the exact per-part masses the simulator flies, so it's the fastest way to sanity-check an import: a mistyped wall thickness or the wrong material shows up as a row that's obviously too heavy or too light. It's dry structure only — the motor and any what-if add their mass at launch. Where a section states a measured weight for its whole assembly, that figure stands in for everything inside it.
Can I export the numbers?
Yes. The motor sweep, the parameter sweep, and the mass & balance breakdown each have a Download CSV button that saves the table to a file in your chosen units — the motor comparison, the full response curve (every metric across the swept range), or the part-by-part masses — ready to open in a spreadsheet. The file is built in your browser and saved straight to your device; nothing is uploaded.
Can I save my design, or open it in OpenRocket?
Yes. Download .ork (top of the results) saves the current design — built from scratch, edited, or imported — as an OpenRocket .ork file, generated entirely in your browser. It re-opens in Loft and, because it's OpenRocket's own format, in OpenRocket, so your work is durable and portable rather than lost on refresh. The file is named for the design — rename it in the field beside Import another first to save meaningfully-titled variants side by side. Any structural (geometry) edits you've made are baked into the saved airframe; transient what-ifs — added ballast, a swapped motor, a resized canopy, launch conditions — are flight explorations, not part of the design, so they're left out. Every bundled design round-trips through save and re-open with its flight unchanged. A freeform (arbitrary polygon) fin is saved as its aerodynamically-equivalent trapezoid — equal area, span and sweep, except where the planform tapers hard enough that no trapezoid can match both — and that is the one detail not recovered. Measured across 35 real designs: 8 carry a freeform set, and on 6 of them the re-opened copy's static margin differs, by a median 0.08 and at most 0.69 caliber. On the 27 designs without one it does not move.
Can I check how Loft read my design?
Yes. The Design workspace centres on a Design geometry panel showing a to-scale side-view of the airframe drawn from the model Loft parsed — nose, body, transitions, fins, and the loaded motor in their true proportions — so a wrong diameter, a missing part, or a fin in the wrong place stands out at a glance. It's also a handle for editing by hand: drag a fin and the design re-flies live. One handle slides the whole fin group fore or aft (the same trim the numeric Fin position field makes); on straight-edged fins a second handle at the tip rakes the sweep — both stability levers, worked by direct manipulation instead of typing, and a focused handle also takes arrow keys. Below the picture, the same parts are listed exactly as parsed: every component with its type, its station measured from the nose tip, and its key dimensions (lengths, diameters, and a fin set's chords and span). The picture and the table are the same geometry, for an imported design or one built from scratch. The side-view also marks the loaded CG and CP, so you can see the static margin — the CG sitting ahead of the CP — right on the airframe, not just as a number. Pair it with the Mass & balance panel (which shows each part's weight) for the full picture of what the simulator is flying.
Does it work offline?
Yes — once loaded, install it or just revisit and it runs with no connection: the app, the motor database, the simulation, and the bundled sample designs are all client-side, cached for the pad. So are these documentation pages, including the limitations log — the question of how far to trust a number is one you ask at the pad, not at a desk. Only the live-weather re-run and the first RocketPy download need a signal.
Can I get a second opinion from RocketPy?
Yes. In the Cross-check workspace, Second opinion: RocketPy flies your design in RocketPy — a separate, independent 6-DOF engine — and shows its apogee, speed, and stability beside Loft's. RocketPy is Python, so it runs in your browser through a WebAssembly build (Pyodide) that downloads the first time you tap the button (~40 MB) and then runs entirely on your device — your design never leaves the browser. Both engines fly a ballistic ascent and share Loft's drag curve, so the comparison is a clean cross-check of the trajectory, mass, and stability model (the same method the Validation page uses on the bundled designs). Close agreement is reassuring; a gap is worth a look, not proof either engine is right.
A run takes the better part of a minute, and once the runtime has it, Stop ends it — genuinely, by shutting down the Python runtime rather than just stopping the wait, because a WebAssembly CPython cannot be interrupted part-way through a flight. That is why stopping has a price: a later run starts the runtime from scratch and costs what the first one did. Nothing else in Loft is affected, and no partial RocketPy figure is ever shown.
It couldn't read my file, or a part was skipped.
Loft degrades gracefully: unknown components are skipped with a note rather than failing the whole import. If something's wrong or missing, please open an issue with the file — it's the fastest way to get the parser improved.
Is it really free / open source?
Yes. MIT-licensed, part of Fusion Space. Fork it, deploy your own, no attribution required. The point of the open repo is that the math is inspectable.