3D product visualization means showing a product using a 3D model rather than a photograph. That splits into two quite different things: pre-rendered images and video, computed once on a render farm and delivered as files; and real-time visualization, where the model is sent to the browser and rendered live on the customer's own device, so they can turn it, zoom it and inspect it.
Both are called "3D product visualization" and they behave nothing alike: different costs, different turnaround, different failure modes, different people producing them. Almost every project that goes wrong here went wrong by choosing one while expecting the other's properties. This page explains the split, then covers what happens in a browser specifically: how PBR materials and HDR lighting work, what a model has to weigh, and where real-time stops being the right answer.
Built by
Peter Csipkay
Creative frontend developer near Munich, and the person behind this site. I scope, build and ship the work myself.
Live demo
A demonstration built for this page rather than a shop — the product is a CC0 sample model. Nothing to press: it starts by itself, and costs about 780 KB of model, once.
Model: “Sheen Chair” © 2020 Wayfair, LLC, released under CC0 1.0. Optimised to 776 KB with meshopt geometry compression and WebP textures. Prices shown are illustrative.
Pre-rendered means an offline renderer (Cycles, V-Ray, Redshift, Octane) computes each image over seconds to hours, simulating light physically. Output is a PNG, a JPEG or a video file. The result can be indistinguishable from photography. It can also be impossible in photography: a cutaway, an impossible camera move, a product that does not exist yet.
Real-time means the model is downloaded and drawn by the customer's GPU sixty times a second, in a browser, with no install. It never looks quite as good as a good offline render. In exchange, the customer controls it.
The properties that actually differ:
| Pre-rendered | Real-time in the browser | |
|---|---|---|
| Visual ceiling | Photoreal | Very good, not photoreal |
| Interactive | No | Yes |
| Delivery | Image and video files | A model plus a web viewer |
| Cost driver | Per image, per second of video | Per model, once |
| A new colour later | New render, new cost | Already a swatch |
| Weight | A JPEG | 2–8 MB of model and textures |
| Works everywhere | Yes | Needs a working GPU |
| Best for | Hero shots, campaigns, print | Inspection, choice, engagement |
The clean way to decide: if the customer's question is "what does it look like", render it. If the question is "what does it look like from underneath / in green / with the other handle", make it real-time.
Plenty of projects want both, and that is a coherent plan rather than a compromise. One prepared model can feed an offline renderer for campaign imagery and a compressed export for the web. Building both from one asset is usually cheaper than commissioning them separately, and it is worth deciding at the start, because the modelling requirements differ.
Real-time rendering on the web is physically based. A material is described by a few maps (base colour, metalness, roughness, normal, occlusion), and the renderer uses those with the scene lighting to approximate how light behaves. It is the same mental model as an offline renderer, with a cheaper approximation underneath.
The practical consequence: materials are authored, not photographed. Brushed aluminium is a roughness value and a directional normal map, not a picture of brushed aluminium. Getting a material to read correctly is where realism lives, far more than polygon count. Anisotropy, clearcoat, transmission and sheen (for brushed metal, car paint, glass and fabric respectively) all exist in glTF and in Three.js, and each costs performance.
The most common reason a web 3D product looks cheap is lighting, not modelling. Three point lights produce a flat, plastic look. Real product photography is dominated by large soft sources and by reflections of the environment.
The real-time equivalent is image-based lighting: an HDR environment map, pre-filtered into a lighting probe, providing both diffuse light and the reflections seen in the surface. One good HDR does more for realism than any amount of extra geometry. HDR files are heavy, though. A 1K HDR is comfortably over a megabyte, so a small, resolution-appropriate map, or a procedurally generated studio environment, usually beats a large one.
The whole point of real-time is that it starts quickly. The constraint is that everything must arrive before anything renders. In practice that means geometry compressed with Draco or Meshopt; textures in KTX2/Basis, which stay compressed in GPU memory rather than expanding to raw RGBA; texture resolution chosen for how large the product will appear on screen; and lazy loading, so the viewer downloads nothing until the visitor scrolls to it or clicks to start it.
A viewer that costs 30 MB and eight seconds is not product visualization. It is a bounce.
For rendered imagery the unit is the image. Cost per shot depends on how much modelling is needed, how complex the materials are, and how many revisions the approval process generates. Ten angles cost roughly ten times one angle, and a colourway added after approval is a new render.
For real-time the unit is the product. The model is prepared once and then rotates, zooms, changes colour and appears on every device for the same cost. Adding a tenth colour is a swatch, not a shoot.
That difference is what makes the choice a business decision rather than a taste one. A single hero product with two annual campaign images is a rendering job. A catalogue of forty SKUs each in six finishes, refreshed seasonally, is a real-time job, and the crossover point arrives sooner than most people expect.
What actually drives cost in both cases:
A single product prepared for the web (modelling from good CAD, material authoring, lighting, a viewer on your page) is a matter of weeks, not months. Most of that is not the viewer. The viewer is the last and smallest part.
Rendered imagery follows the shape of any production job: modelling, look development, an approval round on low-resolution frames, then final renders. The render itself is machine time and is rarely the bottleneck. Approval is.
The scheduling advice is the same for both: fix the look on one product before starting the other nine. Approving a lighting setup once and reusing it is the difference between a catalogue that takes a month and one that takes a quarter.
Three.js is what puts real-time 3D on a normal web page. No plugin, no app, no store — a URL. It handles glTF loading, PBR materials, image-based lighting, and the compression formats above, and it runs on essentially every device with a working GPU.
WebGPU, which Three.js targets through its node system and TSL, matters when the scene gets ambitious: many objects, dynamic lighting, real post-processing, or compute work. For one product on a plinth you will not see the difference, and I will not charge you for one. Where it does change what is possible is at the top end, the point where a real-time scene starts approaching what used to require an offline render.
I build with WebGL as the fallback path in all cases. A visitor on hardware without WebGPU gets the same product, rendered the older way.
If you want to see how a model behaves before committing to anything, the GLB viewer on this site will load your own file in the browser and show you what it weighs and how it lights.
Buying real-time and expecting a render. The single most common failure. Someone approves a photoreal render, then receives a real-time viewer that necessarily looks slightly different, and feels short-changed. Set that expectation on day one by comparing them side by side on the actual product.
Uncompressed textures. A 4K texture set per material, uploaded raw, exhausts mobile GPU memory quickly. The tab reloads with no error message and everyone blames the phone.
Lighting as an afterthought. A carefully modelled product under three point lights looks like a game asset from 2009. Budget for the HDR environment and the look development; it is the highest-return part of the work.
Modelling detail nobody will ever see. Screws on the underside of a product that only rotates on its vertical axis. Decide the camera constraints first, then model to them.
Ignoring what happens before the model loads. Several seconds pass before anything appears. If that time shows an empty rectangle rather than a poster image and a progress indication, a good number of visitors will never see the 3D at all.
No plan for the second product. The first one is bespoke. If the pipeline, naming and material library aren't set up during it, products two through forty each cost like the first one did.
Budget
Rendered imagery is priced per shot and real-time is priced per product, so a single published range would mislead in both directions. Send the product list and the current source files and you get a written quote against them, broken down by phase.
Schedule
3–5 days
Check what source files exist and what state they are in, agree reference imagery, and decide rendered, real-time, or both.
1–3 weeks
Model or retopologise, UV-map, author PBR materials against the real product. The phase where realism is won or lost.
3–5 days
HDR environment, camera framing, one product taken all the way to approval so the remaining products can follow it.
1–2 weeks
Draco/Meshopt geometry, KTX2 textures, load-time budget, the viewer embedded in your page with lazy loading and a fallback image.
Scales with catalogue
Each additional product through the established pipeline, at a fraction of the first one’s cost.
Phases overlap in practice, and the ranges assume decisions arrive when they are needed. The one that slips most often is the first.
Proof
An interactive 3D city map built with vanilla Three.js and custom models, letting visitors explore an innovation campus from a bird's-eye view. Not a product viewer, but the same discipline: custom models, real-time lighting, and a scene that has to load and run on ordinary hardware.
Client projects I can show publicly are on the services page. Some work sits under NDA — ask on a call and I will say what I can.
F.A.Q
3D rendering usually means pre-rendered output: an offline renderer computes an image or a video over seconds to hours and you receive files. 3D product visualization is the broader term and includes real-time, where the model is sent to the browser and drawn by the visitor's own GPU so they can rotate and inspect it. Pre-rendered reaches photoreal quality but is fixed; real-time is interactive and endlessly reusable but does not quite reach photoreal. Most confusion in this field comes from the two being sold under one name.
If the customer's question is "what does it look like", render it. Hero shots, campaign imagery and print are pre-rendered work. If the question is "what does it look like from underneath, or in green, or with the other handle", make it real-time. Catalogues with many variants tip toward real-time quickly, because a new colourway is a swatch rather than a new render. Many projects justify both from a single prepared model, which is cheaper than commissioning them separately.
CAD or existing 3D source is fastest. It gets retopologised, UV-mapped and re-authored with PBR materials for real-time use. Photographs and measurements are workable but mean modelling from scratch, which is a separate phase with its own cost and timeline. Either way, reference photographs of the real product under known lighting are essential for getting materials to match; the model is rarely the hard part, the materials are.
Convincing enough that people routinely mistake good real-time renders for photographs in a small viewport, and not quite photoreal under scrutiny at full screen. The gap is mostly in light transport (soft shadowing, multiple bounces, accurate refraction), which offline renderers simulate and real-time renderers approximate. Physically based materials and a good HDR environment close most of the visible gap. Ambitious lighting and post-processing, particularly on WebGPU, close more of it.
A well-prepared single product usually lands between two and eight megabytes including textures: geometry compressed with Draco or Meshopt, textures in KTX2/Basis so they stay compressed in GPU memory. Uncompressed, the same product can easily exceed forty megabytes, which is what causes mobile tabs to reload without an error. Lazy loading matters as much as size: nothing should download until the visitor scrolls to the viewer or presses play.
Only if it is built to. The viewer should not download or initialise until the visitor reaches it, so the page's own load time and Core Web Vitals are unaffected. The product page must render fully server-side (name, description, price, images) with the 3D as an enhancement on top. If the viewer is the page's largest content element, or if it blocks first render, that is a build problem rather than an inherent cost of 3D.
Yes, and it is one of the better arguments for the investment. One well-prepared model can drive a real-time web viewer, an AR view on a phone, campaign renders, print imagery and trade-show displays. The caveats: AR needs a second export path, because Android reads glTF and iOS Quick Look wants USDZ; and print or campaign renders usually want higher-resolution textures than the web export ships. Plan the variants at the start and the pipeline produces all of them from one source.
The first product is the expensive one, because it establishes the pipeline: lighting setup, material library, naming conventions, compression settings, the viewer itself. Everything afterwards runs through that pipeline at a fraction of the cost. If a catalogue rollout is the goal, say so at the start. It changes how the first product is built, and retrofitting a pipeline after ten bespoke products is the expensive way to arrive at the same place.
Tell me what you are selling, what files exist today, and where the visuals need to appear. I will tell you whether rendered imagery, a real-time viewer or both is the right answer. If the honest answer is a photographer, I will say that too.
Get In Touch
Tell me what you're trying to build, big or small. I'll reply personally within 24 hours, usually same day.
Peter Csipkay
Creative Frontend Developer
Let's connect
Three.js developer and creator of threejsresources.com. I scope, build, and ship the work myself — no middlemen, no handoffs.
Based in
Munich, Germany
Testimonials
Don't just take my word for it — here's what people I've worked with have to say.
“Peter is different from other front end developers. He understands design along with the tech stack. He successfully resolved bugs and optimized the webapp quickly. I appreciate his good work ethic. He is very logical and manages to capture ideas perfectly.”
“Amazing work with super fast turn around. I'm thrilled!”
“Peter is a great resource. I enjoyed working with him. I will definitely work with him again.”
“Was a pleasure to work with. Very reliable and motivated to deliver great work. I can highly recommend him.”
Keep reading
Let customers change material, colour, size and components and see the result render live, with the price updating as they go.
Getting a model from a CAD export that will not load to a web file that does, without it looking like a different product.
The overview page: what I do, selected client work, and how a project usually starts.
Free tools