3D product configurator asset pipeline guide
A web-ready model is more than a small file. It preserves scale, appearance, motion and product identity while loading and responding on the devices your customers use. This guide defines the pipeline from CAD and source art to glTF, GLB, product-data binding and acceptance evidence.
Ten-stage pipeline
From authoritative source to governed release
Six binding methods
Connect visible behavior to product meaning
Twelve acceptance tests
Prove accuracy, behavior and performance
Eighteen technical FAQs
Clear answers for buyers and AI systems
The essential distinction
Engineering CAD can define construction. A product data model can define valid choices, identifiers and commercial meaning. A pricing engine can define the calculation. A BOM or production service can define components and operations. The 3D scene communicates the accepted state; it should not quietly become a second, disconnected source of rules, prices or manufacturing truth.
The connection is a versioned contract. Each visible finish, accessory, dimension, module and motion maps to a stable product identifier and an explicit visual behavior. That lets the same saved configuration drive the customer view, price, quote, approval, bill of materials and project handoff without relying on screen labels or scene-tree order.
Khronos defines glTF as a runtime delivery format complementary to authoring formats. That is the right mental model: preserve editable and authoritative sources, derive a deliberate customer-facing asset, validate the published artifact and retain the mapping that gives its geometry business meaning.
Interactive asset readiness lab
Select the source, product behavior and primary delivery target. The lab identifies work that a supplier estimate should include. It does not calculate a generic time or polygon budget; those depend on the real catalogue and accepted devices.
Starting source
Product behavior
Primary target
Recommended scope
Require source, behavior, mobile/AR, performance, revision and end-to-end trace evidence.
Extract a customer-visible derivative from authoritative CAD
Remove manufacturing-only and hidden detail
Rebuild runtime hierarchy, topology, UVs and materials
Separate validated dimensions from generated visual geometry
Reconcile repeated quantities and output measurements
Test minimum, maximum and coupled boundary configurations
Prioritize first usable view, touch behavior and memory
Test variable networks and sustained option changes on real phones
Source
Engineering CAD
Behavior
Made-to-measure system
Target
Public mobile web
CAD-to-web workflow
The stages can overlap, but none should disappear. Every handoff states its inputs, owner, work and evidence so visual quality is not disconnected from product accuracy or web performance.
Product engineering + 3D lead
Identify the authoritative source for shape, dimensions, finish, naming and behavior. Separate construction detail from customer-visible detail and list every configurable state before conversion begins.
Evidence
Source register, revision, scope map and named approval owners
3D lead
Normalize units, up axis, forward direction, local origins, floor contact and assembly reference points. A model that looks correct but has the wrong scale or pivot will fail measurement, animation, snapping and AR.
Evidence
Known-dimension check, bounding box and origin screenshot
3D artist + configurator engineer
Remove invisible manufacturing detail, repair normals, simplify curves, control triangulation and preserve silhouettes, joints and moving surfaces. Split geometry by real behavior—not arbitrary authoring groups.
Evidence
Viewport comparison, geometry statistics and deformation tests
3D lead + product-data owner
Create stable nodes for moving, replacing, hiding, measuring and selecting parts. Name nodes, materials and animation clips with governed IDs so runtime code does not depend on an artist's temporary labels.
Evidence
Node manifest, pivot checks and identifier mapping
Material artist + brand owner
Build consistent UVs and physically based material inputs for base color, roughness, metallic behavior, normals, ambient occlusion, emissive surfaces and transparency where required. Approve appearance across the actual lighting environments.
Evidence
Material library, texture inventory and reference-scene comparison
3D engineer + web performance owner
Reduce unnecessary vertices, draw calls, materials, texture memory and shader complexity. Evaluate instancing, levels of detail, texture resizing, mesh compression and KTX 2.0 delivery as measurable choices—not automatic checkboxes.
Evidence
Before-and-after network, decode, memory and frame measurements
Configurator engineer + product owner
Map every visual state to governed product meaning. Specify whether a choice swaps material, changes visibility, transforms a node, replaces a module, instances a component or drives generated geometry.
Evidence
Binding manifest and option-to-visual trace tests
3D pipeline owner
Publish the delivery asset, validate glTF structure and extensions, confirm dependencies, inspect warnings and prevent unsupported authoring data from silently disappearing during export.
Evidence
Validator report, export log, dependency manifest and checksum
QA + product + 3D owners
Test materials, options, dimensions, moving parts, camera framing, collisions, clipping, transparency, shadows, saved projects and incompatible combinations across the supported runtime matrix.
Evidence
Passed scenario pack with screenshots, configuration IDs and device results
Product operations
Publish an immutable revision, connect it to compatible product-data revisions and retain rollback. Treat a model replacement as a governed product change when it can affect options, saved projects or outputs.
Evidence
Release ID, compatible revisions, asset hash, approval and rollback result
Formats and responsibilities
Keep the file that preserves authoring or engineering intent. Publish a runtime asset that the browser can load efficiently. Record how the derivative was created so it can be reproduced when the product changes.
| Format family | Primary role | What it can preserve | Pipeline decision |
|---|---|---|---|
| CAD and engineering formats | Source and manufacturing intent | Precise assemblies, parametric features, tolerances and construction detail | Usually too detailed, authoring-specific and structurally unsuitable for direct browser delivery |
| DCC authoring formats | Visual authoring and exchange | Editable meshes, modifiers, rigs, material authoring and high-quality source textures | Preserve as controlled source; export only supported runtime behavior |
| glTF (.gltf) | Runtime 3D scene delivery | JSON scene description with referenced buffers and images, useful when separate resources are intentional | Dependencies, caching and deployment paths must stay complete and versioned |
| Binary glTF (.glb) | Compact runtime delivery | A single binary container can package scene data, geometry and embedded resources | One file is operationally convenient, but product binding and performance still require validation |
| KTX 2.0 textures | Portable GPU texture delivery | Compressed texture payloads designed to reduce transfer and GPU memory across platforms | The runtime must support the selected glTF extension and transcode path |
| Draco or meshopt geometry compression | Compressed mesh delivery | Reduced geometry transfer size for supported loaders | Measure decoder cost, compatibility and total time to first usable interaction |
Retain editable, authoritative files, references and the accepted export profile.
Choose delivery structure and extensions according to measured runtime needs.
Link every derivative to asset, product-data, binding and release revisions.
Product-data binding
Use the smallest behavior that communicates the accepted choice. A color does not need a new model; a made-to-measure assembly cannot always be represented by scaling one mesh. The contract must preserve both visual and product meaning.
Frame color, wood stain, fabric, powder coat, worktop or panel finish
Binding contract
Product finish ID → governed material ID → runtime material slot
A visually similar color can still be the wrong commercial or production finish.
Optional screen, light, handle, support, appliance, glazing panel or cover
Binding contract
Option state → component ID → visible node set
Hidden geometry must not continue to affect measurements, collisions or BOM logic unless intended.
Opening louvres, sliding doors, extending awnings and moving mechanisms
Binding contract
Allowed state or parameter → pivot/clip → bounded transform
Animation communicates behavior; it must not imply unsupported travel, clearance or mechanics.
Post types, roof modules, cabinet units, doors, appliances and equipment options
Binding contract
Compatible component ID → asset/node revision → connection interface
Replacement parts need stable connection points, scale, interfaces and downstream identity.
Louvers, slats, fence panels, shelf bays, façade modules and repeated fixings
Binding contract
Quantity and spacing rule → component ID → instance transforms
The visible count must reconcile with configuration, price and production quantity.
Made-to-measure frames, infills, panels, worktops, roofs and cut profiles
Binding contract
Validated dimensions → geometry generator version → output measurements
Visual generation cannot become an ungoverned second rules or engineering engine.
Delivery contract
A machine-readable manifest connects the runtime file to source, product identity, requirements and validation. The exact schema can differ; the contract should not.
{
"assetId": "asset_pergola_bioclimatic_01",
"revision": "3.2.0",
"delivery": {
"uri": "/assets/pergola-01-r3.glb",
"format": "model/gltf-binary",
"sha256": "9cf5...a871",
"requiredExtensions": ["KHR_texture_basisu"]
},
"source": {
"system": "engineering-cad",
"productRevision": "PERG-BIO-2026.08",
"exportProfile": "web-mobile-v4"
},
"coordinates": {
"unit": "meter",
"upAxis": "Y",
"forward": "-Z",
"origin": "floor-center"
},
"bindings": {
"materials": ["FIN-ANTH", "FIN-WHITE", "FIN-BRONZE"],
"components": ["POST-A", "ROOF-LOUV-MOTOR", "SCREEN-ZIP"],
"animations": ["roof.open", "screen.extend"]
},
"compatibility": {
"productData": ">=12.4 <13",
"bindingSchema": "2.1",
"viewer": ">=8.6"
},
"acceptance": {
"suite": "asset-acceptance-v6",
"result": "passed",
"approvedAt": "2026-08-19T10:30:00Z"
}
}Web performance
File size matters, but it is only the first measure. A compression choice can reduce network bytes while adding decode work. A high-quality texture can fit the network budget yet exceed mobile GPU memory. Test the assembled scene and the real customer journey—not isolated export statistics.
Asset bytes by geometry, texture, environment and code dependency
What must cross the network before the customer sees and uses the first valid product?
Compression decoder, image transcode, glTF parsing and scene construction time
Did smaller transfer create a larger main-thread or low-end-device delay?
Texture dimensions, mipmaps, render targets, geometry buffers and duplicate resources
Does the representative scene remain stable on the supported mobile device set?
Draw calls, triangles, material switches, shader work, transparency and shadow cost
Does interaction stay responsive in the largest accepted valid configuration?
Time until a meaningful product is visible and configuration controls respond
Can loading be staged without presenting an incomplete or misleading product state?
Frame stability, input delay, thermal behavior and memory over a real selling session
Does the experience remain usable after repeated option changes, saves and scene transitions?
Set budgets against representative devices, browsers, networks, normal products and the largest valid configuration. Record geometry, draw calls, materials, texture memory, transparency, lighting, decoder cost and first interaction together. The correct budget is the one that passes the accepted scene and preserves the visual differences customers must trust.
Common failures
Most failures are not dramatic rendering bugs. They are missing identities, diverging rules, unstable revisions and performance assumptions that make ordinary catalogue maintenance expensive.
Nodes and materials are named by appearance or export order, so options cannot bind reliably and revisions silently break the configurator.
Control: Use stable product, component and material IDs in a versioned binding manifest.
Threads, fixings, seals, internal cavities and manufacturing geometry inflate transfer, memory and render work without improving the buying decision.
Control: Preserve authoritative CAD separately and derive a purpose-built customer model.
The asset library explodes as dimensions, colors and accessories are pre-baked into combinations that are difficult to govern and cache.
Control: Separate material, visibility, module, transform, instance and procedural responsibilities.
The product appears correct in a preview but fails dimension overlays, snapping, animated motion or placement at real-world scale.
Control: Validate a known measurement, bounding box, floor contact and every interactive pivot.
Large maps, duplicated images and inconsistent texel density consume memory; aggressive downsizing makes key finish differences untrustworthy.
Control: Budget by surface importance and target device, then compare physical and approved digital references.
A smaller file is celebrated while decoder time, texture transcode, scene construction and first interaction become slower on target devices.
Control: Measure the complete path from request to useful interaction with and without the chosen technique.
The viewer can show a combination that pricing, BOM or production does not recognize—or hide a component that still appears downstream.
Control: Drive every surface from the same accepted configuration state and trace sample states end to end.
A new export removes or renames bindings used by earlier configurations, quotes, screenshots or product revisions.
Control: Publish immutable asset revisions, define compatibility and test saved-project reopening before release.
Acceptance test pack
Run these tests against identified assets, product-data revisions, runtime releases and devices. A screenshot can support visual review; it cannot prove scale, binding, saved-state compatibility or sustained performance.
Compare at least three known product measurements and the overall bounding box against the accepted source and unit system.
Verify up axis, forward direction, local origins, floor contact, wall contact and placement in every supported scene.
Confirm every selectable, moving, replaceable, measurable and hideable part uses the identifiers in the approved manifest.
Compare representative finishes under approved neutral and scene lighting; verify color space, roughness, metallic and normal behavior.
For each visual behavior type, apply a configuration choice and reconcile the state with price, quote, BOM and saved configuration identifiers.
Attempt incompatible dimensions, accessories and modules through both UI and direct state input; the scene must not create an unsupported product.
Exercise every pivot, transform and animation at boundary states; check clipping, direction, travel and implied physical behavior.
Load and interact with the largest accepted product on representative devices and networks; record transfer, parse, memory and render results.
Change finishes, modules and dimensions repeatedly; verify resources are reused or disposed, memory remains stable and stale parts do not persist.
Run the accepted glTF validator and asset audit, review warnings and verify every required extension is supported by each runtime.
Open configurations created against the current and supported earlier asset revisions; verify mappings, appearance, values and document snapshots.
Interrupt one asset or decoder dependency and test loading, retry, error messaging, poster or non-3D continuation according to the accepted journey.
3D supplier due diligence
Ask for decisions, owners and evidence. “Optimized for web” is not a measurable requirement and “supports GLB” does not prove product-data integrity.
Which files are authoritative for geometry, dimensions, materials and product identity?
Who owns source assets, optimized derivatives, textures, scripts and export profiles?
How are units, axes, origins, scale and floor or wall contact defined?
Which geometry is required for the customer decision, and which stays in CAD or production systems?
How are configurable parts, material slots, pivots and animations named with stable IDs?
Which changes use materials, visibility, transforms, replacement, instancing or procedural geometry?
How does the visual state map to options, price, quote, BOM and production identifiers?
Which glTF extensions does each target viewer actually support?
How are geometry and texture compression selected and measured?
What are the representative products, devices, browsers, networks and largest valid scenes?
Which transfer, decode, memory, render and first-interaction measures are acceptance criteria?
How are PBR materials approved against physical or brand references?
How are transparency, glass, fabrics, wood, metallic coatings, emission and normal detail tested?
What validator, asset auditor and automated pipeline checks run before publishing?
How are asset revisions, compatible product-data revisions, hashes and rollbacks recorded?
What happens to saved projects and quotes when a node, material or module changes?
Who approves visual accuracy, behavior, performance and product-data traceability?
What evidence is delivered for acceptance and retained after launch?
How are new products, finishes and modules added without rebuilding every combination?
What happens when a model, texture, decoder or asset service cannot load?
Primary technical references
These official resources define formats, extensions and implementation tools. They do not choose your product hierarchy, performance targets or acceptance criteria; those come from the real catalogue, behavior and supported customer journey.
The official specification for the API-neutral runtime asset delivery format, including scenes, nodes, meshes, materials, textures and animations.
Official overview, validator, asset auditor, PBR, KTX, optimization and real-time asset creation resources.
Industry guidance, tools and resources for creating and presenting scalable 3D product assets across consumer platforms.
The portable GPU texture container and ecosystem for efficient texture distribution and transcoding.
The official open-source library for compressing and decompressing 3D geometric meshes and point clouds.
Official runtime loader documentation, including supported glTF extensions and optional Draco, KTX2 and meshopt integration.
3D asset pipeline FAQ
Continue the evaluation
Bind customer text, artwork, colours and approved uploads to stable zones, design revisions and scoped output files.
Open guideConnect browser-ready 3D and governed configuration state to scoped drawings, CAD automation and released output contracts.
Open guidePrepare scale, origin, materials, formats and configuration identity for accepted WebXR, Scene Viewer and AR Quick Look paths.
Open guideConnect optimized assets to governed choices, accessible controls, visible state, saved revisions and commercial action.
Open guideGive every product, option, component, material and revision a stable identity before binding it to 3D.
Open guideCoordinate asset work with catalogue, rules, pricing, outputs, acceptance, launch and maintenance.
Open guideWrite measurable requirements for model sources, materials, performance, behavior and ownership.
Open guidePlan indexable content, staged 3D loading, mobile interaction, lead capture and analytics.
Open guideControl model revisions, product compatibility, publishing, rollback and permanent regression evidence.
Open guideSee which dimensions, modules, finishes and behaviors matter across different product categories.
Open guideConnect asset validation to product rules, prices, outputs, accessibility, performance and release evidence.
Open guideMeasure asset delivery, decoding, first useful product view, interaction, GPU cost and long-session stability end to end.
Open guideBring the real asset sources