What's the best way to optimize 3D models for real-time performance in an AR app?

The best approach is to optimize for the whole AR frame, not just polygon count. Your phone is simultaneously doing camera capture, tracking/SLAM, depth/occlusion, and 3D rendering, so a model that looks fine in a desktop viewer can still hurt AR frame rate.

A practical optimization pipeline

1. Reduce geometry intelligently

• Preserve the silhouette and visually important edges.
• Remove hidden/internal geometry.
• Use normal maps and textures for small surface details rather than modeling every detail.
• Create LODs so distant objects use progressively simpler meshes. Unity recommends roughly halving triangle counts between LOD levels as a useful starting point.
• Don't chase an arbitrary polygon number: what matters most is how much geometry is visible simultaneously. Apple's spatial-computing guidance, for example, recommends keeping visible triangles around 100k when possible.

2. Minimize draw calls

This is often more important than shaving a few thousand triangles. Ten small meshes with ten materials can be considerably more expensive than one larger mesh with one material.

• Combine meshes that share materials.
• Use texture atlases.
• Avoid unnecessary material variations.
• Use GPU instancing when you have many copies of the same object.
• But don't blindly merge everything: keeping objects separate can allow better frustum/occlusion culling.

3. Control textures aggressively

• Use the smallest resolution that looks good at the object's expected screen size.
• Use mipmaps.
• Prefer compressed GPU-friendly formats where your target platform supports them.
• Atlas multiple small textures when practical.
• Avoid carrying several 4K textures on a mobile AR asset unless there's a compelling reason.

For RealityKit/AR Quick Look, Apple recommends generally keeping textures at 1024² or below, with 2048² as an upper limit, and combining smaller textures where possible. Apple Developer 4. Keep materials simple

Expensive shaders can dominate performance even when the mesh is lightweight.

Prefer:

• Simple PBR materials
• Baked lighting where appropriate
• Few texture samples
• Minimal transparency
• Limited real-time lights and shadows

Transparency is particularly expensive because overlapping transparent surfaces cause additional fragment-shader work. Apple Developer 5. Exploit culling

Don't render things the camera can't see.

• Frustum-cull objects outside the camera view.
• Use occlusion culling for objects hidden behind other geometry.
• Break huge environments into chunks so individual pieces can disappear from rendering independently.

This can provide a much bigger win than simply decimating every mesh. Android Developers Apple Developer 6. Optimize animation

For animated characters, reduce:

• Bone/joint count
• Number of skinned meshes
• Animation complexity
• Unnecessary deformation

Skeletal animation adds GPU work, so a beautifully optimized static mesh can still perform poorly if its rig is excessive.

A good asset structure

For a typical mobile AR object, I'd aim for something like:

High-poly source
       ↓
Retopology / decimation
       ↓
Low-poly render mesh
       ↓
Bake high-poly details
  ├── Normal map
  ├── AO
  └── Other baked detail
       ↓
Texture atlas + compressed textures
       ↓
Simple materials
       ↓
LOD0 ── LOD1 ── LOD2 ── billboard/culled

The key idea is move detail from geometry into textures whenever the user won't notice the difference.

Don't optimize by guesswork

Profile on the actual target phones, not just in the Unity/Unreal editor.

Watch at least:

• Frame time / FPS
• CPU render time
• GPU frame time
• Draw calls
• Triangles/vertices
• Texture memory
• Overdraw
• Thermal throttling
• Tracking/AR subsystem performance

If you're GPU-bound, reducing polygons may do almost nothing if your real problem is 4K textures, transparency, shadows, or shader complexity. Conversely, if you're CPU/draw-call-bound, reducing texture resolution won't solve the problem.

For Unity + AR Foundation, I'd generally prioritize:

draw calls → texture/material complexity → visible triangles → shaders/lights/shadows → animation complexity, while using LOD and culling throughout.

For RealityKit/ARKit, Apple's guidance similarly emphasizes mesh count, polygon count, texture memory, transparency, shadows, and material complexity.

If you tell me whether you're using Unity/AR Foundation, Unreal, RealityKit/ARKit, or another engine, I can give you concrete triangle/draw-call/texture budgets and an asset-export checklist for that stack.

draw calls → texture/material complexity → visible triangles → shaders/lights/shadows → animation complexity, while using LOD and culling throughout.

