Developing graphics optimization specifications for mobile VR headsets
Quest 3 renders two images at 2064×2208 pixels each, on Snapdragon XR2 Gen 2 chipset, with target frame rate 72–90 fps without frame drops. Each frame below target results in either ATW artifact (Asynchronous TimeWarp pulls old frame) or real latency causing motion sickness in the player.
Graphics optimization specification is not a wishlist of "render fewer polygons." It's a set of hard numerical constraints for each resource category, derived from real measurements in Snapdragon Profiler and OVR Metrics Tool.
What comprises the GPU budget for mobile VR
The main metric for Quest is GPU time per eye frame. At 72 fps, each eye has approximately 6.9 ms. At 90 fps – 5.5 ms. Anything exceeding this results in either ATW or frame drop.
Typical budget breakdown by categories:
Draw calls. On Adreno 740 (Quest 3), comfortable ceiling is 100–150 draw calls per eye with static batches. Without batching, 300 objects in scene easily produce 300+ draw calls and drop frames. Specification defines batching rules: which objects go to Static Batching, which to GPU Instancing, which require manual Mesh Combining.
Texture budget. VRAM on Quest 3 shares allocation with RAM. Standard – no more than 512 MB for scene textures. For mobile VR, the only reasonable format is ASTC (Adaptive Scalable Texture Compression): ASTC 6×6 for diffuse/albedo, ASTC 8×8 for roughness/metallic-packed maps. PNG or uncompressed RGBA in build – immediate red flag in audit.
Polygon budget. For scene overall – typically no more than 200–300k triangles for comfortable rendering. But distribution matters more: foreground character – up to 15k, background NPCs – 3–5k, environmental props – 50 to 2000 depending on size and position.
Shaders. For mobile VR, only reasonable choice is URP Lit or custom shader based on URP. HDRP doesn't work on Quest. Each custom shader must be profiled: instruction count, discard in fragment stage (kills early-z), dependent texture samples.
What specification document looks like
Specification is not PDF with general statements. It's a living technical document that team opens at every asset review.
Structure:
- Budget table by categories (draw calls, poly count, texture memory, shader complexity)
- Object naming and grouping rules for batching
- Checklist for each asset type: character, environment, prop, UI
- Quality Settings in Unity (shadow distance, shadow cascades = 1 or disabled, pixel light count, anti-aliasing – MSAA 2x or 4x, Fixed Foveated Rendering level)
- LOD requirements: minimum 3 levels for large objects, switching distances
- Occlusion Culling rules: Static/Dynamic occluders markup
Separate section – Multi-View rendering specifics. Meta SDK and OpenXR support Single Pass Instanced / Multi-View, where geometry renders once with two projections. Not all shaders and not all Unity components work correctly in this mode – specification contains exception list.
Specification development process
Begins with platform audit: which headset, which SDK (Meta OpenXR SDK, OpenXR via Unity XR Plugin Management), target frame rate, content type (action with many objects vs. narrative with few).
Then – analysis of existing assets if project is underway, or constraint development from scratch for new project. Constraints verified on test scene with real measurements.
Final document delivered with compliant-scene example: scene that fits all constraints and serves as team reference.
Timeline: 3–7 business days for new specification; 1–3 days for audit and adaptation of existing. Cost determined after project analysis.