Optimizing 3D Models for AR (LOD, Textures, Polygon Count)

3D artist delivered a chair model—1.2 million polygons, textures 8192×8192 PNG. In Cinema 4D, the render looks great. In AR on an iPhone—18 FPS and overheating in 3 minutes. We see such cases regularly. Our experience shows: the problem is not the app or ARKit—the model was not prepared for a mobile GPU. This situation leads to failed client demos and wasted time. Every second AR visualization project faces this.

Optimizing 3D models for AR requires understanding mobile GPU architecture. We solve it comprehensively: reduce polygon count, compress textures, configure LOD. The result—stable 60 FPS on devices. This allows showing AR content without lag or overheating. Clients save on each project through reduced loading time and storage costs.

Why Polygon Count Matters for AR

On a phone screen, the distance to an AR object is 0.5–3 meters. At this distance, detail above 100–150K polygons is visually indistinguishable from 50K. Our practice rule:

Decimation in Blender: Modifier → Decimate → Collapse with Ratio = 0.05–0.1 for complex models gives the desired result without manual retopology. Quadric Edge Collapse Decimation preserves shape edges better than Unsubdivide.

After decimation—mandatory testing in AR on the target device, not only in editor preview. The object silhouette is more important than internal details.

How to Choose Texture Format

The biggest impact on performance comes from textures, not polygon count. ASTC (Adaptive Scalable Texture Compression) is the right format for mobile AR. It is supported by all ARM Mali and Qualcomm Adreno GPUs since the mid-2010s. ASTC 6×6 gives about 2.37 bpp versus 32 bpp for PNG—13x less GPU memory with minimal quality loss. For more on texture compression, see Wikipedia.

ETC2—a universal fallback for older devices (GLES 3.0+). It has worse compression quality but wider support.

Never use PNG/JPEG in AR scene textures. PNG decodes to full RGBA8888—for a 2048×2048 texture, that's 16 MB GPU memory. ASTC 2048×2048 is about 2 MB.

Generate ASTC via astcenc (command line):

astcenc -cl input.png output.astc 6x6 -medium 

In Xcode Asset Catalog: add the texture, set Compression = Lossy → automatically ASTC on iOS. On Android, compile via Android Studio or in CI using texturetool.

Texture size rule: texture size should be proportional to the visible screen area of the object. For an object taking up 20% of the screen, a 512×512 texture gives results indistinguishable from 2048×2048. Mipmaps are mandatory: SceneKit and ARCore automatically use the mipmap level corresponding to the display size.

Implementing LOD for AR

Unlike game engines, ARKit SceneKit does not have a built-in LOD manager. We implement it via SCNLevelOfDetail. Example code:

let highPolyGeometry = loadGeometry("chair_high.usdz") // 50K polygons let medPolyGeometry = loadGeometry("chair_med.usdz") // 15K polygons let lowPolyGeometry = loadGeometry("chair_low.usdz") // 5K polygons let lod1 = SCNLevelOfDetail(geometry: medPolyGeometry, screenSpaceRadius: 100) let lod2 = SCNLevelOfDetail(geometry: lowPolyGeometry, screenSpaceRadius: 30) node.geometry?.levelsOfDetail = [lod1, lod2] 

screenSpaceRadius is the radius of the bounding sphere in screen pixels. A value of 100 means the model occupies about 200×200 pixels. Numbers are tuned empirically for each object. See SCNLevelOfDetail for details.

On Android ARCore with Filament, LOD is implemented via MaterialInstance swap or RenderableManager.Builder.boundingBox() for culling.

USDZ / glTF: The Right Format for AR

USDZ (iOS, macOS)—a container based on Pixar's OpenUSD. Contains geometry, materials, animations, physics. Supports AR Quick Look without code. Reality Converter (macOS app from Apple) converts from FBX/OBJ/glTF to USDZ with simultaneous texture optimization.

glTF 2.0 (Android/Cross-platform)—open standard, natively supported by Filament and Sceneform. glb is the binary variant, preferred for AR (single file). Optimize via gltf-pipeline:

gltf-pipeline -i model.gltf -o model_opt.glb \ --draco.compressMeshes --draco.quantizePositionBits 14 

Draco compression (Google) reduces geometry size by 5–10x through lossy compression. Quality is controlled via quantizeBits—14 bits is sufficient for most AR objects.

Format choice depends on platform: USDZ—native AR Quick Look support, small size, but only iOS. glTF + Draco—cross-platform, strong compression, but requires a loader. For cross-platform projects, we often choose glTF; for iOS ecosystems, USDZ.

How We Do It: Stack and Process

We use Blender for decimation, astcenc for compression, Xcode and Android Studio for testing. The process is divided into stages:

1. Analyze source models: identify excessive polygons, texture sizes, missing LOD.
2. Decimate to target polygon count (average 10x reduction).
3. Compress textures to ASTC/ETC2 with mipmap generation.
4. Create LOD levels (up to 3 levels).
5. Export to USDZ or glTF with Draco compression.
6. Test on real devices (iPhone and Android).

With over 5 years of AR development experience and more than 200 successful projects, we confirm this approach guarantees results. Example from practice: a major furniture brand wanted to display a catalog in AR. Original models weighed 200 MB each. We reduced polygons to 30K, compressed textures to ASTC, added LOD. Final models were 15 MB, AR scene ran at 60 FPS even on iPhone X. Saving on storage and transfer was substantial for a catalog of 50 models.

Source: project report for a furniture brand.

Checklist for Self-Verification

• Polygon count < 100K for medium objects.
• Textures compressed to ASTC or ETC2.
• Texture size ≤ 1024×1024 for non-primary objects.
• LOD configured (minimum 2 levels).
• Format—USDZ (iOS) or glTF (Android).

What's Included in Our Work

Our service includes:

• Analysis of source models and optimization report.
• Decimation, texture compression, LOD level creation.
• Export to USDZ/glTF with Draco compression.
• Testing on target devices (iOS/Android).
• Pipeline documentation and recommendations for ongoing use.
• Training your team to work with optimized models.

Timeline and Pricing

Optimizing a single model takes 0.5 to 1 day. For a catalog of 20–50 models, it takes 1–2 weeks including automated pipeline setup. Pricing is tailored to complexity and volume. Contact us for a project assessment—we'll prepare a commercial proposal. Request a consultation, and we'll analyze your models for free.