How to Build a 3D Model Catalogue at Scale: Cost and Ops

The demo went well. One sofa, placed in a real living room, at the right size, loading in a couple of seconds. Then the retailer asks the question that decides the project: "We have four thousand products. When can they all be in the app?" That is the moment an AR build stops being about code and becomes about a 3D model catalogue. One good model is a design task. Four thousand is a factory.

Almost every agency article stops at "use Blender" and treats the model as done. This post is the part they skip: producing and maintaining hundreds or thousands of models without the whole thing falling apart. If you have not made a single model yet, read the companion guide on making 3D models for an AR furniture app first, then come back here for the scale problem.

What is a 3D model catalogue, and why is scale the hard part?

A 3D model catalogue is the managed library of optimised 3D files behind an AR app, one per product and often one per colour or finish. Scale is the hard part because the difficulty is not any single model, it is keeping hundreds or thousands of them correct, named, versioned and current, while the real product range keeps changing underneath you.

Making one model, you can hold every detail in your head. At a few hundred models, that stops working. Files drift out of spec, two artists name the same product differently, a colour variant goes missing, and an old version ships to a customer months after the product changed. The craft moves from modelling to 3D model production ops: the systems that let a team turn out matched models at a steady rate and never lose track of which file is the real one. Here is the line every product travels.

Notice that only two of the six stages are about making the model look right. The other four exist purely because there are so many. Intake, cataloguing, QA and upkeep are the cost of scale, and they are exactly what a single model guide never has to mention.

In-house rig vs outsourced: how to split the work

Split the work by ownership and repeat rate. An in-house photogrammetry rig pays off for product lines you own and re-shoot often, because the setup cost is high but the cost per model then drops. An outsourced modelling studio suits backlog, one off spikes and the long tail you will not capture twice. Most catalogues use both at once.

Photogrammetry is building a 3D model from many photographs of a real object, and a rig is the fixed setup that makes it repeatable: a turntable, controlled lights and a camera at set positions, so every capture starts from the same conditions. Build one and a staff member can push products through it all day. Apple's Object Capture and similar tools then turn each photo set into a model on a workstation, though every raw scan still needs the cleanup covered in the single model guide.

The trap with outsourcing is spec drift. Two studios, or two artists at one studio, will make different choices about polygon budget, texture size, origin point and units unless you tell them exactly what you want. So the first deliverable is not a model, it is a written spec: the polygon range, the texture resolution, the units, the origin, the two export formats and the file size target. Send it to every vendor and check the first sample against it before the batch runs. The wider build of an AR furniture app depends on that spec being fixed early, because it is the contract that keeps in-house and outsourced models looking like one catalogue.

Naming and versioning: the boring system that saves the catalogue

Give every model a stable identifier tied to the SKU, not to a person, a date or a project folder. Keep colours and finishes as variants under that identifier, and version every change with a simple rising number. Write the rule down before the first batch. This is dull, and it is the single thing that most often decides whether a catalogue survives its second year.

A workable scheme is short. The SKU is the key, for example sofa-arden-3seat. A finish becomes a variant, so sofa-arden-3seat--oatmeal. A change makes a new version, v2, and the old file stays until the new one passes QA. Names carry no artist initials and no "final" or "final2", because those are how duplicates breed. When the model file name matches the SKU in your product system exactly, a machine can line the two up and tell you what is missing, what is out of date and what no longer has a product behind it.

Versioning matters as much as naming because products change and you cannot afford to overwrite in place. The scene formats built for large libraries assume this: Universal Scene Description, the open standard from the film world, is described by OpenUSD as a platform for collaboratively constructing 3D scenes at large production scale, with composition and layering so many people can work on the same assets without standing on each other. You do not need a film pipeline, but you do need its habit: additive versions, one source of truth, never a silent overwrite.

The QA gate at scale: automate what one model did by hand

At scale, QA splits in two. Automated tools check the machine readable rules on every single file, and a human reviews a sample from each batch for the things only an eye can judge. A single model can be checked by hand. A catalogue cannot, so the gate has to be part software, part person, run the same way on every model before it ships.

The automated pass enforces the rules that do not need judgement: real world scale in metres, the origin at the base so the item sits on the floor, both a GLB and a USDZ present, valid material paths, and a compressed file within the size budget. Open source tooling makes this programmable. The glTF Transform SDK and command line can read, inspect and rewrite glTF files in batches, applying Draco geometry compression and KTX2 texture compression and reporting on each asset, which turns "check every model" into a script you run over a folder rather than a person opening files one by one.

1. Automated checks first. Scale, origin, file size, both formats present, materials resolve. Fail the file, do not let it into the DAM.
2. Human review of a sample. Pull a few from every batch and look: does the fabric read right, does the wood look like wood, do the two exports match.
3. Track the pass rate. If one vendor or one product type keeps failing, fix the spec or the source, not the individual files.

