A 3D product configurator is a product-definition system with a visual interface. It takes a known product family, records a user's choices, applies compatibility and completeness rules, asks the right system for price or availability, updates a 3D representation, and sends a reproducible configuration to the next commercial or operational step. The 3D view helps someone understand the product. It should not become the hidden source of product truth.
That distinction is old and useful. Oracle's Configurator documentation describes model structure, configuration rules and a user interface as the fundamental elements of a configurator, then places the session inside a host application and connects a completed configuration to downstream processing.[1] A modern web implementation may use different services and a real-time renderer, but it still has to answer the same questions: what can be selected, what is valid, what the user sees, and what record leaves the experience.
The shortest useful definition
A working configurator keeps one configuration state in sync across product logic, commercial logic, interface and visuals. If a customer selects a wider frame, the system should know the internal value, apply any dependent rules, update the visible geometry, request a valid price when needed, and preserve enough structured data to recreate the choice later.
A 3D viewer can rotate, zoom or annotate a prepared model without defining a new product. A visual customizer may switch finishes while leaving the underlying sellable item unchanged. A configurator goes further: it creates and validates a specific product state. The planned guide to product configurators, product customizers and 3D viewers owns that category comparison in full.
The output is the cleanest test. A screenshot can help a buyer recognize a design, but it cannot tell a cart, quote system or factory which parts and values were selected. A valid configuration record can. That record may point to a standard SKU, a set of line items, a bill of materials, a quote request or an engineering handoff, depending on the product and sales process.
A configurator has seven connected parts
The browser scene is only one part of the system. The architecture below separates the seven responsibilities that need owners and acceptance tests.
The table below maps the seven-part configurator architecture and its ownership boundaries.
| Part | What it owns | Typical input | Required output |
|---|---|---|---|
| Product model | Product families, components, attributes, values, identifiers and revisions | PIM, ERP, catalogue or governed project data | A stable product vocabulary |
| Option graph | Available choices and the relationships between them | Product model plus channel and audience scope | The current selection state and possible next choices |
| Rule layer | Defaults, requirements, dependencies, exclusions, quantities and numeric limits | Rule catalogue and current selections | Valid, incomplete or invalid state with reasons |
| Commercial layer | Price authority, account context, stock, tax, discount and quote policy | Valid configuration plus market and customer context | Displayable commercial response with provenance |
| Interface | Guidance, controls, summaries, errors, save and completion actions | Current state and rule responses | An understandable path through the decision |
| Visual layer | Geometry, materials, dimensions, camera and optional animation or AR handoff | Accepted configuration values and visual bindings | A faithful visual projection of the accepted state |
| Integration and outputs | Cart, quote, CRM, ERP, CAD or production handoff | Versioned configuration record | A destination-specific payload and recoverable identifier |
Oracle's documented model follows a comparable separation: product structure organizes parts, rules constrain relationships, and the UI reflects and operates on the model.[1] Roomle's current project roadmap also separates product analysis, data preparation, journey and integration planning, logic and visual implementation, technical integration, and final QA.[7] Those are platform examples, not a mandatory stack. The reusable point is the boundary between responsibilities.
Product model and option graph
Start with identifiers, not labels. "Blue" is customer copy; finish_cobalt_powdercoat_v3 might be the governed value. The label can change by language or campaign. The identifier needs to survive saving, pricing and fulfilment.
An option graph is more than a list of dropdowns. It represents which choices exist, which depend on earlier choices, which components can repeat, and which values apply only to a market, product revision or user role. A modular shelving product might allow three widths, but a sliding cabinet may require the middle shelf and rule out the narrowest frame. The graph records those relationships before the interface decides whether to present them as steps, filters or direct manipulation.
Keep provenance beside the model. For each value, record the source owner, revision, effective dates where relevant, visual binding, commercial identifier and retirement behavior. Without that data, an old saved design can reopen with today's label while silently pointing to a different part.
Rules turn choices into a valid product
Oracle's rule guide lists defaults, automatic selections, permitted and excluded options, along with logical, numeric, comparison and compatibility rule types.[2] It also distinguishes a violated configuration from an incomplete one that still needs input.[2] That distinction belongs in the user experience.
A useful rule response has three parts: status, reason and recovery. "Invalid" alone leaves the customer guessing. A better response names the affected choice, explains the constraint in product language and offers allowed next actions. Some rules should prevent an impossible selection. Others can accept the selection but add a required component, warn about a consequence or send the case to a quote path.
Do not maintain separate rule copies in the option panel, renderer and price calculator. One accepted evaluation should drive all of them. Duplicated rules drift, and the drift is often invisible until the 3D scene shows one product while the order payload describes another.
Give every configuration a contract
The configuration object is the system's working agreement. It does not need to expose every internal field to the browser, but the project should define what each field means and which service may change it.
The table below maps the versioned configuration contract, its owners and the evidence to retain.
| Contract question | Owner | Acceptance test | Evidence to retain |
|---|---|---|---|
| Which product is this? | Product-data authority | Product family and revision resolve to one active definition | Product and revision IDs |
| What did the user request? | Configuration state | Every selected value uses a recognized attribute and value ID | Ordered selection record |
| Is it complete and valid? | Rule authority | Required inputs are present and no blocking rule is violated | Rule version, result and reasons |
| What should appear in 3D? | Visual binding layer | Each visual value resolves to approved geometry, material or transform behavior | Binding map and visual test views |
| What is the commercial result? | Pricing, inventory or CPQ authority | Response matches the exact configuration and context sent | Request ID, currency, market and timestamp |
| What goes downstream? | Destination adapter | Cart, quote or build payload can be traced back to the accepted state | Configuration ID, payload version and destination response |
This is an original Double Edged configuration-contract framework. It is intentionally neutral about software. A small ecommerce product may resolve to a single variant plus personalization fields. A made-to-order assembly may need quantities, formulas, a parts list and an approval state. Both still benefit from explicit identity, validity, visual, commercial and output contracts.
Version the rule set and product model separately from the customer's configuration ID. When the catalogue changes, the system can then decide whether to reopen the original revision, migrate supported values, or ask the user to review a conflict. Overwriting the saved choices with the newest catalogue makes the record easier to display and harder to trust.
The 3D scene is a projection of accepted state
Khronos defines glTF as an API-neutral runtime asset delivery format. The specification says glTF does not mandate runtime behavior and is not an authoring format, although it can carry scenes, nodes, meshes, materials, cameras and animation.[3] A GLB or glTF asset can therefore carry useful visual content, but it does not define your sellable options, price policy or manufacturing rules by itself.
Bind configuration values to stable scene semantics. A finish value can select an approved material definition. A module value can control visibility or instantiate governed geometry. A dimension can drive a constrained transform or request generated geometry. Avoid treating artist-facing object names as permanent commerce IDs; those names often change during asset cleanup.
Visual acceptance needs named states. Pick a representative set that covers defaults, exclusions, material extremes, repeated modules and the largest supported dimensions. Compare geometry, material assignment, scale cues and camera behavior on the target devices. These are project tests, not proof that every possible combination is correct.
The scene also needs a fallback. A still image, readable summary and normal HTML controls should preserve the essential product decision when WebGL, a model request or direct manipulation is unavailable. The configuration record should survive even if the renderer does not.
The interface explains the rule system
The option panel should show the customer what changed and why. A disabled swatch with no explanation hides product knowledge. A removed option can be even worse because the user cannot tell whether it is unavailable, incompatible or simply missing.
WCAG 2.2 requires keyboard operation for content functionality, visible keyboard focus, text identification of detected input errors, and programmatically determinable status messages; it also requires a non-dragging pointer alternative where dragging is not essential.[4] For a configurator, that means essential choices cannot live only inside a draggable 3D canvas. Use labelled HTML controls, preserve a meaningful focus order, announce price or validity updates without stealing focus, and provide a control-based alternative to moving parts in the scene.
A stable interaction cycle is easier to test:
- Record the requested value without mutating several hidden copies of state.
- Evaluate rules and return accepted changes, derived selections and reasons.
- Update the option controls, summary and visual projection from that accepted result.
- Request commercial data only with the configuration identity and required context.
- Save or hand off only a complete state, unless the destination explicitly accepts an incomplete draft.
The planned interactive product configurator UX guide owns detailed interface patterns. The principle here is narrower: every visible control and status should reflect the same governed state.
Pricing needs its own authority
Some products have a fixed price for each sellable variant. Others calculate from dimensions, components, finish classes or quantities. B2B flows may add account rules, market lists, approvals or manual review. Decide which service is authoritative before drawing a live price in the interface.
Do not bake volatile price, stock or lead-time claims into a 3D asset or a client-only rules file. Send the accepted configuration and required context to the commercial authority, then retain enough response metadata to identify what was priced. If the price cannot be returned, the interface should say what remains possible: save a design, request a quote, retry, or continue without a promise.
The main scope drivers are the number and diversity of product families, rule depth, visual-state complexity, pricing method, integration count, audience and permission model, required outputs, target devices, and post-launch ownership. They shape the work, but they do not produce a responsible project price without discovery.
Outputs decide whether the system can do useful work
A configuration should leave the browser as structured data, even when a snapshot or PDF travels with it. The destination determines the payload.
Oracle CPQ documents BOM mapping rules that turn configuration selections into a BOM instance represented as a hierarchy of commerce transaction lines for a quote.[5] Shopify's current Ajax Cart API provides a simpler commerce example: a request adds variants by ID and quantity, and can carry line-item properties as key-value pairs.[6] These are different implementation contracts. Neither should be inferred from the appearance of the 3D scene.
The table below shows the destination outputs and the authorities that must accept them.
| Destination | Minimum useful payload | Authority to confirm | Failure that must return to the experience |
|---|---|---|---|
| Saved design | Configuration ID, product and rule versions, accepted values and owner | Configurator persistence service | Expired values, revision conflict or access failure |
| Cart | Sellable variant or item IDs, quantities, permitted custom fields and configuration ID | Commerce platform | Rejected item, stock change or invalid property mapping |
| Quote or CPQ | Accepted selections, quantities, price context, account context and attachments | CPQ or sales system | Pricing exception, missing input or approval requirement |
| Production handoff | Governed component IDs, dimensions, units, rule version and release state | ERP, PLM or engineering authority | Unmapped part, tolerance conflict or unsupported revision |
| Share or review | Recoverable link, permission state, readable summary and optional image | Identity and persistence layer | Revoked access, stale revision or incomplete record |
Treat each adapter as a translator with tests. It should accept one versioned configuration contract and return a destination response. If a cart mapping changes, the rule engine and renderer should not need matching edits. If a destination rejects the payload, keep the user's accepted configuration and show a recoverable next step rather than losing the session.
Build one representative slice before scaling
A useful first slice is not the easiest colour switch. Pick a product state that exercises one dependency, one exclusion, one derived choice, one visual geometry change, one material change, the real commercial authority and the intended output. This reveals weak boundaries while the catalogue is still small. It also gives product owners a concrete approval artifact: one state, one rule trace, one commercial response and one destination payload under version control.
The current Roomle roadmap similarly puts product analysis and data preparation before logic and visual implementation, then separates technical integration from final QA.[7] That sequence is evidence of one vendor's delivery method, not a universal schedule or result. It does support a practical rule: discovery should identify product logic and output ownership before a team scales asset production.
For the full implementation sequence, responsibilities and release phases, use How to Build a 3D Product Configurator: Architecture and Phases. This pillar stops at the system definition so that build choices, platform detail and vertical workflows retain their own page ownership.
Use acceptance tests that cross the boundaries
Component tests are necessary, but the expensive defects live between layers. Run a thin set of end-to-end contracts against a named product revision and environment.
The table below lists starter cross-layer acceptance tests for a representative product slice.
| Test | Starter pass condition | What it catches |
|---|---|---|
| Repeatability | Reopening the saved ID recreates the same accepted values and product revision | Lossy saving or silent catalogue substitution |
| Rule recovery | Every blocked representative choice has a reason and at least one allowed recovery path | Hidden or duplicated rule behavior |
| Visual binding | Named accepted states select the intended geometry and materials without changing product identity | Scene-name drift and stale asset bindings |
| Commercial trace | Displayed price or quote state can be traced to the exact configuration and context requested | Client-side price drift and stale responses |
| Output integrity | Destination payload IDs and quantities match the accepted summary | Cart, quote or BOM translation errors |
| Accessible completion | The representative journey works with keyboard controls, visible focus, readable errors and announced status changes | Canvas-only interaction and silent updates |
| Degraded mode | A failed 3D request leaves choices, summary and save or handoff behavior usable where the brief requires it | Renderer failure taking down the whole journey |
These are starter acceptance conditions, not results from a deployed configurator. Add product-specific tolerance checks, security tests, device and network budgets, localization, analytics and operational rollback criteria during discovery. Do not mark a whole product family accepted because one attractive state rendered correctly.
Common architecture mistakes
The most common failure is letting a convenient layer own data it cannot govern. CAD geometry becomes the option catalogue. Renderer node names become order IDs. The interface duplicates exclusions. A browser bundle calculates the final price. A screenshot stands in for a build record. Each shortcut works in a demo and becomes costly when the product changes.
A second failure is treating invalid, incomplete and unavailable as one status. The user needs different recovery for each. An invalid combination may require changing a choice. An incomplete design needs another input. An unavailable item may need a new market, date or fulfilment path. Preserve those meanings in the rule response and interface copy.
Finally, plan ownership after launch. Someone must approve product revisions, rule changes, price connections, 3D derivatives, interface copy and destination mappings. Store tests with the governed data so a new finish or component can be checked against old configurations before release.
Where custom work fits
A configured product with a small, stable variant list may fit an existing commerce platform and prepared 3D viewer. Custom architecture becomes more likely when the product has dimensional or modular rules, several audiences, account-specific pricing, generated geometry, complex outputs, or integrations that must preserve one state across systems.
The custom 3D product configurator service owns direct project and hiring intent. Double Edged's Spellexo case study is relevant as owned evidence of product strategy, UX, 3D production, engineering, testing, launch and operation. It is not evidence of a client's conversion lift, rescue outcome, migration result or a universal configurator architecture.
The definition to carry into discovery is simple: a 3D product configurator is a governed configuration system whose visual layer explains the accepted product state and whose outputs preserve it. If the product model, rules, price, UI, scene and destination can disagree without a detectable failure, the project still has a demo. It does not yet have a dependable configurator.
