AR Rollouts Stall on the 3D Asset Pipeline, Not on the AR

Most AR projects that fail do not fail in the AR. The tracking works, the model renders, the pilot demos beautifully on twelve products. Then someone asks what happens to the other two thousand, and the project quietly becomes a permanent pilot. The blocker was never the experience layer. It was that nobody costed the content, and content in this context means a 3D model per product, kept current, forever.

This is worth stating before any vendor conversation, because the experience is the part that gets demonstrated and the pipeline is the part that gets invoiced.

The viewer is built once, the assets never stop

An AR viewer is a fixed cost. You specify it, build it, test it across devices, and it then serves any number of products without further work. It has maintenance, but the maintenance is occasional and it does not scale with your catalogue.

Assets are the opposite. Every product needs one. Every new product needs one on the day it launches, or the AR button disappears from the newest and most promoted pages on the site, which is the worst possible coverage pattern. Every colourway, finish and material variant either needs its own asset or needs the asset built so that materials can be swapped at runtime, and that decision has to be made before the first model is produced rather than discovered at product number four hundred.

Seasonal ranges make this sharper. A catalogue that turns over substantially each season is not a one-off production of two thousand models, it is a standing production line, and the cost profile of the project is an operating cost rather than a capital one. The breakdown of what AR and VR marketing costs treats this properly, and the headline point is that asset volume, not experience complexity, is the number that moves the total.

Where the models come from decides everything

There are four realistic sources, and which ones apply to your catalogue determines whether coverage is achievable at all.

Source	Works for	Real bottleneck	Ongoing viability
Existing CAD from design or manufacturing	Furniture, appliances, machinery, anything engineered	CAD is built for production, not rendering, and needs heavy optimisation and re-materialling	Good, if you can get the files from suppliers reliably
Photogrammetry or scanning	Physical products with complex form or texture	Needs the physical item, a rig, and clean-up time per item	Workable in-house, weak if items arrive late
Manual modelling from photography and specs	Products with no CAD and no sample available	Slowest and most expensive per item	Fine for a pilot, painful at catalogue scale
Supplier-provided assets	Multi-brand retailers and marketplaces	Wildly inconsistent quality, scale and format	Best long-term option, requires a written spec

The fourth row is where large catalogues eventually land, and it is a commercial exercise rather than a technical one. If you sell other people's products, the sustainable answer is a supplier asset specification attached to onboarding, with format, scale, polygon budget, texture resolution and naming defined, and a validation step that rejects anything non-compliant automatically. Retailers who did this early have coverage. Retailers who did not are still modelling in-house and still behind.

The question that exposes an unplanned pipeline

Ask a supplier or an internal team one thing: who produces the asset for product number two thousand and one, and how long after the product goes live does it appear.

An answer that involves sending files back to an agency each time is not a pipeline, it is a retainer. It also means the AR button will lag your merchandising by weeks, which is exactly the wrong direction, because new products are where the visual uncertainty is highest and the traffic is most concentrated.

A real pipeline has an owner inside the business, a defined format, an automated conversion and compression step, storage that the product page can address by product identifier, and a validation gate that catches an asset with the wrong scale before a customer sees a sofa the size of a phone. Most of that is ordinary content operations work rather than 3D expertise, which is why it tends to sit unassigned between the ecommerce team and the creative agency.

The technical shape of that pipeline is covered in the guide to producing and managing 3D assets for AR at catalogue scale, including the format and budget decisions that are cheap to make once and expensive to reverse.

Build the pipeline in this order

1. Count the real asset requirement first: products in scope, plus variants that cannot be handled by runtime material swaps, plus the number of new products added in a typical quarter. That third number is the operating cost and it is the one usually missing.
2. Classify the catalogue by source. Which products have CAD, which have a supplier who could provide assets, which need scanning, and which need modelling from scratch. Coverage percentage by source tells you immediately whether the rollout is feasible.
3. Write the asset specification before commissioning any models. Formats for web and for iOS delivery, polygon and texture budgets tied to a target device, real-world scale in defined units, material conventions, and the naming and identifier scheme that links an asset to a product record.
4. Automate conversion and compression as a build step rather than a manual export. Assets produced by hand at the end of a modelling process drift from the spec within weeks.
5. Put validation in front of publication: scale sanity, file size, missing textures, identifier match. Automated rejection is what keeps quality stable once volume rises.
6. Only then scale production, and start with the products where the visual objection is strongest rather than the ones that model most easily.

Step three deserves one extra note, because it is usually settled at the wrong end of the project. The polygon and texture budget is not an aesthetic choice, it is a decision about which phone your customers hold. Assets authored without a stated device target look excellent in review on a workstation and stutter on a three-year-old mid-range Android, and by the time anyone notices you have hundreds of them. Set the target device first, derive the budget from it, and hold suppliers and modellers to it. Delivery constrains this too, since a browser-delivered experience has a payload limit that an installed app does not, and the comparison of WebAR against app-based delivery is worth reading before the budget is fixed rather than after.

What to do next

Do the count. Products in scope, variants that need separate assets, new products per quarter, and the share of your catalogue with usable CAD or a supplier who could be asked for files. That is a spreadsheet exercise, it takes a day, and it will tell you more about whether an AR rollout is viable than any demo will.

If the count is manageable, the specification comes next and it should be written before anyone models anything. If the count is not manageable, the right move is a narrow rollout on the products with the strongest visual objection, with the pipeline built properly for that subset and extended later. Either route is a content operations project with an AR layer on top, which is how the AR and VR immersive marketing work is best scoped, and it is worth checking the patterns in the guide to immersive product demos that stay live on commerce pages before committing to a format.