2.0.3 LIVEAura3Dapplication-first browser 3D

Stop assembling renderer parts.
Start shipping 3D applications.

Aura3D turns typed assets, scene composition, physics, navigation, interaction, templates, diagnostics, and deployment into one agent-ready TypeScript workflow. The selected comparison suite completes all 15 required workloads from exact installed packages—and Aura3D carries the application architecture with it.

Launch 36 live experiences Build your first scene
15 / 15selected correctness workloads
29exact installed Aura3D tarballs
36live apps, games, and examples
1 commandto scaffold the first application
The decision

Own the product—not the integration backlog.

A low-level renderer leaves your team to select, connect, type, test, and maintain the rest of the application stack. Aura3D starts at the application layer with a coherent public API and deployable workflows.

The renderer-first path

Your team assembles the application layer.

  • Choose and connect loaders, controls, simulation, navigation, asset conventions, lifecycle, and deployment.
  • Create internal patterns for coding agents, scene composition, diagnostics, and release verification.
  • Own every integration boundary and keep it working as the stack changes.
The Aura3D path

Start with the system assembled.

  • Resolve license-aware assets into generated, typed references instead of guessing model URLs.
  • Compose scenes through stable application-level nouns and verbs designed for developers and coding agents.
  • Use maintained scaffolds, interactions, Rapier, Recast, route health, diagnostics, and deploy checks in one product path.
Why Aura3D

The application stack is already moving.

Build from a typed asset to an interactive route without recreating the same infrastructure on every project.

01

Measured outcomes

15 of 15 workloads pass

The frozen exact-install suite completes every selected correctness workload through public Aura3D packages.

02

Typed asset pipeline

Real models, generated references

Search, resolve, validate, hash, license, and import assets through TypeScript instead of scattering raw URLs across the app.

03

Developer workflow

Application APIs from the first line

Scene kits, typed assets, interactions, physics, navigation, templates, and agent context begin above the raw renderer layer.

04

Release confidence

Proof travels with the route

Route health, interaction audits, asset hashes, browser screenshots, installed-package tests, and hosted checks are maintained product surfaces.

05

Editable ownership

Ordinary TypeScript, no black box

Developers keep the generated application code, typed assets, scene structure, controls, and deployment output.

What 2.0 changes

Built in, without rebuilding everything.

Typed assets

The CLI records provenance, license, hash, bounds, and a generated TypeScript reference. Public routes import assets.product; they do not guess a URL.

One simulation owner

Rapier owns physical bodies, colliders, joints, CCD, character movement, and physical vehicle handles. Recast owns navmesh and crowd. Authored arcade motion stays explicitly non-physical.

AI-native composition

The public API exposes stable scene nouns and verbs, templates, prompt context, and ordinary TypeScript that a developer can inspect after an agent writes it.

Evidence as code

A green DOM is not accepted as a rendered scene. Aura3D separates source, renderer, visual, interaction, package, clean-consumer, and hosted-route proof.

Lean entries

@aura3d/lean, /product, and /game isolate recommended surfaces while the root engine remains the broad compatibility entry.

Production escape hatch

The production renderer and low-level packages remain reachable for selected shader, postprocess, WebGPU, GLB, animation, and lifecycle workloads—with claims scoped to the path actually tested.

Frozen r185 workload set

Fifteen outcomes. Every limitation retained.

Primitive PBR sceneGLB product viewerCinematic architectureDigital-twin dataInstancing + LODSkinned morph animationCustom material shaderPostprocessed sceneRapier characterRapier vehicleRecast crowdWebGPU shaderInjected XR interactionResource lifecycleScaffold to deploy

The set proves these named outcomes, not universal visual parity, renderer-feature parity, performance non-inferiority, physical-device XR, general TSL ergonomics, or the breadth of Three.js’s ecosystem. Native WebGPU passed on host hardware; the clean Linux container without GPU passthrough passed 23 of 24 browser assertions.

Build now

Less assembly.
More application.

Give your team and coding agents a typed, inspectable path from asset to interactive, deployable browser 3D.

Build the first scene Launch the examples