Recipe: 3D Product Viewer

This recipe ships an interactive 3D viewer for your products. A three-d element compiles a Bevy app to WebAssembly and serves it, while a files element holds the source models and textures. Visitors rotate, zoom, and inspect a real 3D scene in the browser — no plugin, no external 3D host.

The problem it solves

A flat product photo cannot show what a 3D object actually looks like. But standing up an interactive 3D experience usually means a games-engine toolchain, a WASM build pipeline, and somewhere to host the assets and the compiled bundle. This recipe makes all three platform elements, so a 3D viewer is something you build and deploy the same way you build any other front end.

Elements

Flow

1. Create a files element as your asset store. upload your source models and textures; list and download them as you iterate.
2. Create a three-d element. Register the 3D assets the scene uses with its upload_asset operation (each asset is stored in the element’s dedicated namespace), and confirm them with list_assets.
3. build the world — the three-d element compiles your Bevy app to wasm32-unknown-unknown via BuildForce. While iterating, hot_reload pushes changes without a full rebuild.
4. serve the compiled viewer to the browser. Visitors get the interactive scene; you render a still or re-serve to check it before publishing.

What this shows

Interactive 3D is a native frontend category on the platform, not a special case — the three-d element owns the Bevy→WASM build and the serving, so “ship a 3D viewer” is one element’s job. Source assets live in a plain files store you can manage independently of the build, which keeps the authoring loop (upload a new model, re-register, rebuild) tight. The same build-and-serve shape that backs a spa backs a 3D world — the platform treats both as first-class front ends.

Next pages

• Three-D
• Files
• SPA