Each row is the same wrap rendered two ways. Left: Blender Cycles, the server
render — shown as the finished 15 RPM spin it produces (it spins, but you can't drag it,
because Cycles path-traces every frame offline). Right: the WebGPU/three.js preview running
live in your browser, on this device — drag it to rotate. Both spin at the real
~15 RPM of the display gearbox. The goal: get the browser version close enough to retire the
server render — zero render cost, no single point of failure.
01 Color & detail test blocky, high-contrast color
Server Blender — Cycles
pre-rendered · can't drag
In-browser WebGPU / three.js
drag to rotate
02 Logo wrap SUMMIT Outfitters — front & back
Server Blender — Cycles
pre-rendered · can't drag
In-browser WebGPU / three.js
drag to rotate
03 Full-wrap artwork edge-to-edge design
Server Blender — Cycles
pre-rendered · can't drag
In-browser WebGPU / three.js
drag to rotate
What you're looking at. Every right-hand panel is real-time WebGPU — it loads the tumbler model +
a studio HDRI and renders the clear plastic, the printed wrap, cap/straw and a soft floor shadow live on
your own device, which is why you can drag it. The left panels are the actual Blender Cycles output (a
pre-rendered 15 RPM spin). Why it matters: if the browser render is good enough for the customer
preview, the heavy Blender render can move off the Mac Studio entirely — and since the factory
manufactures from the flat print file (not the render), the 3D is preview-only.
Open the full interactive preview →