How to Make 3D Models for an AR Furniture App: Guide

You have scoped the app and the AR view works on a test phone. Then comes the real question: where do the sofas come from? Not the code, the 3D models. Every chair, table and lamp a customer places in a room has to exist as a 3D file first, built to look right and load fast on an average phone. For a furniture catalogue that can mean hundreds or thousands of them.

This is the part almost every agency article skips. They say "use Blender" and move on. The model pipeline is where the real cost and timeline of an AR furniture app live, often 40 to 50 percent of the whole budget. Here is how it actually works, from capture to a catalogue you can keep alive.

What are 3D models for AR, and why are they the hard part?

A 3D model for AR is a digital version of a real product, a mesh of polygons wrapped in textures, that a phone can render and place in a room at true size. It is the hard part because the same file must look convincing, sit at correct scale, and load in seconds on an average phone. Those three goals pull against each other.

A model that looks perfect in Blender can be useless in AR. If it carries too many polygons or a huge texture, it stutters or takes half a minute to load, and the customer closes the app. Strip it down too far and the sofa looks like a cardboard box in the middle of the living room. The whole craft is holding photoreal quality, correct scale and a small file size at the same time. Here is the path every product travels.

The first two steps decide how the model looks. The last three decide whether it works on a phone. Most models built by a general 3D artist who has never shipped AR pass the first two and fail the last three. Scale matters as much as looks: an AR model at the wrong size is worse than no model, which is a whole subject on its own, covered in the companion guide to getting accurate AR measurements.

Photogrammetry vs manual modelling: which should you use?

Use photogrammetry when the product already exists and has organic shape, worn texture or fine detail, like a fabric armchair. Use manual modelling when the product is boxy and hard surfaced, or does not physically exist yet, like a flat pack shelf you only have drawings for. Most furniture catalogues use both, chosen item by item.

Photogrammetry means building a 3D model from many photographs of a real object taken from every angle. Software finds matching points across the photos and reconstructs the shape and colour. Apple ships this idea as Object Capture, and the scans it produces can go into AR Quick Look on iOS. It captures true colour and material cheaply, but a raw scan is far too heavy to ship, so it always needs cleanup.

Manual modelling is building the piece by hand in software such as Blender, which is free, or Maya or 3ds Max. It gives clean geometry from the first click and needs no physical product, only drawings or specifications. It is the right choice for hard surface furniture with flat panels and straight edges, and the slower choice for soft, organic shapes that a scan would capture in minutes.

A depth sensor can help with capture and scale, though you do not always need one. Whether it earns its place depends on your products and volume, which the sibling post on whether you need LiDAR for an AR furniture app works through in detail.

What is a polygon budget, and why does mobile AR need low poly?

A polygon budget is the maximum number of polygons you allow a model to use, set so a phone can render it smoothly. Mobile AR needs low poly because the phone renders the model, the live camera feed and the motion tracking all at once, in real time. Too many polygons drop the frame rate, heat the device and drain the battery.

A raw photogrammetry scan can arrive with millions of triangles. A furniture piece in a shipping AR app usually lives in the low tens of thousands. Getting from one to the other is retopology: rebuilding the model with far fewer, better placed polygons that keep the silhouette. The detail you lose is put back with a normal map, a texture that fakes fine bumps and seams on a simple surface so a flat panel still looks carved or quilted. This is the single skill that separates an artist who has shipped AR from one who has not.

PBR textures and texture resolution

PBR stands for physically based rendering. A PBR texture set describes how a surface reacts to light using several image maps: base colour, metallic, roughness and normal. It is what makes a wooden leg read as wood and a steel frame read as metal under the real lighting of the room the customer is standing in. Texture resolution is the pixel size of those maps, and it drives file size fast.

The open standard these models use, glTF, supports a full PBR material set, including base colour, metallic, roughness, normal and emissive maps, according to the Khronos glTF specification. The practical discipline is restraint: a 4K texture looks barely better than a 2K one on a sofa seen at arm's length on a phone, yet it can quadruple the file. Share one texture atlas across parts where you can, and keep the material count low. Texture size, not polygon count, is usually what pushes a model over its size budget.

GLB and USDZ: why you export every model twice

You export every model twice because Android and Apple use different AR viewers that read different files. Android's Scene Viewer reads glTF and its binary form GLB. Apple's AR Quick Look reads only USDZ. One model, two exports, so the same sofa opens in AR on both an iPhone and a Pixel.

glTF is a royalty free format for 3D scenes that became an ISO/IEC international standard in 2022; its core is a JSON file, and GLB is the single binary container built for distribution, per Khronos. Google's Scene Viewer documentation confirms it reads glTF 2.0 and GLB on Android. On the Apple side, USDZ is the format that AR Quick Look uses to display objects in AR across iOS, iPadOS and visionOS, inside apps like Safari and Messages. The two formats are worth understanding in their own right, which is the whole subject of what USDZ and glTF are.

