Preparing models for AR

Real-world scale, two ecosystems, and lighting you do not control.

Augmented reality places a model in the user's environment. That imposes requirements a screen-based renderer does not.

Scale is not optional

The model appears at real size next to real objects. A chair that is ten percent too large is immediately, viscerally wrong in a way it never is on a screen. Model to true dimensions and verify against a known reference.

Two delivery paths

  • iOS uses USDZ through AR Quick Look — a single file, no app required.
  • Android uses GLB through Scene Viewer.

So a product intended for both ships both, generated from the same source. The conversion is routine; the discipline is remembering that two files must stay in sync.

Lighting you cannot control

The renderer estimates the real environment's lighting and applies it. Your material has to look right under unknown conditions — which makes physically correct PBR values more important here than anywhere else. A material tuned to look good under one studio setup will look wrong in a kitchen.

Grounding

A model needs to sit on a surface convincingly. That means the origin at the base rather than the centre, the model level, and often a contact shadow. Without them, objects look pasted rather than placed.

Budgets

AR runs on phones, doing camera capture, tracking and rendering simultaneously, usually while the device heats up. Budgets are tighter than mobile games — modest polygon counts and compressed textures, with the total download small enough to load in seconds.

Generated assets for AR

The two things to get right are scale and the base pivot, neither of which a generator provides — reconstruction has no unit system and centres the pivot on the bounding box. Both are quick fixes and both are the difference between a model that works in AR and one that appears sideways and enormous.