Quick start

nanoraster renders a GLB file to image bytes you own. One request always produces the same pixels, so a render can serve as evidence.

npm install nanoraster

Save this as render.mjs and run it with node render.mjs. The example states the fitted camera direction so you can edit it. Without camera, you get the same three-quarter default. The live tile renders at 960×720, so its byte count differs. Milliseconds drop after the first frame because dragging reuses one renderer. Reuse the renderer shows the same technique in your code.

import { directionFromOrbit, renderImage } from 'nanoraster';import { readFile, writeFile } from 'node:fs/promises';const glb = Uint8Array.from(await readFile('model.glb'));const image = await renderImage(glb, {  format: 'webp',  width: 512,  height: 512,  camera: {    framing: 'fit',    direction: directionFromOrbit({ azimuth: 45, elevation: 30 }),  },});await writeFile(image.name, image.bytes);console.log(`wrote ${image.name} (${image.bytes.length} bytes, ${image.mimeType})`);

Expected output

wrote render.webp (26628 bytes, image/webp)

The result is a plain object: name, bytes, mimeType, and the resolved width and height. nanoraster never writes to disk, so the bytes are yours to save, upload, or give to another process. Run the script again: the bytes are identical. Camera, lighting, and encoder are fixed for a given request.

The same call produces PNG, WebP, or JPEG (jpg is an alias), or the unencoded frame with format: 'raw'. See Format and annotate and Work with raw pixels. Every rejection is a RenderError with a stable machine-readable code. See Handle render failures.

What it does not do

nanoraster does not render texture-backed materials, animation, or scene graphs beyond static geometry. The supported profile is factor-only glTF metallic-roughness. Lighting is the studio preset unless you supply a rig. See How it works.