If you deliver AR through the browser instead of a native app, the same two files feed a web component such as model-viewer, which shows a GLB on the page and hands a USDZ to Quick Look on iPhone. That trade, an app versus the web, is set out in WebAR versus a native AR app, and the platform split behind these formats runs deeper in ARKit versus ARCore for AR apps.

Compression: hitting a small file size

Compression shrinks a model so it loads fast on a phone with a weak signal. Two tools do most of the work: Draco compresses the geometry, and KTX2 with Basis Universal compresses the textures. Together they can take a model from tens of megabytes to a target near 5MB, which is the difference between a model that loads and one a customer never waits for.

Draco is Google's open library for compressing 3D meshes and point clouds, built to make 3D downloads smaller without compromising visible quality. For textures, glTF supports KTX 2.0 images with Basis Universal supercompression through the KHR_texture_basisu extension, which cuts both the file size and the memory the GPU uses, again per Khronos. USDZ has its own texture handling on the Apple side, so budget for both formats separately rather than assuming one compressed file serves both. Fast loading is not a nicety here. A slow model on mobile data is the most common reason a working AR feature still fails with real customers.

The model QA gate: scale, origin and materials

A QA gate is a fixed checklist every model must pass before it joins the catalogue. The three checks that matter most are scale, so a two metre sofa is two metres in the room, origin, so the model sits on the floor exactly where the customer taps, and materials, so nothing renders black or wrongly shiny. A model that fails any of these looks broken in someone's home.

1. Scale in real units. The model must be authored in metres so a placed sofa matches its real footprint. Wrong scale is the fastest way to lose a customer's trust.
2. Origin at the base. The pivot point should sit at the bottom centre, so the item lands on the floor plane rather than floating or sinking.
3. Materials and normals. Check that every texture path resolves, no face is inside out, and metal and roughness read correctly under different lighting.
4. Both formats match. Open the GLB and the USDZ side by side. They should look the same. Colour and material often drift between the two exports.
5. File size within budget. Confirm the compressed model meets your target before it ships, not after a customer complains.

Run this gate the same way on every model. A catalogue is only as trustworthy as its worst asset, and one floating, oversized wardrobe undoes the good impression of a hundred correct pieces.

The real cost: building and maintaining a catalogue at scale

The biggest cost in an AR furniture app is not the app, it is the 3D catalogue. Producing and maintaining models for hundreds or thousands of SKUs can take 40 to 50 percent of the total budget. Each model is a small production job, and every product change, new colour or discontinued line means another model to make, re-export or retire.

This is also the part with no shortcut. The app is built once. The catalogue is a standing operation for the life of the product. A large retailer's edge in AR is often the catalogue itself, since a range of tens of thousands of finished, optimised models is a moat a smaller rival cannot copy quickly. That is why cost is driven by the work in the table below, not by a headline number.

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 3D catalogue is quoted on the drivers above, mainly SKU count, capture method and refresh rate, because a fifty item range and a five thousand item range are different businesses. You can size a build with the published pricing as a starting point, and a specialist AR app development team should cost the models against your actual SKU list, not a guess.

The same asset economics show up in fashion, where a garment is a 3D model too. The full breakdown is in the guide to the cost and time to develop a virtual try on app like Zara, and if you are still shaping the idea, how to turn an idea into an app covers scoping before you spend.

When making your own 3D models is not worth it

Building your own models is not worth it when your range is tiny, when you can license ready made models, or when the effort will never earn its keep. If you sell twenty products, a small set of hand made models is cheap and quick. The pipeline only becomes a heavy cost, and a real advantage, at catalogue scale.

A word on existing 3D files. Many manufacturers already hold CAD models from their design process. These can shorten capture, but CAD geometry is built for engineering, not phones. It is dense, often has no clean textures, and still needs retopology and PBR work before it runs in AR. Treat it as raw material, not a finished model.

There are also products where AR itself does not pay. A flat, simple item that a photo already sells well may not justify a model at all. 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 how a catalogue budget doubles for no return.

Our take

The app is the easy half. The 3D catalogue is the half that decides whether an AR furniture app ships on time and looks real in a customer's home. We have seen more of these projects stall on models than on code. So scope the catalogue first: count your SKUs, decide what to scan and what to model, set a polygon budget and a file size target, and treat QA as a gate rather than an afterthought.

If you are scoping an AR furniture app and want the model pipeline costed honestly against your real SKU list, that is exactly the conversation we enjoy. You own every model and every line of code from day one, so the catalogue you build stays yours.

Frequently asked questions