See it from every side,
right in the page
We build interactive 3D with three.js, sized for the phones your visitors use and described in words in the page, so people can look closer before they decide.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When the 3D is the heaviest thing on the page
A 3D scene asks more of a visitor’s device than most of a page does: its models and textures have to download, and then every frame has to be drawn.
On a phone, that can mean a wait before anything moves. And to a screen reader the scene is one picture, while a keyboard can’t reach what’s inside it, unless the page gives it words and controls of its own.
So the real work is deciding what’s 3D at all, what each scene weighs, and what every visitor gets, whether they look, listen or use a keyboard. How much a scene asks depends on the scene and on the phone.
What we build
Each scene is built on a branch, measured on the phones it’s meant for, and reviewed by a person before it ships.
New 3D scenes, and 3D in the app you have
Scenes for new sites, and 3D views added to an app you already run, with tests from the start.
Product viewers and configurators
Products a visitor can turn and try in each finish, with the same choices and the same words in the page.
Models made ready for the web
Your models, CAD exports or a 3D artist’s files brought to glTF™, their geometry and textures compressed, and sized for the phones your visitors use.
Measured on phones first
Loading and frame rate measured on real phones before anything changes, then each change measured against the scene as it was.
Releases moved forward, and WebGPU where it helps
An older release moved forward a few at a time, and WebGPURenderer taken on where it helps, with WebGL™ 2 behind it.
Words and controls for everyone
What each scene shows also said in the page, controls that work by keyboard, a way to stop motion, and less of it for people who ask.
Data behind the scene
Products, plans and live data brought into the scene from your systems, through their APIs.
Checks on every change
Pictures of each scene compared on every change, and loading checked in CI, so a change merges once both pass.
AI where it helps
When an AI coding assistant drafts a change, it’s compared and reviewed the same way as any other before it merges.
- 3D inside a React app:React & Next.js Development
- 3D inside a Vue app:Vue.js & Nuxt Development
- 3D inside a Svelte app:Development for Svelte and SvelteKit apps
- For hosting and delivery:Cloud, DevOps & Security
- Loading and speed across a site:Performance & Optimization
- Words, keyboard and motion across a site:Accessibility
- Developers in your own team:Developers for 3D on the web, with three.js
The picture, and the words behind it
A 3D scene is drawn in a canvas, and to a screen reader a canvas is one picture. The HTML standard asks that what a canvas shows is also given in the page: its names, its descriptions and its controls.
A scene a visitor can turn also needs a way to turn it without dragging, and a way to reach it by keyboard, as WCAG 2.2 asks.
A scene that moves on its own needs a way to stop it, and people who ask their device for less motion should get less of it.
So we write each scene’s words with the scene, and check them whenever it changes. Below is a rice cooker from a shop of our own: turn it, and the words beside it change with it.
To turn the rice cooker, drag it sideways, or use Turn left and Turn right. With a keyboard, the arrow keys turn it a little at a time, Page Up and Page Down a quarter turn, and Home brings back the front.
Seen from the frontSeen from the front leftSeen from the leftSeen from the back leftSeen from the backSeen from the back rightSeen from the rightSeen from the front right
In the page: The coral button that opens the lid, the control panel under it, and the carry handle arching over the lid.In the page: The button and the control panel, turned to the right, the carry handle at a slant, and the cable trailing at the back.In the page: The carry handle end on above the lid, the hinge at the back of the lid, and the cable leaving the base.In the page: The hinge at the back of the lid, the cable leaving the base, and the carry handle at a slant.In the page: The hinge at the back of the lid, the steam vent above it, and the cable leaving the base toward you.In the page: The hinge and the cable leaving the base, and the carry handle at a slant.In the page: The carry handle end on above the lid, the hinge at the back of the lid, and the cable leaving the base.In the page: The button and the control panel, turned to the left, the carry handle at a slant, and the cable trailing at the back.
Why it’s there: The HTML standard asks that what a canvas shows is also given in the page, so anyone who can’t see the picture still gets what it shows.
{{ tnSay }}
Forward, a few releases at a time
New releases of three.js come out several times a year, and each one’s notes, with its own section of the Migration Guide, list what changed since the release before.
We move a project on an older release forward a few releases at a time, reading each step’s notes first, and comparing pictures of every scene before and after.
WebGLRenderer is still maintained, and the manual recommends it for pure WebGL 2 apps. The project’s focus is now WebGPURenderer, which uses WebGPU where the browser has it and falls back to WebGL 2 where it doesn’t.
Its materials are built from nodes, and its shaders are written in TSL, the three.js shading language, which works on either backend. So a scene with shaders of its own is checked shader by shader before it moves, and the renderer is its own step, taken when it helps the scene.
Start with one scene
The review covers the three.js release in use, and how it’s pinned in development, in CI and in deploys; the renderer, and any custom shaders or patched materials; the models: their formats, how they were exported, their geometry and textures, and the compression they use; what loads first, what waits until it’s needed, and what a visitor sees while it loads; loading and frame rate on a mid-range phone, measured as a baseline for the review; memory, and what’s freed when a scene closes; what happens when a device can’t draw the scene, or loses its graphics context; the words, the keyboard controls and the motion settings; how the scene sits in the app, whether React, Vue, Svelte or plain JavaScript, and the data it reads; the tests, and whether pictures are compared on every change; and where the assets are hosted.
The first step is one of these, each tried on a branch: one model compressed and measured before and after; the scene paused while it’s off screen, with a still image shown first; words and keyboard controls added to one scene; the release moved forward one step, with each scene compared; or pictures of each scene compared in CI.
What you receive is a written review and a proposal for that first step.
Questions worth asking
Should our site use 3D at all?
Where turning, choosing or exploring something helps a visitor, often yes. Where it doesn’t, a still image or a few views often do the job better, and show sooner.
Will it work on phones?
We design for the phones your visitors use, measure on them, and show a simpler scene or a still image where a device can’t keep up.
WebGPU or WebGL?
WebGPURenderer uses WebGPU where the browser has it and falls back to WebGL 2, and the manual still recommends WebGLRenderer for pure WebGL 2 apps. We choose per project, and custom shaders often decide it.
Can you make our 3D models?
We work from your models, your CAD exports or a 3D artist’s files, and make them ready for the web: brought to glTF, compressed, and checked against the original.
Can you add 3D to our React, Vue or Svelte app?
Yes, inside the app you have, as one more part of it, with its own tests.
Can people with screen readers or keyboards use it?
Yes, when the scene’s words and controls are built with it, as the rice cooker above shows: what it shows said in the page, and every control reachable by keyboard.
Can you take over a project already built with three.js?
Yes. First we read it: its release, its renderer and shaders, its models, its tests, and how it’s built and deployed. Then we pick a first piece of work together, a person on our side takes charge of it, and we work beside any developers you already have.
What does it cost?
That depends on the scenes and on the first step you pick. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can AI assistants help with our 3D code?
Yes. Whatever an assistant drafts is compared against the scene as it was, and a person reviews it before it merges.
Can we hire developers for our own team?
Yes. Within 48 hours of your request we introduce developers who work on 3D for the web, each working in your time zone, and you meet them before you decide who joins.
Webair is independent of the three.js project, and isn’t sponsored by, endorsed by or affiliated with it. WebGL and the WebGL logo are trademarks of the Khronos Group Inc. glTF and the glTF logo are trademarks of the Khronos Group Inc.
Let’s build it better
Tell us what your 3D needs to show and who it’s for, and we’ll suggest a first step in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}