Preparing 3D Product Assets for Browser Delivery

A model that renders well in an offline CGI scene is not automatically suitable for a browser. Real-time product assets must balance silhouette, material quality, download size, GPU memory and interaction speed across a defined device range.

Optimisation should begin with the use case. A freely rotating configurator, an animated product story and a small decorative viewer do not need the same asset.

Choose the delivery specification first

Before reducing polygons, define:

• Target browsers and mobile devices
• Expected camera distance
• Maximum zoom
• Required animations
• Configurable components
• Initial loading target
• Offline or cached behaviour
• Fallback for constrained devices

Without these constraints, “optimised” has no measurable meaning.

Clean the source geometry

Engineering CAD and offline render models contain detail that may never affect the browser image. Remove or simplify:

• Hidden internal assemblies
• Duplicate and overlapping parts
• Tiny fasteners invisible at the closest camera
• Manufacturing features that do not change the silhouette
• Dense bevels that can be represented by normal maps
• Geometry outside the approved configuration

Do not optimise every part equally. Preserve the silhouette, major highlight edges and components customers inspect closely.

Build a useful hierarchy

A configurator needs predictable object names and groups. Organise meshes around interaction and material changes rather than the source application’s export history.

Separate parts when they:

• Switch independently
• Animate independently
• Use different materials
• Need a hotspot or selection state
• Are optional in some configurations

Combine parts when separation adds draw calls but no useful control.

Manage polygon density deliberately

Polygon count is only one performance measure. Many separate meshes, material changes and transparent surfaces can be expensive even when the total triangle count appears modest.

Inspect:

• Triangles at the closest view
• Mesh and draw-call count
• Material count
• Skinning or morph targets
• Transparent layers
• Shadow-casting geometry

Level-of-detail models can reduce complexity as the camera moves away, but they also add production and testing work. Use them where the product or scene scale justifies the trade-off.

Treat textures as a memory budget

Large textures affect download size and GPU memory. A product with several 4K maps may be much heavier than its model geometry.

Plan resolution by visible detail. A hero label may need more density than the underside of a housing. Share texture sets where appropriate and avoid unused channels.

KTX 2.0 and Basis Universal can deliver GPU-friendly compressed textures. Khronos’ glTF compressor supports KTX 2.0 generation and interactive quality tuning.

Use physically based materials carefully

glTF’s physically based material model is a practical baseline for product assets. Match values to the target renderer and test under the actual environment lighting.

Common problems include:

• Metals exported as grey plastic
• Roughness ranges that are too narrow
• Normal maps with the wrong orientation
• Colour textures interpreted in the wrong colour space
• Transparent materials sorted incorrectly
• Offline procedural materials with no baked equivalent

Build a browser material review scene before integrating the full interface.

Compress geometry with a measured quality target

Geometry compression can reduce transfer size, but the asset must be decoded before use. Test visual error and startup behaviour on representative devices.

The goal is not the smallest possible file. It is the smallest file that preserves the approved silhouette and interaction quality.

Design progressive loading

The Three.js guide to loading 3D models demonstrates glTF loading and highlights common import issues. A production experience should also define what the customer sees before the full model is ready.

Possible stages include:

1. Product poster image
2. Interface shell and loading progress
3. Base model and primary material
4. Secondary variants
5. Optional high-detail or animation assets

Load the default configuration first. Do not block the first useful view on every possible option.

Bake what does not need to be dynamic

Ambient occlusion, small surface detail and some lighting information can be baked into textures. This can improve perceived richness without adding geometry or expensive runtime effects.

Keep truly interactive effects dynamic. A product whose colour changes cannot have all colour information permanently baked into one texture.

Test the complete experience

Asset metrics only become meaningful inside the interface. Test:

• Time to first product view
• Time to interactive controls
• Peak memory use
• Frame rate while rotating
• Option-switch latency
• Visual quality at closest zoom
• Background-tab and resume behaviour
• Mobile thermal behaviour during longer sessions

Check low and mid-range devices, not only the workstation used to build the model.

Keep the master and delivery asset separate

Maintain a high-quality master asset as the source of truth. Generate browser assets through a documented pipeline so future product updates do not depend on manually repeating dozens of optimisation steps.

Our 3D configurator service connects that asset pipeline to interface design, product logic and commerce integration.