They are not competing products
This is the first thing to get straight, because the comparison is usually framed as a fork in the road. Both features live inside Threekit and both consume the same input: a clean, real-time-ready 3D asset with PBR materials and a working variant structure. If that asset does not exist, neither option produces anything good. What differs is when the pixels are computed, in the browser at click time, or on a render farm weeks earlier.
That single difference cascades into cost, load time, AR support and how well the setup survives a catalogue that keeps growing.
Side-by-side comparison
How the image is produced
Real-time WebGL
The browser renders the model live on every option click, using the shopper's GPU.
Virtual Photographer
Threekit's render farm produces images ahead of time; the browser swaps a JPG or WebP.
Variant explosion
Real-time WebGL
Flat cost. 12 finishes x 8 frames x 4 sizes is the same asset, resolved by the rules engine.
Virtual Photographer
Linear cost. Every combination is a separate render job, and re-renders repeat on any material change.
First load
Real-time WebGL
2–4 s for a well-optimised glTF (Draco or Meshopt, KTX2 textures, sub-3 MB payload).
Virtual Photographer
Under 1 s. It is just an image, cached at the CDN edge.
Visual ceiling
Real-time WebGL
Excellent with good PBR materials and an HDR environment, but bounded by real-time lighting.
Virtual Photographer
Higher. Offline path tracing gives true global illumination, caustics and depth of field.
AR
Real-time WebGL
Native. The same asset exports to USDZ and GLB for Quick Look and Scene Viewer.
Virtual Photographer
Not possible from images alone; needs a real-time asset alongside.
Interaction
Real-time WebGL
Free orbit, zoom, part-level hotspots, exploded views, animation.
Virtual Photographer
Fixed camera angles, or a spin set if you render a turntable.
Low-end mobile
Real-time WebGL
Needs LOD swapping and texture budgets to hold 60 fps on mid-range Android.
Virtual Photographer
Flawless everywhere. No GPU work at all.
Time to launch
Real-time WebGL
Longer. Retopology, UVs, materials, rules and performance tuning per product family.
Virtual Photographer
Shorter for a first catalogue, provided the option set is small and stable.
The variant maths that decides most projects
Pre-rendering is priced per image. A sofa with 3 sizes, 14 fabrics and 4 leg finishes is 168 configurations. At 5 camera angles that is 840 renders: and one fabric supplier change means re-rendering a slice of the whole set. The same product in real time is one asset, 14 material definitions and a rules file. Add a fifteenth fabric and you upload a texture set.
The crossover point in our experience sits somewhere around 40 to 60 configurations per product family. Below it, pre-rendered imagery is faster and cheaper to launch. Above it, real-time wins on both cost and maintenance, and the gap widens every quarter the catalogue grows. If you are still scoping which route to take, How to build a 3D product configurator walks through the asset pipeline both approaches depend on.
When Virtual Photographer is the right call
- Listing pages, category grids, email and print, where a fixed hero angle beats an interactive canvas.
- Small, stable option sets: a watch in four colourways, a kettle in three finishes.
- Products whose appeal lives in lighting and finish quality: jewellery, glassware, polished metals, anything with caustics or subsurface scattering.
- Markets on low-end devices or constrained bandwidth, where a WebGL canvas would stutter.
- Replacing a photo studio. Cost per image lands well under a physical shoot, with no sample shipping and no reshoots for a colour change.
When real-time WebGL is the right call
- Made-to-order and configure-to-order products where the shopper is designing, not just picking.
- Anything with an AR requirement: furniture, appliances, fixtures. Images cannot be placed in a room.
- Large or fast-moving option sets, where the render bill would compound every season.
- Products that need part-level interaction: exploded views, hotspots, opening doors, adjustable dimensions.
- B2B quoting flows where the 3D view feeds CPQ pricing and a downloadable spec.
The hybrid setup most catalogues end up with
Build one optimised 3D master per product family, then feed both pipelines from it. Use pre-rendered stills for listing pages, ads and marketplaces, where a fast image and a consistent hero angle matter more than interaction. Use the real-time configurator on the product detail page and for AR. Because both outputs derive from the same source asset, materials stay consistent across the storefront, which is the failure mode when photography and 3D are produced separately and the fabric never quite matches.
The practical implication for scoping: budget for asset quality first, then decide the delivery mode. Feature checklists rarely decide these projects. Product configurator software: 12 features that matter covers what to look for in the platform layer once the assets are sorted.
What "configurator-ready" means for either route
The asset requirements overlap almost completely, which is why the choice can be deferred without wasting production budget:
- Retopologised meshes from CAD, not raw tessellated exports: a 200 MB STEP conversion is unusable in either pipeline.
- Non-overlapping UVs and a coherent texel density, so a fabric reads at the same scale on a cushion and an armrest.
- PBR material sets: base colour, metalness, roughness, normal and AO, authored against a reference HDR environment.
- A variant structure that mirrors your SKU logic, so the rules engine and the ERP agree on what exists.
- Real-time budgets on the master: Draco or Meshopt geometry compression, KTX2 textures, LODs. Pre-rendering tolerates heavier assets, but keeping the budget lets you switch later at no cost.
Frequently asked questions
What is the difference between Threekit WebGL and Virtual Photographer?
WebGL renders the 3D model live in the shopper's browser on every option change. Virtual Photographer renders the same model offline into 2D images that the storefront serves as static assets. Same source asset, different render moment.
Which one is cheaper?
Pre-rendered imagery is cheaper below roughly 40–60 configurations per product family and gets more expensive as variants multiply. Real-time costs more to prepare once, then stays flat no matter how many combinations exist.
Does Virtual Photographer support AR?
No. AR Quick Look and Scene Viewer need a real USDZ or GLB file. Any AR requirement means producing a real-time asset regardless of what the product page displays.
Which looks more photorealistic?
Offline rendering, on absolute quality. It can afford path tracing, true global illumination and depth of field. A well-authored real-time asset under an HDR environment gets close enough that most shoppers cannot tell, and it moves.
Can we start with one and switch later?
Yes, if the master asset is produced to real-time budgets from the start. Going the other way, trying to bring a heavy render-farm asset into WebGL, usually means redoing topology and textures.
How does this compare to Unity for configurators?
Unity WebGL builds ship a large runtime and are heavy for a product page; they make sense when the same experience must run in a native app or on a showroom kiosk. For web commerce, Threekit or a three.js build loads faster and indexes better.