Viscore knowledge centre

How to prepare CAD and 3D files for a web configurator

A model created for manufacturing or offline visualisation is not always ready for the web. Part structure, scale, materials and asset weight need to be assessed together with the product choices the configurator will support.

Chair model transitioning from a technical wireframe to a realistic product

Review the source file and target use

STEP, IGES, SolidWorks and similar CAD files preserve manufacturing detail but may contain internal parts and dense surfaces that the web does not need. FBX, OBJ or glTF files may carry visual materials more directly but can lack a usable product hierarchy.

Review units, axes, part names, repeated components and the parts customers will change—not just the extension.

  • Real dimensions and units
  • Variable and fixed parts
  • Components that move together
  • Material regions and colour variants
  • Modules that can be reused

Simplify geometry around product behaviour

Threads, internal faces and production details that customers never see may not belong in the web asset. Silhouette, joins and close-up details such as stitching can still be essential to perception.

Use the product, target device and camera distance to set detail—not one universal polygon target. Shared geometry is especially valuable in modular products with repeated parts.

Match the part hierarchy to configurable choices

The model tree does not need to copy the manufacturing assembly exactly, but every customer-changeable part must be addressed reliably. Random object names and merged geometry make colour or module changes fragile.

If several products reuse the same geometry, manage it as a shared asset instead of recreating it. Decide whether left-right, open-closed or short-long variants are geometry, transform or material changes.

  • Stable and readable part names
  • Mapping between option codes and model parts
  • Shared sources for repeated modules
  • Pivot and axis checks for moving parts
  • Cleanup of dependent assets when a variant is retired

Prepare materials and textures consistently

A colour value does not describe a physical material on its own. Roughness, metallic behaviour, normal detail, transparency and texture scale work together.

Choose texture resolution for its actual on-screen coverage. Using the largest texture everywhere increases download and memory cost without guaranteeing visible quality.

  • Compare PBR parameters in the same lighting
  • Match texture repeats to real scale
  • Do not approve colour from screenshots alone
  • Check memory and sharpness on mobile devices

Set a performance budget for target devices

File size alone does not explain runtime performance. Geometry decoding, texture memory, draw calls, shadow quality and the number of visible parts need to be assessed together.

Loading only the model and materials required for the first view gives slower connections a safer start. Later options can be fetched on demand, while common variants may be prepared in advance.

Performance layers to review
LayerCheck
TransferModel and texture download size
MemoryDecoded textures and visible geometry
InteractionOption changes and camera responsiveness
Visual qualityEdges, materials and shadow consistency
DeviceReal mobile and desktop tests

Pre-delivery validation checklist

Test the asset through real configuration scenarios, not only in a model viewer. Part replacement, animation, material changes and camera movement should not introduce gaps, overlap or visible jumps.

  • Do dimensions match product information?
  • Are selectable parts named consistently?
  • Do material regions change cleanly?
  • Are load and option changes acceptable on target devices?
  • Are asset usage rights confirmed?

Sources and further reading

Define the right starting point for your product.

Tell us about your product structure, existing files and sales journey. We’ll explore an initial scope together.