For RealityKit/ARKit, Apple's guidance similarly emphasizes mesh count, polygon count, texture memory, transparency, shadows, and material complexity.

Optimizing 3D models for real-time Augmented Reality (AR) requires balancing visual fidelity with strict mobile hardware limits. Because AR runs on smartphones and headsets with limited thermal and processing headroom, every polygon and texture counts.

• Reduce Polygon Count (Decimation): Target a low-poly baseline (typically under 50,000 to 100,000 triangles total for mobile AR, depending on the target device and number of concurrent objects). Use manual retopology or automated decimation tools while preserving silhouette edges.
• Streamline Draw Calls: Combine meshes and use material instancing to minimize draw calls. High draw call counts choke mobile GPUs and cause frame drops.
• Optimize Textures: Stick to power-of-two texture resolutions (512 × 512 or 1024 × 1024 are ideal for mobile AR). Use compressed texture formats like ASTC, ETC2, or PVRTC depending on the platform.
• Utilize Normal and Ambient Occlusion Bakes: Bake high-poly details, lighting, and shadows into normal, roughness, and occlusion maps. This gives the illusion of high geometry and depth without the heavy vertex processing cost.
• Adopt Efficient File Formats: Use modern, web-ready, and runtime-optimized formats like glTF or GLB, which support efficient compression (like Draco mesh compression) and load rapidly over mobile networks.
• Implement LODs (Level of Detail): Create simpler versions of your 3D assets to swap out when the virtual object is placed further away from the user's camera in the AR space.
• Limit Dynamic Lights and Real-Time Shadows: Rely on baked lighting or simplified, single-directional real-time lighting to maintain a stable 60 FPS (or 30 FPS minimum) tracking experience.

If you'd like, let me know:

• Which engine or platform you are developing for (e.g., Unity with AR Foundation, Unreal Engine, or WebXR/Model Viewer)?
• What kind of objects you are optimizing (e.g., hard-surface mechanical parts, organic characters, or furniture)?

I can provide specific polygon/texture budgets and pipeline steps tailored to your project.

Optimizing 3D models for a real-time AR app is mostly about balancing visual quality, GPU cost, memory usage, and load time. A model that looks great in Blender or Maya can still perform poorly on a phone because the device is simultaneously handling camera input, tracking (SLAM), rendering, and battery/thermal constraints.

1. Reduce geometry complexity (but preserve silhouette)

• Decimate high-poly meshes using tools like Blender’s Decimate modifier or mesh simplification tools.
• Remove: - Hidden/internal geometry
• Tiny details that do not affect the silhouette
• Unseen back faces
• Prioritize the visible outline and major shapes over microscopic surface detail.

Typical targets vary by device and scene, but many mobile AR assets work well when kept in the tens of thousands of triangles rather than hundreds of thousands. Apple’s AR Quick Look guidance, for example, recommends keeping asset geometry below roughly 100,000 polygons and minimizing expensive rendering features.

2. Use Level of Detail (LOD)

Create multiple versions:

• LOD 0: Full detail for close viewing
• LOD 1: Medium detail
• LOD 2: Low detail for distance

Swap models based on camera distance or screen size. A user standing next to an object should see more detail than an object occupying only a few pixels.

Example:

3. Optimize textures

Textures often consume more memory than geometry.

Recommended practices:

• Use compressed GPU formats: - ASTC (common on modern mobile GPUs)
• ETC2 (Android fallback)
• KTX2/Basis compression for some pipelines
• Generate mipmaps.
• Avoid huge textures unless the object is viewed very close.
• Pack multiple maps into atlases where possible.

Good rules of thumb:

• Hero object: 1024–2048 px textures
• Background objects: 256–1024 px textures

Avoid a model with several 8K textures unless there is a strong visual reason.

4. Reduce draw calls

A common mistake is focusing only on polygon count. Rendering overhead also comes from:

• Number of separate meshes
• Number of materials
• Texture swaps
• Shader variants

A 50k-triangle model with 10 materials can perform worse than a larger model with fewer materials. Combine meshes that share materials when it improves batching.

Good practices:

• Merge small meshes
• Limit unique materials
• Use texture atlases
• Remove unused materials and UV channels

5. Bake expensive details

Instead of calculating everything in real time:

Bake:

• Ambient occlusion
• Small shadows
• Surface detail
• Lighting information

Use:

• Normal maps
• Roughness maps
• Metallic maps
• Lightmaps (where appropriate)

This keeps the model visually rich without adding geometry or shader cost.

6. Simplify materials and shaders

Avoid:

• Heavy transparency
• Complex reflections
• Multiple layered shaders
• Expensive real-time shadows

Prefer:

• Simple physically based materials (PBR)
• Baked lighting
• Minimal shader passes

Transparency is particularly expensive because it increases fragment processing.

7. Choose efficient formats

Common AR formats:

• USDZ - Best for Apple AR Quick Look / RealityKit workflows
• glTF / GLB - Good cross-platform choice
• Supports compression methods like Draco

Keep the final asset compact and avoid shipping unnecessary data:

• Extra animations
• Unused bones
• Duplicate meshes
• Multiple UV sets you do not need

8. Profile on real devices

Do not rely only on desktop testing.

Measure:

• FPS/frame time
• GPU usage
• Memory consumption
• App startup time
• Device temperature after several minutes

Test on:

• Older supported phones
• Average user devices
• Your target flagship devices

A model that runs smoothly for 30 seconds but causes thermal throttling after 10 minutes is not optimized.

A practical optimization pipeline

1. Import high-quality source model.
2. Remove hidden geometry.
3. Create clean topology.
4. Generate LOD versions.
5. Bake normal/AO/light details.
6. Reduce material count.
7. Compress textures.
8. Export to USDZ or GLB.
9. Test on actual AR hardware.
10. Iterate based on profiling data.

The biggest performance wins usually come from reducing texture memory, lowering draw calls, and creating LODs rather than simply deleting polygons.

Optimizing 3D models for Augmented Reality (AR) requires balancing visual fidelity with strict hardware limits on mobile devices . Because AR apps run alongside camera feeds, computer vision tracking, and rendering loops, heavy assets will cause lag, thermal throttling, and battery drain.

Here is a practical breakdown of the best strategies to optimize your 3D assets for real-time AR performance:

1. Optimize Geometry and Polygon Count

• Target low poly counts: Aim for a target polygon budget depending on your platform (e.g., under 50,000 triangles per scene for mobile AR, or 10,000 to 20,000 per hero object).
• Use LODs (Level of Detail): Implement lower-detail models that swap in when the virtual object is far from the user’s camera.
• Clean topology: Remove hidden geometry, interior faces that users will never see, and non-manifold edges.

2. Streamline Textures and Materials

• Limit texture resolution: Stick to 2048 × 2048 max for hero assets, but prefer 1024 × 1024 or 512 × 512 for background or smaller objects.
• Pack texture channels: Combine metallic, roughness, and ambient occlusion (AO) into a single 3D-packed texture map (e.g., Red = Metallic, Green = Roughness, Blue = AO).
• Use efficient shaders: Avoid complex procedural shaders or heavy multi-layered materials. Stick to mobile-optimized PBR (Physically Based Rendering) shaders.

3. Consolidate Draw Calls and Textures

• Atlas your textures: Merge multiple smaller textures into a single large texture atlas to reduce material switching.
• Combine meshes: Merge separate sub-meshes that share the same material into a single mesh to minimize draw calls and reduce CPU overhead.

4. Choose the Right Asset Formats

• Use GLTF / GLB: Khronos Group glTF is the industry standard open-source format for real-time transmission and loading, highly optimized for web and mobile AR (like iOS Quick Look and Android Scene Viewer).
• Use USDZ for iOS: Apple natively relies on USDZ for AR Quick Look. Ensure your pipeline exports clean USDZ files if you are targeting iOS devices.

5. Implement Efficient Compression

• Draco compression: Compress geometry data using Draco mesh compression to drastically reduce file download sizes without losing visible detail.
• KTX2 / Basis Universal: Compress your textures using GPU-ready formats like KTX2, which keeps memory footprints low on the device GPU while maintaining quality.

If you'd like, let me know:

• Which engine/framework you are using (Unity, Unreal Engine, WebXR, RealityKit/ARKit)
• The target devices (high-end iOS vs. broad Android range)

I can give you engine-specific settings to dial this in further.

Optimizing 3D assets for augmented reality (AR) is all about balancing visual fidelity with strict mobile hardware limitations—keeping your frame rate locked at 60 FPS while preserving battery life and preventing thermal throttling.

Here is a step-by-step breakdown of the best practices to optimize 3D models for real-time AR performance:

