AR & VR
3D models for AR and VR
Augmented reality on phones and virtual reality on headsets both demand light, well-scaled models in the right format. Here is what each platform expects.
AR and VR are unforgiving. A model that renders fine in Blender can stutter on a standalone headset or refuse to open in a phone's AR viewer. The fixes are almost always the same three: format, scale and weight.
Formats by platform
| Platform | Format |
|---|---|
| iPhone and iPad (AR Quick Look) | USDZ |
| Android (Scene Viewer) | GLB |
| WebXR in the browser | GLB, through three.js, Babylon.js or model-viewer |
| Unity or Unreal VR apps | FBX or GLB |
For web AR that works on both phone platforms, the common pattern is a GLB plus a matching USDZ. Google's open-source <model-viewer> element handles the switch for you. Every model page in our library uses it.
Scale is real in AR
In AR, one unit is one metre. A chair modelled at 100 units appears 100 metres tall in your living room. Check the dimensions before you export, and apply scale in Blender (Ctrl+A → Scale) so the exported file carries it.
Keep it light
- Triangles. Standalone headsets and phones handle a few hundred thousand triangles per frame across the whole scene, so a single AR product model is usually best kept well under 100,000.
- Textures. 1024 or 2048 px is plenty for most AR objects. The models in our library were re-encoded to 1024 px WebP textures, which roughly halved many file sizes.
- Compression. Draco or meshopt geometry compression shrinks GLB files further for web delivery.
Where generated models help
Retail AR, educational AR and VR environments all need many objects, and most of them don't need to be perfect. Image to 3D turns product photos into AR-ready previews, and text to 3D fills a VR room with set dressing. For VR especially, light low-poly models keep the frame rate high, and that is what prevents motion sickness.
Written with AI assistance and reviewed by the Renderlyst team. Spot something out of date? Email alishbakhalid766@gmail.com.
