®"AR-ready" is the least reliable phrase in a 3D quote. It sometimes means a validated, compressed, correctly scaled asset that loads on a mid-range phone, and it sometimes means an export button was pressed. These are the questions that separate the two.
Formats, and why you need two
The web and Android side runs on glTF, usually as the binary GLB. Apple’s Quick Look wants USDZ. There is no single file that serves both, so an AR deliverable is a pair, generated from one source and checked separately — conversions drift, particularly around transparency and emissive materials.
If a supplier hands you one file and calls it AR-ready, ask which platform it is for. The answer tells you how much of the pipeline they have actually run.
Budgets are a product decision, not a technical one
There is no universal triangle count. What exists is a load-time and thermal budget on the worst device you intend to support, and geometry is only part of it — textures are usually the bigger download. A useful discipline is to fix the total transfer size you will accept, then spend it deliberately across mesh and maps.
- Mesh compression (Draco or meshopt) for geometry, chosen for what your runtime supports
- GPU texture compression (KTX2 / Basis) rather than shipping raw PNGs the GPU has to decode and store
- Texture resolution set per material, not globally — the sole of a shoe rarely needs what the upper does
- Baked ambient occlusion and detail where a real-time light will never sell it anyway
Scale, orientation and pivot
The most common AR failure is not visual quality; it is a sofa that arrives in the room the size of a shoebox. Assets must be authored at real-world scale in the units the target runtime expects, oriented so the natural front faces the viewer, with the pivot at the point the object should sit on the floor — normally the base, not the centre of mass.
Get this wrong and every downstream consumer patches it with a transform, which works until someone reuses the asset somewhere that does not know about the patch.
Materials behave differently in real time
An offline renderer will happily give you dispersive glass, subsurface scattering and multi-layer coats. A real-time PBR material is a much shorter list. Anything relying on ray-traced refraction needs a plan: approximate it, bake it, or accept that the AR version reads differently from the hero render and design for that gap rather than being surprised by it.
Validate on the target, not the workstation
- Open the GLB and the USDZ on real devices, including the oldest phone in your support matrix
- Check scale against a known object in the room, not on screen
- Watch load time on a throttled connection, not office wifi
- Run the file through a glTF validator and fix the warnings, not just the errors
- Confirm transparency, double-sided faces and emissive materials survived conversion
None of this is exotic, but it is work, and it is the difference between an asset that ships and an asset that gets quietly dropped from the launch because "AR didn’t look right".