1. Geometry and Polygon Reduction

• Target Polygon Count: Aim for under 50,000 triangles per scene or per hero asset for mobile AR (iOS/Android), and significantly less (< 10,000) if you plan to spawn multiple instances.
• LODs (Level of Detail): Implement LOD meshes to swap out high-detail models for lower-poly versions when the object is further away from the user's camera.
• Clean Topology: Remove hidden or interior geometry (non-manifold geometry, internal faces) that the user will never see.

2. Texture and Material Optimization

• Resolution Caps: Limit texture maps to 2048 × 2048 max for hero assets, and 1024 × 1024 or 512 × 512 for smaller or secondary objects.
• Texture Packing: Pack roughness, metallic, and ambient occlusion (AO) maps into a single ORM/RMA texture (Red = Ambient Occlusion, Green = Roughness, Blue = Metallic) to save precious texture memory channels.
• Atlas Textures: Combine multiple small material objects into a single texture atlas to reduce draw calls and state changes for the GPU.

3. Draw Calls and Shader Complexity

• Minimize Materials: Try to use a single material/shader per object whenever possible. Every unique material adds an extra draw call.
• Mobile-Friendly Shaders: Avoid heavy procedural or node-heavy shaders. Stick to optimized PBR (Physically Based Rendering) shaders or unlit/diffuse shaders for distant or stylized assets.
• Bake Lighting: Bake ambient occlusion and lighting directly into the textures rather than relying on real-time dynamic lighting and shadow calculations.

4. Efficient File Formats

• GLTF / GLB: Use .gltf or binary .glb as your primary delivery format. It is lightweight, streams quickly over networks, and is natively supported by platforms like Google Model Viewer and Apple Quick Look.
• USDZ: For iOS-centric AR experiences, optimize and convert your assets to .usdz to leverage Apple's native RealityKit pipeline.

Would you like to dive deeper into any of these areas? I can help you with:

• Specific polygon and texture budgets for your target engine (Unity, Unreal, or WebXR)
• Recommended baking and decimation workflows in tools like Blender
• Setting up AR Quick Look or WebXR pipelines

The best approach is to optimize for the device’s GPU/CPU and the actual AR camera view, not simply minimize the model’s file size. A good pipeline is:

1. Reduce geometry intelligently

• Remove hidden/interior geometry and tiny details that won't be visible at AR viewing distances.
• Use LOD (Level of Detail): high-poly when close, progressively simpler meshes as the object gets farther away.
• Optimize vertex cache/fetch order and triangle overdraw; these can improve GPU efficiency without visibly changing the model.
• Keep an eye on draw calls/material count, not just polygon count. Merge meshes that share materials when it helps, but don't merge everything blindly because you can lose efficient culling.

As a rough mobile-AR starting point, Apple's AR guidance recommends keeping an individual asset below 100,000 polygons, although your actual budget should be established through device testing.

2. Optimize textures aggressively

Textures can consume considerably more memory than the mesh.

• Prefer 512–1024 px textures where possible.
• Avoid automatically giving every asset a 4K texture.
• Combine small textures into atlases when appropriate.
• Use GPU-friendly compressed texture formats supported by your target platform.
• Generate/use mipmaps so distant objects don't sample unnecessarily large textures; mipmaps reduce GPU memory bandwidth as well as aliasing.
• Minimize expensive transparency/alpha materials. Transparency can substantially increase fragment-shader work.

For perspective, Apple's photogrammetry documentation lists an uncompressed 4096×4096 texture at about 170 MB of runtime texture memory, versus about 10.7 MB for 1024×1024.

3. Keep materials simple

Use a small number of materials and avoid expensive effects unless they're visually important.

A useful priority is:

base color → normal map → roughness/metallic → everything else

Be especially cautious with:

• Multiple transparent layers
• Complex shader graphs
• High-cost reflections
• Real-time shadows
• Screen-space effects
• Excessive normal/detail maps

RealityKit specifically recommends reducing textures, meshes, and materials when GPU utilization is the bottleneck.

4. Optimize the asset format and loading

For cross-platform AR, glTF/GLB is a strong intermediate/delivery format because it was designed with efficient delivery and mobile/resource-constrained devices in mind.

For larger assets:

• Compress geometry where your runtime supports it.
• Compress textures rather than merely zipping the model file.
• Load assets asynchronously.
• Preload assets before the user enters the AR experience.
• Break enormous scenes into smaller independently loadable assets.

