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.

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.
| Layer | Check |
|---|---|
| Transfer | Model and texture download size |
| Memory | Decoded textures and visible geometry |
| Interaction | Option changes and camera responsiveness |
| Visual quality | Edges, materials and shadow consistency |
| Device | Real 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
- Khronos Group — glTF
Open format information for web and real-time 3D delivery.
- Khronos Group — KTX
GPU texture delivery and the KTX 2.0 compression approach.


