Real-time 3D on the web with WebGPU

For most of the last decade, “3D on a website” meant a pre-rendered image or a turntable video. The model stayed on the artist’s workstation; the visitor got pixels. That is changing fast. Browsers can now draw detailed, physically-based scenes in real time, and product pages, configurators and portfolios are starting to ship the model itself instead of pictures of it.

From WebGL to WebGPU

WebGL brought hardware-accelerated 3D to the browser, but it is built on OpenGL ES — a graphics API designed long before today’s GPUs. WebGPU is its successor, modelled on the modern native APIs: Vulkan, Metal and Direct3D 12. For visualization work, that means three practical things:

• Less CPU overhead. Rendering state is prepared up front in pipelines and bind groups, so scenes with many objects spend less time in JavaScript and more time drawing.
• Compute shaders. The GPU can run general-purpose work — particle systems, culling, skinning, post-processing — without bending the graphics pipeline to do it.
• A cleaner shading language. WGSL replaces the patchwork of GLSL versions, and engines can share more shader code between desktop and web.

WebGPU is available by default in current Chrome and Edge on desktop and on many Android devices, and support in Safari and Firefox has been arriving over the past year. The practical rule has not changed, though: detect it, and keep a WebGL 2 fallback.

async function pickBackend() {
  const adapter = navigator.gpu ? await navigator.gpu.requestAdapter() : null;
  return adapter ? 'webgpu' : 'webgl2';
}

Engines such as three.js (with its WebGPU renderer) and Babylon.js handle most of this switch for you, so one scene can run on either backend.

What changes for visualization

• Heavier, more honest scenes. More geometry and more materials fit into a frame before the frame rate drops, so the model on the page can be closer to the one on the workstation.
• Effects that used to be pre-rendered. GPU particles, ambient occlusion, reflections and bloom can run live instead of being baked into a video.
• Interactive product stories. Configurators for colour, material and parts, exploded views and annotated hotspots — all driven by the real model.

The pipeline: from studio model to web-ready asset

The browser is still a constrained runtime: the model has to download over a phone connection and fit in a phone’s memory. Our pipeline for web delivery looks like this:

1. Start from the production model, then reduce. Decimate or retopologise to a triangle budget that suits the target devices, and bake fine detail into normal maps instead of geometry.
2. Consolidate materials. Every mesh–material pair costs a draw call. Merge parts that share a material and pack textures into atlases where it makes sense.
3. Author PBR textures for the web. Metal/roughness workflow, 1K–2K maps for most objects, with occlusion, roughness and metallic packed into one texture.
4. Export glTF 2.0 as GLB. glTF is the standard delivery format for 3D on the web: meters, Y-up, PBR materials, animation and scene hierarchy in a single file.
5. Compress. Draco or meshopt for geometry and KTX 2.0 (Basis Universal) for textures often shrink a model several times over — and KTX 2.0 also cuts GPU memory.
6. Test on the weakest target device, not on the workstation that built it.

Our Web 3D export tutorial walks through these steps one by one.

The budgets we actually check

• Download size — the whole scene, compressed, as the visitor receives it.
• Draw calls per frame — the fastest way to lose frame rate on mobile.
• Texture memory — uncompressed textures fill a phone’s GPU long before geometry does.
• Time to first frame — how long the visitor looks at an empty canvas.

If one of these slips, it shows up as a blank or stuttering canvas on a phone — which is worse than a static image.

When a pre-rendered image is still the right answer

Real-time rendering has closed much of the gap, but not all of it. Hero shots, print, and scenes that depend on caustics, heavy volumetrics or film-quality path tracing still belong to offline renderers. The strongest product pages mix both: a cinematic render for the first impression, and the live model for exploration.

How we use it at 3Desite

Web and UI/UX 3D is one of our core services: interactive viewers, AR/VR-ready exports and data visualization built from the same models we render for print. You can try browser-based 3D tools in the ZIBADIS 3D viewer, or send us a brief for a viewer or configurator of your own.