For RealityKit specifically, Apple recommends asynchronous loading, sharing mesh resources between entities, and avoiding asset creation/loading while active AR interaction is happening.

5. Build multiple quality tiers

Instead of one "optimized" model, I'd normally ship something like:

Those numbers are starting points, not universal limits. Measure your particular app and device matrix.

6. Profile the complete AR experience

This is the part people often miss: a beautifully optimized model can still produce a bad AR frame rate.

Profile:

• GPU frame time
• CPU frame time
• Draw calls
• Triangle/vertex count
• Texture memory
• App memory
• AR tracking workload
• Number of simultaneously visible objects

For example, RealityKit targets a 60 FPS rendering cadence where each frame has roughly 16.6 ms available, so you need to determine whether you're CPU- or GPU-bound before deciding what to optimize.

A practical pipeline

I'd structure the asset pipeline as:

High-res source → remove hidden geometry → retopology/mesh decimation → LOD generation → UV cleanup → texture resize/compression → material consolidation → mesh optimization/compression → platform-specific export → device profiling

Then test the worst realistic scene, not an isolated model.

The key principle is: optimize what the user can actually see. Put geometry and texture resolution where they affect perceived quality, and aggressively simplify everything else.

Optimizing 3D models for Augmented Reality (AR) requires balancing visual quality with strict performance limits, especially since mobile devices run on battery power and have tight thermal budgets.

Here is a step-by-step framework to optimize your 3D assets for smooth, real-time AR performance:

1. Polygon & Vertex Reduction (Geometry)

• Target low poly counts: Aim for fewer than 50,000 to 100,000 triangles per scene (or under 15,000–30,000 per individual object), depending on whether your target is high-end iOS/Android or older budget devices.
• Remove hidden geometry: Delete internal faces, vertices, and geometry that the user will never see (backface culling optimization).
• Use Level of Detail (LOD): Generate lower-poly variants of your model to swap in when the object is placed further away from the user's camera.

2. Texture & Material Optimization

• Stick to power-of-two sizes: Use 512 × 512, 1024 × 1024, or max 2048 × 2048 textures. Avoid 4K textures on mobile AR as they consume massive VRAM.
• Bake lighting: Pre-compute shadows and ambient occlusion into your textures rather than calculating real-time dynamic lights.
• Pack texture maps: Combine metallic, roughness, and ambient occlusion channels into a single RGB texture (ORM map) to reduce the number of texture lookups the GPU has to perform.
• Limit draw calls: Merge materials and use texture atlases where possible to minimize material switches (draw calls) during rendering.

3. Choose the Right File Formats

• glTF / GLB: This is the industry standard for web and mobile AR (supported natively by Model Viewer and Apple/Android quick look features). It is compact, loads fast, and handles PBR materials seamlessly.
• USDZ: Apple's preferred format for iOS AR Quick Look. Ensure you convert your optimized assets cleanly from GLB to USDZ using tools like RealityConverter.

4. Rigging and Animation Efficiency

• Limit bone counts: Keep skeletons for animated characters simple (under 50–60 joints if possible).
• Bake or decimate animations: Reduce keyframe density and remove unused animation tracks before exporting.

5. Testing and Profiling

• Test your assets directly on target hardware (e.g., mid-range Android or older iPhones) rather than a high-end development PC.
• Use built-in profilers in Unity or Unreal Engine to monitor frame rate drops, draw calls, and memory bandwidth usage.

If you'd like, let me know:

• What engine or framework you are using (Unity, RealityKit, WebXR, etc.)
• What target devices you are optimizing for (high-end iOS vs. broad Android range)

I can give you engine-specific settings or a deeper dive into shader optimization.

For an AR app, the goal isn't simply “use fewer polygons.” You want to minimize the total cost of rendering while preserving the details users actually notice at the model's expected viewing distance.

A good optimization pipeline

1. Profile first

• Test on representative low-, mid-, and high-end phones.
• Determine whether you're CPU-, GPU-, memory-, or draw-call-bound before changing assets. Unity specifically recommends profiling early because optimizing the wrong bottleneck can have little effect.
• For AR, also watch tracking stability and thermal throttling—the AR system itself needs CPU/GPU resources for real-time camera/sensor processing.

2. Reduce geometry intelligently

