Does a 500-product catalog need 500 separate 3D models?

Start with what changes between the products. A different finish, handle or mounting bracket does not necessarily justify another complete GLB.

By Mitchell Wierenga / Masterwork Studio
29 September 2026 / Architecture guide

Five hundred products and five hundred independent model files are different requirements. You can keep every SKU, product page, price and specification while changing how its 3D representation is assembled.

This guide uses a hypothetical catalog to explain the decision. It is not a report of a commissioned 500-product deployment or a measured speed improvement. The right choice depends on the source models, permitted combinations and how people browse.

Separate the product record from the 3D asset

Imagine industrial enclosures with ten body designs, several handles, two mounting systems and a choice of finishes. A product record could identify a particular body, compatible handle, mounting bracket and material. It would also retain its own commercial information.

1. 01 / PRODUCTSKU ENC-042A product record selects base 04, wide handle, bracket B and a blue finish.
2. 02 / ASSETSShared partsThe viewer requests the selected base and components, reusing available assets.
3. 03 / ASSEMBLYOne product viewAttachment rules place the parts and apply the chosen material settings.

Changing the finish may need only a material update. Changing the handle may need one small component download. Choosing another body requires its base geometry. None of those operations inherently requires downloading a complete duplicate of every unchanged part.

Customers can still open a ready-made product from a normal catalog. A shared asset system does not mean making every visitor build their own configuration. The same assembly logic can support both fixed SKUs and a customer-facing configurator.

When a modular 3D product catalog makes sense

Reuse works best when the physical product is already modular. Parts need a consistent scale, coordinate system and attachment points. The software also needs rules describing which parts fit which bases.

• Finish changes: share geometry and change material parameters or selected texture sets.
• Interchangeable components: load the required handle, wheel, fitting or bracket and place it at a defined connection.
• Repeated assemblies: reuse the same source assets across product families rather than embedding duplicates in every exported file.
• Dimensions: use parameters only when the geometry supports them. Stretching a finished model can distort wall thickness, holes and fittings; some dimensions require another base or generated geometry.

The maintenance benefit can be substantial: a corrected shared handle can feed every relevant configuration. That also creates a responsibility. A change to a shared part must be checked against the products that use it, and asset versions should stay consistent with the product data.

How the models load matters as much as their size

A server holding 500 GLBs does not mean a customer downloads all 500. A conventional catalog can load a single product on demand. Compare the modular approach with that sensible baseline, not with a page that needlessly downloads the entire library.

1. Let the catalog open first. Show product information and thumbnails without starting hundreds of live 3D viewers.
2. Load the selected product. Request its base, required components and appropriate textures when the visitor opens the viewer.
3. Reuse unchanged resources. Keep the selected base available while options change. Request only components or texture sets that are missing.
4. Prefetch selectively. A likely next option may justify a background request after the current view is ready. Preloading all ten bases and every accessory defeats the initial-load saving.
5. Bound memory use. Keep a useful working set rather than every model ever visited. Release resources when no active product needs them, without disposing of assets still shared by another view.

Browser download caching and reuse inside the running viewer are separate. A cached file may still need parsing, decoding or uploading to the GPU if the application rebuilds it. The asset manager should avoid duplicate work as well as duplicate network requests.

For download budgets, start with our measured GLB file-size examples. Then measure the actual viewer. File size alone cannot tell you how quickly the product becomes usable.

Choose the delivery approach that fits the product

A standalone GLB may also be useful for an external viewer or an AR delivery path. A modular web viewer can generate or retrieve that finished variant when needed; the web asset architecture and export format do not have to be identical.

Fewer files do not automatically mean faster rendering

A modular assembly can become slower if it adds many separate materials, draw calls or sequential requests. Its first view may be slower than one well-packed GLB, even when switching between related variants is faster.

Geometry compression, texture formats and runtime rendering solve different problems. Three.js supports Draco and Meshopt geometry decoding and KTX2 textures through its glTF loader. Those tools complement asset reuse; they do not replace a loading plan.

Rendering many copies of the same geometry and materials together is another case. Three.js instancing can reduce draw calls for those repeated objects. It does not automatically combine arbitrary accessories into one draw call, and a catalog showing one product at a time may not need it.

Lighting and materials need to hold up across every valid combination. A shadow baked into one part for a particular accessory can look wrong when that accessory is removed. Test shared parts under the actual viewer lighting, especially where finishes or attachments change.

Test one product family before converting the catalog

Choose a representative family with real variation: a shared base, interchangeable geometry, at least one finish change and an incompatible option. Build both a conventional on-demand model and a modular version using equivalent visual quality.

• First usable view: download, decode and display time from an empty cache.
• Option changes: extra requests, transferred bytes and time until the new configuration is visible.
• Rendering: frame time, draw calls and texture/geometry memory across representative desktop and mobile devices.
• Longer browsing: memory behavior after repeated product and option changes.
• Correctness: fit, scale, materials, invalid-combination handling, SKU mapping and pricing.
• Maintenance: the work needed to correct a shared component and safely update all affected products.

Record devices, browsers, network conditions, asset versions and cold versus warm cache results. Until that comparison exists, a percentage reduction or speed claim is a hypothesis.

What to prepare before commissioning the viewer

Bring a representative set of models, the product/SKU list and a matrix of compatible options. Identify which features change geometry, which change materials, and which need their own base. Include target devices, the existing commerce platform and any AR or downloadable-model requirement.

For an existing example of browser interaction and component explanation, explore the jet engine project breakdown. It is an independent studio demonstration, not a modular product-catalog case study.