Low Poly Models for AR

Real-world scale is the one thing a game export almost never has to think about, and AR cares about nothing else more. ARKit and ARCore both trust the units embedded directly in the file to size the model against a room tracked through the camera via SLAM, so a model authored as a generic "1 unit tall" will either appear as a tiny tabletop miniature or tower over the furniture depending on the export scale factor. glTF and GLB specify meters as their one native unit unambiguously, so a model meant to sit on a real desk should measure roughly 0.1 to 0.3 real meters, and a full-size prop like a chair needs to be modeled and exported at true human scale rather than a stylized arbitrary size. Get this wrong and no amount of pretty shading saves the demo; the model floats through the floor or dwarfs the room the instant it is placed.

Two platforms genuinely need two different files. iOS AR Quick Look, reachable through Safari, Files and Messages, requires USDZ specifically and will not open a GLB or FBX directly. Android's Scene Viewer and Google's model-viewer web component, which layers both platforms under one HTML tag, read GLB directly and hand off to ARCore. A properly cross-platform AR page therefore usually ships a GLB and a USDZ side by side, generated from the same source mesh, since no common tool losslessly transcodes one into the other automatically; Apple's Reality Converter or Blender's USD exporter are the usual bridges, though animation and material fidelity can shift slightly in the process.

USDZ inside AR Quick Look is deliberately limited: it reliably supports only a single looping animation clip or a static pose, with no runtime scripting and no interaction beyond the built-in tap-to-place, pinch-to-scale and rotate gestures Apple provides. Skinned mesh animation is technically permitted in the USDZ spec, but support is inconsistent across iOS versions, so the safest AR export is a static model or one simple looping clip rather than a multi-clip game rig, which will not behave predictably once it reaches a phone.

Polycount and texture budget for AR sit tighter than a typical mobile game budget, because the phone is running SLAM tracking, camera passthrough compositing and model rendering simultaneously, on top of a cold-load requirement that often happens over a cellular connection rather than Wi-Fi. A tabletop AR figure should stay under roughly 20,000 triangles with a single 1024px atlas; anything heavier noticeably delays the tap-to-place moment, which is the exact instant a visitor decides whether the demo feels premium or broken. Keep the whole GLB or USDZ file itself down to a few megabytes so that first load stays fast.

Lighting behaves differently in AR than in an engine you fully control. Because your model gets composited into a live camera feed under unpredictable real-world lighting, ARKit and ARCore both apply automatic lighting estimation to relight the model to roughly match the room, so hard directional shadows baked into your textures will look visibly wrong once the device's real-time relighting is layered on top. Instead, add a simple flat shadow-catcher plane beneath the model, a transparent disc carrying a soft baked blob shadow, which is the standard trick that makes an AR object feel grounded on a real floor or tabletop rather than floating just above it.

Every model you generate here, exported as GLB or bridged to USDZ, is yours to use commercially with no attribution required, so a product-preview AR page, a furniture-placement demo for a shopping site, or a novelty AR figurine app can all ship the same generated asset without any licensing question standing between the model and the phone screen.