• Use decimation/retopology to remove polygons that don't affect the silhouette.
• Preserve geometry around the silhouette, joints, and prominent features; simplify flat or rarely visible surfaces aggressively.
• Create LOD (Level of Detail) versions: high detail when close, progressively simpler meshes farther away. LOD is particularly useful on mobile because geometric complexity directly affects GPU workload.
• Don't blindly merge everything into one giant mesh—you want the engine to retain opportunities for culling.

3. Spend polygons where they matter

A practical hierarchy is:

silhouette > large shape changes > normal-map detail > tiny geometric detail

A bolt, seam, bevel, or embossed logo usually shouldn't require actual geometry if a normal/roughness texture can reproduce the appearance. 4. Optimize textures

• Use appropriately sized textures rather than defaulting to 4K/8K.
• Compress textures using formats appropriate for your target devices.
• Use mipmaps for textures viewed at varying distances.
• Pack related textures into atlases where appropriate.
• Watch texture memory and bandwidth; reducing texture size/compression can substantially help mobile GPU performance.

5. Minimize materials and draw calls

This is often more important than shaving another 10% off polygon count. Different materials/shaders can cause additional render-state changes and draw calls.

Try to:

• Reuse materials.
• Combine texture maps into atlases.
• Avoid unnecessary material variants.
• Use GPU instancing for repeated objects.
• Use appropriate batching/SRP Batcher where your engine supports it.

6. Keep shaders cheap

• Prefer simple physically based/mobile shaders.
• Avoid unnecessary transparency.
• Minimize alpha-tested surfaces and overdraw.
• Limit expensive screen-space effects.
• Bake lighting where possible rather than using multiple dynamic lights and real-time shadows. Mobile GPUs are particularly sensitive to fill rate, shader complexity, and overdraw.

7. Strip unnecessary mesh data

If a model doesn't need tangents, extra UV channels, vertex colors, etc., don't ship them. For example, Unity's Optimize Mesh Data option can strip unused vertex attributes, reducing mesh size and runtime memory usage. Unity Documentation 8. Separate render geometry from collision geometry

Don't use your detailed visual mesh as a physics collider. Build simple primitive/low-poly collision meshes instead; complex mesh colliders can be considerably more expensive on mobile.

A useful asset structure

For something like a piece of furniture:

Furniture
├── LOD0  High-quality silhouette
│   ├── ~100k triangles
│   └── 2K textures
├── LOD1  Medium
│   ├── ~30k triangles
│   └── 1K–2K textures
├── LOD2  Low
│   ├── ~8k triangles
│   └── 512–1K textures
└── Collision
    └── Simple primitive/low-poly mesh

Those numbers aren't universal targets—they're starting points. Screen coverage, device class, number of simultaneous models, materials, and shaders matter more than any single triangle budget.

The biggest AR-specific rule

Optimize for what is actually visible through the phone.

If an object occupies only 10% of the screen, users generally won't notice that its hidden back side has 90% fewer polygons. Put your budget into the silhouette and visible details, then use LOD, texture baking, compression, and simple materials to handle everything else.

If you're using Unity + AR Foundation, I can also give you a concrete mobile AR optimization checklist with recommended triangle/texture/material budgets and Unity import settings.

Optimizing 3D models for real-time Augmented Reality (AR) requires balancing visual fidelity with strict hardware constraints (mobile GPUs, battery life, and heating).

Here is the best workflow to optimize your assets:

- **Target Budgets** : Aim for under 50,000 to 100,000 triangles for mobile AR per scene, or 10,000 to 20,000 per individual interactive object depending on the target device.
- **Retopology** : Manually retopologize high-poly meshes or use smart decimation tools in software like Blender or Maya, focusing loops on animating joints and silhouettes.

- **Resolution Caps** : Limit texture sizes to 2048 × 2048 pixels maximum, with 1024 × 1024 or 512 × 512 being ideal for smaller props.
- **Channel Packing** : Pack roughness, metalness, and ambient occlusion into a single **ORM** (Occlusion, Roughness, Metalness) texture to save memory bandwidth and reduce texture sample counts.
- **PBR Shaders** : Use lightweight standard shaders rather than complex multi-layered materials.

- **Texture Atlasing** : Combine multiple smaller textures into a single shared atlas to reduce material switching.
- **Mesh Merging** : Combine static sub-meshes that share the same material into a single mesh object to minimize CPU-to-GPU draw calls.

