Three systems, examined honestly.

Aurelius is a small engineering studio creating browser-native graphics, simulation, visualization, and experimental computing systems using WebGPU and modern web technologies. These are engineering writeups of three of those systems — each one open to run while you read. Every project carries a status label so you know exactly where it sits:

Helix — browser-native plasma simulation

interactive charged-particle simulation · run it at /helix/ →

Overview

Helix is Aurelius' primary browser-native simulation project. It explores how modern browser technologies can deliver interactive scientific computing through a standard web browser: it combines charged-particle simulation, real-time 3D visualization, and live diagnostics in a single system that requires no installation or specialized software.

It is labeled a research experiment deliberately. Helix exists to investigate a specific physical question, and its value is measured by whether that investigation is honest — not by how impressive the visuals are.

The question under test

An RF antenna launches a helical wave; the reactor's magnetic field lines twist with their own pitch. The match number M compares the two helices, and the working hypothesis is that power coupling peaks when they align (M ≈ 1). What makes the simulator interesting as an instrument is that it refuses to assume its own conclusion: it ships three coupling models —

• KERNEL — the M ≈ 1 resonance is baked in as a hand-tuned prior;
• EMERGENT — coupling is derived from field-geometry alignment, so the peak must emerge from the physics or fail to;
• WAVE — coupling follows a helicon eigenmode model.

Sweeping M under each model and comparing the responses is the core experiment, and the app's plotting tools are built around exactly that comparison. The project is accompanied by a working paper defining four falsifiable predictions; the simulator's diagnostic instruments mirror those predictions one-for-one.

Architecture

Helix is a static, no-build single-page app. The physics core advances roughly 18,000 macro-electrons — each standing in for a large electron population — through an analytic magnetic field:

UI (React component — SIMULATE / DIAGNOSTICS / PLOTS / GUIDE)
        ↓ step(dt) · setParam()
Physics engine — Boris pusher · Monte-Carlo collisions
        ↓ 64×64×128 density grid · diagnostic series
3D view (three.js) · canvas plotting · dusty-plasma module

• Boris integrator — a standard, well-established pusher for charged-particle motion, chosen for its long-run stability: naive integrators visibly spiral particles into non-physical orbits, and in a live view there is nowhere to hide that.
• Monte-Carlo collisions with neutral gas turn clean single-particle orbits into believable bulk behavior — diffusion, thermalization, ionization.
• Six synthetic diagnostics — virtual Langmuir probes, a turbulence proxy with spectral analysis, an 8-probe B-dot array that recovers the azimuthal mode via DFT, a synthetic imaging camera, axial-structure readouts, and a dust panel with pair-correlation statistics — all computed from the same particle state the physics integrates.
• A dusty-plasma module — charged grains under ion drag and Yukawa pair forces, exhibiting a gas → liquid → crystal transition as the coupling parameter rises.
• Self-hosted everything — all runtime dependencies are version-pinned and served from the repo, so the instrument runs fully offline.

Alongside the browser app there is a separate headless research simulator — SI units, measured argon cross sections, absorbing walls — used for the quantitative studies (confinement time versus field-line pitch), with a physics self-test suite and seeded, reproducible runs.

Demonstrated today

• Browser-native charged-particle simulation at interactive rates
• Boris integration and Monte-Carlo collision modeling
• Live 3D visualization coupled directly to simulation state
• Six synthetic diagnostic instruments with CSV export
• Interactive parameter sweeps across three coupling models
• Reproducible headless studies with a self-test suite

Future development

• Additional particle species
• Field visualization refinements
• Larger-scale simulations
• Alternative numerical methods

Honest limitations

Helix is a reduced, normalized-unit model: analytic fields, macro-particles, a coarse density grid. It is designed around established numerical techniques commonly used for charged-particle simulation, and it is built to be trusted for trends and comparisons between settings, not absolute values. That caveat is printed in the project's own documentation, and we consider stating it part of the engineering.

Lessons learned

• Choose numerics for their failure modes. The Boris scheme earns its place by failing loudly and physically when misconfigured — the most useful property an integrator can have in a live instrument.
• Shipping the EMERGENT model alongside the KERNEL prior made it possible to test whether the predicted resonance actually emerged from the simulation rather than being imposed by the model.
• A URL lowers the barrier to experimentation more than any packaging improvement we could have made.

IKOS — Iterative Knowledge OS

knowledge-graph runtime · run it at /ikos/ →

IKOS is a different kind of problem from Helix — not numerics, but knowledge representation — so this writeup is organized around the design questions the project actually had to answer.

Why one state rendered four ways?

Knowledge tools usually force a choice: linear documents that read well but hide structure, or graph tools that expose structure but read terribly. IKOS's premise is that this is a rendering problem, not a data problem. Concepts are typed nodes, relationships are labeled edges, chapters are paths through the graph — and everything the user sees is a projection of that one structure. The four renderers exist because each answers a question the others can't: the Book answers "what does this mean in order?", the Graph answers "how is this connected?", the Terminal answers "how do I change it fast?", and the Orbit answers "how big is what I know, and where are its centers of gravity?"

The Book is the strongest test of the premise: chapter prose is composed live from the graph — each concept's passage is followed by paragraphs woven from its actual edges, and practice notes quote the user's current mastery back to them. Chapters form automatically as the graph grows. If the projection idea were wrong, the Book is where it would read as nonsense.

How does synchronization across projections work?

