Case studies, sorted by what is real now.

Aurelius builds browser-native graphics, visualization, simulation, and interactive computing systems. These engineering writeups use the same maturity model as Capabilities, so it is clear whether a system is running today, still evolving as research, or only a stated direction.

The Shader Lab

status · proven today · live TSL material gallery · open the Shader Lab →

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

The reusable library the Lab was growing toward now exists: the shared basis became a verified TSL node collection — noise, ramps, fresnel, patterns — with every entry run through the same gate (both backends, measured cost, generated source) and published in the Lab's node gallery. Its first consumer beyond this page is echoGalaxy (Case 02), which sends new nodes back through that gate as it grows. That loop is the plan from here: building the universe together, one line of code at a time.

echoGalaxy — a free tool for exploring the universe

status · proven today · open education project · run it at /galaxy/ →

Overview

echoGalaxy is a free educational explorer: four connected scales — planet, star system, galaxy, Local Group — each rendered procedurally and each carrying its own set of astronomy facts. Scroll past the edge of one scale and you climb to the next; the facts panel is the point, the graphics are how it earns attention.

It is also this studio's first structural reuse test: echoGalaxy consumes the same TSL shader library that powers the Shader Lab above, in a different codebase, on a different three.js release, under a different renderer setup. That made it the proving ground for a question the Lab alone can't answer — does the library survive contact with a second product?

What the scales actually compute

• Planets — procedural worlds from the library's planetary nodes: lattice-noise continents, a day/night terminator with night-side city light, an additive atmosphere shell.
• Star system — orbits move on Kepler's third law, not decoration: period follows distance, and the facts panel reads the live configuration.
• Galaxies — four Hubble classes from one persistent star field; every per-star quantity is derived on the GPU from its index, so switching galaxy type is a uniform swap, not a rebuild. Star colors come from a blackbody ramp anchored to published color-matching data (validated to a worst-case channel error of 8/255 against the reference table).
• Local Group — the Milky Way, Andromeda and companions, and Triangulum inside a single 24,000-star budget, with the blueshift story told on the HUD.

The consumer test, honestly scored

The library is verified on three.js r178; echoGalaxy runs r184. The result: zero library-code changes — every node the app uses built and rendered on both backends unchanged, because the library injects its dependencies rather than importing them. The friction lived around the library, and it was real: point primitives cannot render sized sprites under the WebGPU renderer at all (the galaxy became instanced sprites, which the GPU-derived star field then required anyway), and repeated compute dispatches into a render buffer proved unreliable on the WebGL2 backend — so that path keeps a live vertex fallback while the divergence sits on the library's public watch list.

Two nodes were born in this project and promoted upstream through the library's verification gate before they counted as done: a latitude-band flow field for gas giants, and the blackbody color ramp. Both now sit in the Lab's node gallery with their cost and parity records.

Measured performance

On the studio's Intel UHD 630 development machine — a deliberately modest floor — the explorer holds 33–45 fps on WebGPU and 27–35 fps on WebGL2 across all four scales, after baking the star positions, gas veil, and sky sphere to textures at load.

Distribution

echoGalaxy ships as an installable PWA at /galaxy/: offline-capable after first visit, touch-ready, and prepared for Android Trusted Web Activity packaging. Privacy is intentional and short — no accounts, analytics, or tracking.

Future development

The journey is not complete: more worlds, more facts, and deeper rungs on the ladder are planned, and new shader work will keep flowing back into the library the same way — extracted, verified on both backends, then consumed back as a vendored copy.

Helix — browser-native plasma simulation

status · active research & development · 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: charged-particle simulation, real-time 3D visualization, and live diagnostics in a single system that requires no installation or specialized software.

It sits in Active R&D 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

status · active research & development · 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: 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 remains Active R&D, 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.