- **GLTF/GLB** : Use `.glb` (binary glTF) as the standard delivery format for web and native AR (supported natively by **SceneKit**, **ARCore** , and **RealityKit**).
- **Draco Compression** : Apply Draco mesh compression within glTF exporters to drastically shrink file sizes for faster network downloads in web-based AR.

- **LODs** : Generate lower-poly variants (LOD₁, LOD₂) for objects that can scale down when placed further away from the user's camera.
- **Frustum and Occlusion Culling** : Ensure hidden geometry (faces pointing inward or covered by other meshes) is deleted entirely—do not rely solely on engine-level culling.

Would you like me to dive deeper into:

• Specific performance targets for iOS (RealityKit) versus Android (ARCore)?
• A step-by-step optimization tutorial for Blender?

The best approach is to treat an AR model as a real-time asset, not a game/film asset: preserve detail where the user will look, and aggressively simplify everything else.

A practical optimization pipeline

1. Reduce geometry first

• Remove hidden/interior geometry and tiny details that won't be visible at AR viewing distances.
• Use decimation/retopology to reduce triangle and vertex counts.
• Create LODs (levels of detail) so nearby models use the detailed mesh while distant ones switch to simpler meshes.
• As a rough Apple/RealityKit reference, keeping an individual asset around 100k polygons or fewer is a useful starting point; the appropriate budget depends heavily on the device and number of simultaneous objects.

2. Minimize draw calls

• Don't make every tiny component its own mesh/material.
• Combine meshes that share materials where practical.
• Avoid combining objects that are far apart or need independent visibility culling—otherwise you can end up rendering a giant combined mesh when only a small portion is visible.
• Material count is often just as important as polygon count.

3. Optimize textures

• Prefer 2K or smaller textures for mobile AR unless a particular surface genuinely needs more detail.
• Use texture atlases to combine several small textures.
• Use compressed GPU-friendly formats where your rendering stack supports them.
• Pack grayscale maps such as roughness/metallic/AO into channels of shared textures instead of using separate images.
• Don't spend 4K texture resolution on geometry that occupies only a small portion of the screen. Apple specifically recommends using the smallest texture that still looks good and notes that 2048 pixels per side is generally sufficient for iPhone/iPad content.

4. Keep materials simple

• Use a small number of PBR materials rather than lots of unique shaders.
• Avoid expensive transparency whenever possible; overlapping transparent surfaces cause the GPU to shade the same pixels repeatedly.
• Be conservative with reflections, clearcoat, complex procedural shaders, and other expensive material effects.

5. Bake detail instead of modeling it

• Replace high-poly surface details with normal maps, AO maps, or baked lighting information.
• A 10-million-polygon sculpt can often become a relatively lightweight real-time mesh while retaining much of its perceived detail through textures.

6. Be careful with shadows and lighting

• Dynamic shadows can become expensive, especially with complex geometry.
• Limit the number of lights and shadow-casting objects.
• Where appropriate, use baked AO or inexpensive fake-shadow techniques.

7. Optimize animation

• Reduce unnecessary skeletal joints.
• Avoid excessively complex deformers.
• Reuse animation data where possible. Skeletal animation and joint transforms can create significant GPU work.

8. Optimize loading, not just rendering

• Compress assets and remove unused textures, animations, meshes, and audio.
• Load asynchronously so asset loading doesn't block the main thread.
• Reuse mesh/material resources rather than creating duplicate copies for every instance.
• Consider splitting very large assets into smaller pieces that can be loaded progressively.

A good starting budget

For a mobile AR app, I'd start roughly like this:

These aren't universal limits—the number of objects rendered simultaneously matters enormously. Ten 50k-triangle models can be much more problematic than one 300k-triangle model in some scenes.

Most important: profile on real phones

Don't optimize based solely on polygon count. Measure CPU time, GPU time, draw calls, triangles/vertices, memory, and frame rate on your lowest-spec supported device.

For RealityKit, Apple's profiling tools expose CPU/GPU and rendering statistics, and Instruments' RealityKit Metrics can show mesh draw calls, triangles, vertices, and related bottlenecks.

The rule of thumb: LOD + low draw calls + small/compressed textures + simple materials + baked detail + device profiling will usually give you a much larger performance improvement than obsessing over triangle count alone.