It doesn't — and that is the design. All state (nodes, edges, positions, chapters, books, notes, per-node mastery, installed modules) lives in a single state object, persisted locally. Every renderer reads the same fields of that object; every action writes back to it and triggers a re-render of whatever view is open. There is no synchronization layer, no event bus reconciling copies, no cache to invalidate — because nothing is ever duplicated. The architecture cost of four views is therefore close to the cost of four render functions, which is what made a solo-buildable four-view app feasible at all.

Why offline-first, and why a PWA?

A knowledge tool that dies with the network teaches its user not to trust it with anything important. IKOS is an installable PWA: a service worker keeps the app shell and 3D modules cached, navigations are network-first so new deploys land when online, and the knowledge state itself lives in local storage — the user's graph never depends on a server existing. The install-from-browser path matters for the same reason the URL matters for Helix: distribution is part of the design, not an afterthought.

Why WebGPU for the Orbit view?

The Orbit renders every concept as a spinning wireframe planet on typed orbital shells — with per-connection moons, rings on mastered nodes, comet streaks, and a camera that flies into a planet on click. That is hundreds of animated 3D objects with custom materials and real depth, which is out of reach for SVG and painful at interactive rates on 2D canvas. It runs on WebGPU with TSL node materials by default, with fallback to classic WebGL (the engine in use is shown in-app and can be toggled). It is also the shared-DNA point with the rest of the studio's work: the same TSL material approach used on the Aurelius landing page and Shader Lab drives the Orbit's planets.

What's deliberately conservative

IKOS treats trust as a first-class design constraint, which is unusual for a prototype: AI-suggested nodes are quarantined as pending until explicitly approved, experimental modules are gated behind a mode that can only be changed from the terminal, and a single killswitch command forces safe mode, rejects pending AI content, and disarms module rules. The interesting lesson: those guardrails made it easier to experiment with AI-generated graph content, not harder, because mistakes were cheap to contain.

Future development

IKOS is an active prototype, and its roadmap is exploratory: richer semantic layout in the Orbit, deeper terminal-as-query-language work, and convergence experiments with the studio's other systems. Directions, not commitments.

The Shader Lab

live TSL material gallery · run it in section 05 →

Why TSL

The browser GPU world is mid-transition: WebGPU (shaders in WGSL) is where capable browsers are; WebGL2 (shaders in GLSL) is the reality everywhere else. Maintaining parallel shader codebases across that split is a tax that compounds with every material. TSL — Three.js Shading Language — resolves the split at the authoring layer: materials are written once as JavaScript node graphs, and the compiler emits WGSL or GLSL per backend. The Shader Lab is our public verification that this holds for non-trivial materials — every material in it runs on both backends from a single source, and the widget's header reports which backend you're on.

TSL's second advantage is composability: a fresnel term, a noise field, a color ramp are JavaScript values, so materials share subexpressions the way code shares functions. The Lab's four materials draw on one shared basis — view vector, fresnel, a global FLUX uniform driven by the on-page slider.

Material architecture

Four materials chosen to cover four distinct shading regimes:

• HOLOGRAM — additive transparency: fresnel shell, world-space scanlines, temporal flicker. The regime of depth-write discipline and blend-order reasoning.
• SHIELD — pattern-driven emission: a Worley-noise cell lattice with radial pulse waves. The procedural-pattern regime.
• LIQUID METAL — geometry participation: fbm vertex displacement through positionNode with a dark chrome ramp. The regime where vertex and fragment stages must agree.
• DISSOLVE — threshold logic: noise-versus-threshold cutout with an ember edge. The regime of hard alpha and edge fields.

Each material's actual TSL source is displayed beside the running result — parameter control and visible source as proof the graphs are live, not recordings.

Cross-backend findings

Published because they cost real debugging time and are documented almost nowhere:

• Storage-buffer attributes pad to vec4 on WebGPU. An instancedArray('vec3') read back as an attribute is vec4-shaped on the WebGPU backend; constructing vec4(attr, 1) compiles on WebGL2 and throws on WebGPU. Take .xyz first, always.
• Sprite billboard space bypasses positionView. In sprite materials, positionView evaluates uselessly (view-z ≈ 0); per-instance depth requires modelViewMatrix.mul(vec4(instancePos,1)).z explicitly.
• Reversed smoothstep edges are undefined behavior. Some GLSL drivers tolerate smoothstep(hi, lo, x); treat edge order as a hard rule and invert with 1 − smoothstep(lo, hi, x).
• Power-ramp color math has a validity domain. A classic fire ramp (b, b², b⁴) inverts to blue-white the moment b > 1 — clamp at the ramp, not at the symptom.
• The host page is part of the runtime. Component frameworks re-render; a module can execute twice and its DOM can be absorbed mid-flight. Every live widget on the Aurelius landing page is a window-level singleton with a reattach-and-purge loop.

Measured performance

Numbers from the Shader Lab benchmark runs — headless Chrome at 1600×900 on an NVIDIA GeForce GTX 1060; the widget publishes its own live frame time, so your hardware reports its own truth:

The spread on the WebGL2 path is the honest story: the additive transparency materials hold 60 fps, while the displacement-plus-noise materials drop to the high-20s on the same rig — the cost profile you'd predict from the extra per-vertex noise evaluations. The widget renders only while on screen and shows its frame time continuously, which is the standard we think any performance claim on the web should meet: measured where you can see it.

Future development

New materials will land in the Lab first as the shared basis grows toward a reusable TSL library — source visible, frame time attached, both backends verified before anything ships.