A Rust 3D engine in WebAssembly with the three.js API. Change the import, call init(), keep your code.
WAMR3D WebAssembly Accelerated Modular Rendering 3D
$ npm install wamr3d
Migration path
Scene, meshes, lights, shadows, materials and math keep their three.js names, properties and chaining. A parity script runs the same code on both libraries and compares every number.
Point three at wamr3d/compat and call init() once.
Use WebGPURenderer and await renderer.init(). It draws with WebGPU, or WebGL 2 where WebGPU is missing; WebGLRenderer works too.
scene.add, position.set, rotation.y +=, lookAt and raycasting work as written for supported classes.
- import * as THREE from 'three';+ import * as THREE from 'wamr3d/compat';+ await THREE.init();
const scene = new THREE.Scene();
const mesh = new THREE.Mesh( geometry, material );
scene.add( mesh );
- const renderer = new THREE.WebGLRenderer( { antialias: true } );+ const renderer = new THREE.WebGPURenderer( { antialias: true } );+ await renderer.init();What it is
Scene graph, transforms, cameras, geometry processing, culling and draw ordering run inside a WebAssembly module. You drive it from JavaScript through three.js-style classes or batched calls.
Rust → WebAssembly
Set transforms as cheaply as in three.js: the object API batches every change into the Rust engine once per frame. When you need more, the low-level API gives you handles, explicit disposal and zero-copy typed-array views of geometry and world matrices.
WebGPU + WebGL 2
Not a wrapper around three.js. WebGPU where the browser has it, a native WebGL 2 renderer everywhere else, chosen automatically. Meshes, lines, points, sprites and instanced meshes; basic, Lambert and standard materials; colour textures, fog, up to 16 lights, PCF shadows, tone mapping, render targets and 4× MSAA.
Object API
Scene, Group, Mesh, InstancedMesh, Points, Sprite, render targets, cameras, eight shapes, six materials, textures, five light types, shadows, tone mapping, Raycaster, Clock and the math types.
Batched API
Handles and batched calls such as setRotations; read world matrices and geometry through typed-array views over engine memory, with no copy.
Parity
Over 7,600 reference cases generated from the three.js source are replayed against the Rust code. All 23 renderer cases are compared with stored three.js images.
Roadmap
These features are not supported by either the WebGPU or WebGL 2 renderer yet. Keep three.js for them for now:
CPU + GPU
Browser 3D usually spends its frame in JavaScript before the GPU sees a single triangle. WAMR3D puts both processors to work: compiled Rust does the scene work on the CPU at native speed, and the GPU receives a frame that is ready to draw, through WebGPU or WebGL 2. No plug-in, no install, just a tab.
01 · CPU, in WebAssembly
Rust compiled to WebAssembly with SIMD runs the whole scene: no garbage collector pauses, no object churn, data laid out in flat typed memory.
02 · The boundary
The object API records your changes and sends them to the engine in a batch. Geometry and world matrices are typed-array views over engine memory: read without copying.
03 · GPU, WebGPU or WebGL 2
A thin host turns the prepared frame into GPU commands: pipelines and programs are cached, instanced meshes draw in one call, and the same frame runs on WebGPU or WebGL 2.
The result: the CPU time three.js spends updating and submitting a scene shrinks, and more of each frame is left to the GPU. How much depends on the scene; the benchmarks show measured medians, including where WAMR3D is slower.
Measured, not promised
The same scene, 6 renderers, one engine at a time. Medians from a single run on one machine; higher is better in every figure here. Open the showcase to measure yours.
60fps
10,000 separate meshes at 1280×720
WAMR3D batched. three.js ran at 42.4 fps with WebGL and 11.6 fps with WebGPU.
60fps
50,000 instanced bodies at 1280×720
WAMR3D batched. three.js ran at 19.6 fps with WebGL and 20.1 fps with WebGPU; its scene update took 44 to 41 ms against 12.2 ms.
1.4× faster
Draw submission than three.js WebGL
10,000 separate meshes at 1280×720: 13.2 ms of CPU time per frame against 18.3 ms. Computed from the measured medians.
53fps
The same 10,000 meshes on WebGL 2
WAMR3D batched on its WebGL 2 renderer, for machines without WebGPU: 1.3× the frame rate of three.js WebGL (42.4 fps) on the same graphics API.
Sun, belts, clusters and bodies: a four-level scene graph where every rotation changes each frame. Longer bars are better in the two frame-rate charts; the CPU chart below them is marked separately.
scene update: animation, transforms, world matricesdraw submission: the renderer’s CPU work
This is the cost behind the frame rate above: CPU time past the dashed line cannot fit in a 60 fps frame. GPU time is not measured.
| Engine | fps ▲ | update ms ▼ | submit ms ▼ | draw calls |
|---|---|---|---|---|
| WAMR3D · batched API | 60.0 | 2.4 | 13.2 | 9846 |
| WAMR3D · object API | 54.7 | 4.2 | 13.8 | 9859 |
| WAMR3D · batched API · WebGL 2 | 53.0 | 2.1 | 16.5 | 9872 |
| WAMR3D · object API · WebGL 2 | 45.9 | 4.3 | 17.2 | 9894 |
| three.js · WebGPU | 11.6 | 5.7 | 78.9 | 9870 |
| three.js · WebGL | 42.4 | 4.9 | 18.3 | 9789 |
Where it is slower: calls that do very little work, such as a single vector operation or one property at a time, cost more than plain JavaScript because crossing into WebAssembly has a fixed cost. Single math calls measured 1.5× to 4.1× slower than three.js. GPU time is not measured; it only shows in the frame rate.
Intel(R) Core(TM) i9-10900X CPU @ 3.70GHz, ANGLE (NVIDIA, NVIDIA GeForce RTX 2070 SUPER, Chrome/155.0.8059.80 headless, undefined.
Fresh 1280×720 measurements; the higher-resolution charts use the earlier same-day run. Raw logs: bench/results/2026-10-15-current.
Live demos
Every demo below is drawn by WAMR3D, with WebGPU or WebGL 2 depending on your browser, except the three.js engines you choose to compare against.
A three.js game · now on WAMR3D
Crossy Road, with only the import changed. Hop with the arrow keys.
or open it full screenThe demos need a browser with WebGPU, such as current Chrome or Edge.
Get started
The package ships the WebAssembly module, the object API, the low-level API and TypeScript typings.
$ npm install wamr3d
file://.wamr3d name."lib": [ "esnext", "dom" ].import * as WAMR3D from 'wamr3d/compat';
await WAMR3D.init();
const scene = new WAMR3D.Scene();
const camera = new WAMR3D.PerspectiveCamera( 50, innerWidth / innerHeight, 0.1, 100 );
camera.position.set( 3, 2, 5 );
camera.lookAt( 0, 0, 0 );
const cube = new WAMR3D.Mesh( new WAMR3D.BoxGeometry(), new WAMR3D.MeshLambertMaterial( { color: 0x4f8cff } ) );
scene.add( cube, new WAMR3D.DirectionalLight( 0xffffff, 2 ), new WAMR3D.HemisphereLight( 0xbfd4ff, 0x30281e, 1 ) );
const renderer = new WAMR3D.WebGPURenderer( { antialias: true } );
await renderer.init();
renderer.setSize( innerWidth, innerHeight );
document.body.appendChild( renderer.domElement );
renderer.setAnimationLoop( ( time ) => {
cube.rotation.y = time / 1000;
renderer.render( scene, camera );
} );Open source · MIT
Run your three.js scene on WAMR3D's WebGPU renderer, compare the numbers, then batch the hot paths as your scene grows.