Scale and origin are the checks that matter most, because a model at the wrong size or floating above the floor looks broken in a customer's home. Getting those right is a subject on its own, worked through in the guide to accurate AR measurements.

A model DAM: where the catalogue actually lives

A model DAM, or digital asset management system, is the single store the whole catalogue lives in. It holds each model, its GLB and USDZ exports, its textures, its metadata and its version history in one place that both the app and the team read from. Without one, models scatter across laptops, shared drives and email, and nobody can say for certain which file is current.

The DAM is where naming and versioning turn into something useful. Each entry carries the SKU, the variant, the version, the formats present, the file sizes and the QA status. That metadata is what lets the app request "the current oatmeal Arden three seater, the format this device can open" and get the right file every time. It is also what lets you answer, in seconds, how many SKUs still have no model, which is the question that actually tracks the project. Because Android reads GLB and Apple reads USDZ, the store keeps both against every model, a split explained in the post on what USDZ and glTF are. Serving happens from a CDN so a model loads fast on mobile data wherever the customer is.

Maintaining models when products change

Maintenance is the cost that surprises people. A catalogue is never finished, because the real range never stops moving. New products need new models, a changed colour or fabric needs a re-export, a redesigned frame needs a new version, and a discontinued line needs its model retired so the app stops offering something you no longer sell. This upkeep runs for the entire life of the app.

The way to keep it sane is to connect the catalogue to your product data. When a SKU is added, changed or discontinued in your own system, that should raise a task against the model: create, update or retire. Handled this way, the catalogue stays in step with the shop floor and a customer never places a sofa that has quietly gone out of production. Handled by memory, it drifts within a season, and every drift is a model that misrepresents a real product to a real buyer. This standing effort is a large slice of why an AR furniture app costs what it does, and it belongs in the budget from day one, not as a surprise in year two.

Cost: why the catalogue is most of the budget, and how to phase it

The 3D catalogue is usually the largest cost in an AR furniture app, often 40 to 50 percent of the total, and sometimes more than the app itself. There is no single price, because the work is driven by volume and change, not by a flat per model rate. The table below is the honest cost picture: each task and the driver that actually moves its cost.

Read that table as a set of levers. Every one of them scales with the number of SKUs, which is why a fifty item pilot and a five thousand item range are different businesses, not the same project at different sizes. This is also the reason a large retailer's catalogue is a real advantage: a range of tens of thousands of finished, checked, current models is a stock of work a smaller rival cannot copy in a quarter.

The way to make the number bearable is to phase it. Do not model everything before launch. Start with your best sellers, the products that carry most of your sales, so the app is genuinely useful while the catalogue is still small. Add the long tail in later batches, and for the items that will never earn a model, license a ready made one or keep a good photograph. appico builds the app on fixed, transparent scope: a mobile application starts from $12,000, and a larger build with a deep catalogue and custom AR can run up towards $150,000, with upkeep on a separate monthly plan. The catalogue itself is quoted on the drivers above, not as one lump, so you can size it against your real SKU list with the published pricing as a starting point and have a specialist AR app development team cost the models against your actual range. The same asset economics show up in fashion, where each garment is a 3D model too, set out in the guide to the cost and time to develop a virtual try on app like Zara.

When building a full catalogue is not worth it

A full catalogue is not worth it when your range is small, when most of your products would never earn their model, or when you have not proven that AR sells for your category yet. If you sell forty products, a small hand made set is cheap and quick, and the whole production line described here is overkill. The ops only pay off at scale.

There are also products that AR does not help. A flat, simple item that a photograph already sells does not need a 3D model, and forcing one on every SKU is how a catalogue budget doubles for no return. The honest move before committing to thousands of models is a pilot: build models for a small, high traffic set, ship it, and measure whether AR changes the numbers for your customers before you scale the factory. If you are still shaping the idea, how to turn an idea into an app covers scoping before you spend, and the full build of an app like IKEA Place shows where the catalogue sits in the whole project.

A good app development partner should tell you plainly which products deserve a model, which can be licensed, and which are better left as photographs. Assuming every SKU needs AR is the most expensive mistake in this space, and the one no incentive on the vendor side pushes against.

Our take

We have watched more AR furniture projects stall on the catalogue than on the app. The code is the predictable half. The models are the half that runs long, because a catalogue is an operation, not a deliverable. So scope it that way from the start: fix one spec, decide your in-house and outsourced split, agree names and versions before the first batch, automate the QA gate, put everything in a DAM, and connect the whole thing to your product data so upkeep is a task and not a fire.

Phase by best sellers, prove the value on a small set, then scale the factory. Do that and the catalogue becomes the asset that keeps competitors out rather than the cost that sinks the project. You own every model and every line of code from day one, so the library you build stays yours to grow.

Frequently asked questions