What real-time 3D is
Pre-rendered 3D is like film, every frame calculated in advance. Real-time 3D is calculated as you watch, dozens of times a second, so you can orbit a product, fly across a landscape, change the lighting or ripple a surface with your cursor.
In the browser, it runs on WebGL, which every modern browser supports, and increasingly on the more powerful WebGPU. Libraries such as Three.js handle much of the complexity, and custom shaders (small programs on the graphics processor) control every pixel.
Why it’s practical now
3D on the web used to mean long loads, plugins and crashes on phones. Capable phone graphics, fast browser standards and much better model and texture compression changed that. A well-built scene now loads quickly and runs smoothly on an ordinary device.
Real-time 3D is still easy to build badly. Whether it delights or frustrates comes down mostly to the engineering discipline behind it.
Where we use it
- Hero experiences: a memorable, responsive front door for a site.
- Product and object viewers, where rotating something beats looking at photos.
- Maps and terrain, where seeing a place from above, or flying through it, helps people plan.
- Data in space, when three dimensions make information easier to grasp.
- Games and playful moments, on a website or a venue’s big screen.
- AR and camera effects, reusing the same models in social platforms and mobile browsers.
If a flat page would answer the question faster, we’ll build the flat page.
Every effect earns its weight
Performance is what makes real-time 3D worth doing:
- Budget from the start. Model and texture sizes, object counts and a target frame rate on a target device, agreed before building.
- Optimize the assets. Models simplified where detail won’t be noticed, modern texture compression, geometry reused wherever possible.
- Write efficient shaders. Shaders can make beautiful effects cheaply, or expensive ones for no visible gain. We profile them and cut what doesn’t pay its way.
- Adapt to the device. Less capable hardware gets less detail, resolution or effects: a smooth version, never a broken one.
- Pause when unseen. Rendering stops when the scene is off-screen or the tab is hidden, saving battery.
- Test on real devices. Actual mid-range phones throughout the build, because emulators don’t tell the full story.
Accessibility and fallbacks
A 3D scene can’t be the only way to get important information:
- Key content is available as real text and standard controls, for screen readers, keyboards and search engines.
- Reduced-motion settings are honoured where motion could cause discomfort.
- Devices that can’t run the scene get a well-designed static or simplified version instead of an error.
From Blender to browser
Our pipeline usually starts in Blender, where we model, light and prepare scenes. Assets are exported in web formats, compressed and loaded into the browser, where lighting, materials and interaction are finished in code. Custom shaders often do the most distinctive work: a model you can draw on, surfaces that respond to sound or data, stylized looks impossible to pre-render.
Early on, we work through rough grey-box prototypes with the client. Interaction and shader tests built with AI-assisted code are cheap to change, so we learn whether an idea feels right before detailed modelling and polish.
Keeping it maintainable
Content baked into a 3D scene is hard to update. Labels, locations, products and copy that are likely to change stay outside the 3D assets in a CMS, so your team can update them without a developer.
