What we build — sorted by what's real.

Aurelius is a small engineering studio creating browser-native graphics, simulation, visualization, and experimental computing systems using WebGPU and modern web technologies. Every capability on this page falls into one of three categories, so you can instantly separate what is demonstrated from what is direction:

WebGPU rendering

status · proven today — running on this domain

We build browser-native rendering systems on the modern GPU stack, with WebGPU as the primary target and a tested WebGL2 fallback. Capabilities in production use:

• Compute-driven particle systems with per-frame GPU integration
• Large-scale instanced rendering with additive-blend luminance control
• Visibility-aware scheduling — every scene renders only while on screen
• Multi-canvas pages where scenes initialize lazily and coexist within one frame budget
• Procedural environments (nebula, aurora, solar dynamics) generated entirely in shaders
• Per-tier degradation with explicit ceilings and brightness normalization

Current deployments, with measurement context:

The fallback numbers are tested, not theoretical — verification runs force WebGPU off to exercise the WebGL2 path deliberately. Why it matters: most organizations still treat browser graphics as presentation. We treat the browser as a GPU computing platform, and the front page is the standing demonstration.

TSL shader development

status · proven today — live in the Shader Lab

We develop custom materials and visual effects in TSL — Three.js Shading Language — where a single node graph compiles to WGSL on WebGPU and GLSL on WebGL2. Working practice includes:

• Cross-backend material development from one source
• Procedural noise-driven materials (fractal, Worley)
• Vertex displacement through the node pipeline
• Data-texture sampling by computed coordinates
• Interactive shader parameters bound to live uniforms

The running material set spans holographic surfaces, energy shields, liquid metal, dissolve systems, and the landing page's solar, atmospheric, and aurora effects. The Shader Lab shows four of these live with their TSL source beside them, and the case study publishes the cross-backend findings — the seams we hit in production and how to route around them. Why it matters: one material architecture, both GPU eras of the web, no parallel codebase.

Interactive visualization

status · proven today — live data on the landing page

We turn live data into interactive GPU-rendered systems. The reference deployment runs on the front page: the rendered Earth's storm layer samples Open-Meteo's live global weather feed — real storm systems flash at their true latitude and longitude on the spinning globe, refreshed every fifteen minutes, with a procedural fallback so the scene never depends on the network and a HUD tag that discloses when the live feed is active. It is a small pipeline with every stage of a serious one: ingestion, transformation to GPU-friendly form, shader-side sampling, graceful degradation, visible provenance.

The IKOS Orbit view applies the same discipline to a different data shape — an entire knowledge graph rendered as a navigable 3D space (case study). The emphasis in both: not displaying data, but making a system understandable through direct interaction.

Interactive experiences

status · proven today — every example is on this domain

We build interfaces designed to be explored rather than observed: the landing page's working command console (type help), the three-engine scenario demo, the Shader Lab's draggable geometry and live FLUX parameter, and a hero field that responds to your pointer. All of it is lazy-initialized, reduced-motion-aware, and hardened against the realities of production DOM — framework re-renders, resize storms, tab suspension.

We consider interaction a verification tool: a system a visitor can poke, drag, and fail to break earns a kind of trust no copy can. That standard — inspectable, testable, challengeable — is what we mean by an interactive experience.

Scientific simulation

status · active research & development — Helix is the testbed

We are developing browser-native simulation systems — numerical models with live diagnostics, delivered through a URL. Helix, the primary testbed, currently demonstrates charged-particle dynamics under a Boris integrator with Monte-Carlo collisions, live 3D visualization, and six synthetic diagnostic instruments; the full writeup, including its honest limitations, is in the case study.

Current research focus:

• Numerical stability under real-time constraints
• Computational efficiency at interactive rates
• Live parameter inspection and diagnostic design
• Reproducible, seeded studies alongside the interactive app

This is labeled R&D rather than a service because that is what it is: a working system built to investigate a question, evolving as the investigation does. The architecture is intentionally general-purpose and can support future exploration of additional simulation domains.

Health & engineering visualization

status · active research & development — internal prototypes

We are exploring approaches for visualizing complex technical and biomedical information — health data, biological structure, engineering diagnostics — under one constraint: faithful representation outranks visual spectacle. A rendering error in these domains is not a cosmetic bug, so the work leans on the studio's validation habits: explicit units and scales, rendering choices documented against the data they encode, and review that treats the visualization itself as a claim requiring evidence.

This section is honest about its status: the prototypes here are internal and there is nothing public to link yet — which under this page's own rules is exactly why it sits in Active R&D and not above the fold.

Digital twins

status · future program — direction, not an offering

The long-term aim: browser-native representations of real physical systems that combine live telemetry, simulation, diagnostics, historical data, and predictive analysis in one inspectable view. We deliberately reserve the term "digital twin" for systems actually driven by their physical counterpart's data — which is precisely why this is a future program and not a listed capability. Helix demonstrates the simulation and diagnostics layers; the telemetry-driven mirror is the unbuilt part.

Potential settings we are studying — hypothetically, not as delivered work — include manufacturing lines, energy systems, infrastructure, and research environments.

AI-assisted simulation

status · future program — direction, not an offering

We are exploring workflows where AI assists simulation rather than replacing it: parameter-space exploration, scenario generation, analysis of simulation output, and human-guided optimization. The design intent is augmented decision-making, not autonomous decision-making — the same discipline the studio already applies to AI-assisted engineering, where machine-generated work passes through validation before it counts.