meta-quest/hz-unity-code-review

Unity Code Review for Meta Quest

When to Use

Use this skill when reviewing Unity C# code or project settings that target Meta Quest headsets. This includes:

• Reviewing scripts for VR performance issues
• Checking rendering pipeline configuration and settings
• Ensuring adherence to Quest-specific best practices
• Identifying common VR development pitfalls
• Validating input handling for controllers, hands, and eye tracking
• Auditing memory usage and GC allocation patterns

Key Review Areas

1. Rendering Pipeline Configuration

Quest applications must use the Universal Render Pipeline (URP) with specific settings optimized for mobile VR. The Built-in Render Pipeline is not recommended for new Quest projects.

Critical settings to verify:

• Single-pass multiview must be enabled (Player Settings > XR Plug-in Management > Oculus > Stereo Rendering Mode)
• Vulkan should be the primary graphics API
• Linear color space is required for correct lighting
• HDR should be disabled in URP asset settings
• Post-processing should be minimal or disabled

2. Draw Call Budgets and Batching

Quest has draw call budgets that vary by workload complexity. Every draw call has CPU overhead that directly impacts frame timing.

| Metric | Quest 2 / Quest Pro | Quest 3 / Quest 3S | |--------|---------------------|---------------------| | Draw calls (busy simulation) | 80-200 | 200-300 | | Draw calls (medium simulation) | 200-300 | 400-600 | | Draw calls (light simulation) | 400-600 | 700-1000 | | Triangles per frame | 750K-1M | 1M-2M | | SetPass calls | < 50 | < 80 |

Enable and verify:

• Static batching for non-moving geometry
• GPU instancing for repeated objects
• SRP batcher for URP materials
• Dynamic batching for small meshes (< 300 vertices)

3. Shader Complexity

Mobile GPUs on Quest cannot handle desktop-class shaders. Review all materials for:

• Use of URP/Lit or URP/Simple Lit instead of Standard shader
• Custom shaders that minimize texture samples and ALU operations
• Avoidance of real-time shadows where possible (bake instead)
• No screen-space effects (SSAO, SSR, screen-space shadows)

4. Memory Management

GC allocations cause frame hitches and must be eliminated from hot paths.

// BAD: Allocates every frame
void Update() {
    string label = "Score: " + score.ToString();
    var enemies = FindObjectsOfType<Enemy>();
    var filtered = enemies.Where(e => e.IsAlive).ToList();
}

// GOOD: Zero allocations in Update
private StringBuilder _sb = new StringBuilder(32);
private List<Enemy> _enemyCache = new List<Enemy>();
private Enemy[] _enemyArray;

void Start() {
    _enemyArray = FindObjectsOfType<Enemy>();
}

void Update() {
    _sb.Clear();
    _sb.Append("Score: ");
    _sb.Append(score);
}

5. Input Handling

Quest supports multiple input modalities. Code should handle:

• Controllers: Use Unity's Input System Package for new projects (recommended); OVRInput is maintained for legacy support
• Hand tracking: OVRHand and OVRSkeleton for hand pose data
• Eye tracking: OVREyeGaze (Quest Pro / Quest 3, requires permission)
• Graceful switching between controller and hand tracking modes

6. Physics Configuration

Physics simulation is expensive on mobile. Review for:

• Physics timestep set to match target frame rate (72/90/120 Hz)
• Simplified collision meshes (use primitives, not mesh colliders)
• Reduced solver iterations (4-6 is usually sufficient)
• Layer-based collision matrix to minimize pair checks
• Rigidbody sleep thresholds configured appropriately

7. Audio Setup

Audio is often overlooked but can impact performance:

• Compress audio clips (Vorbis for music, ADPCM for short SFX)
• Use streaming load type for clips longer than 1 second
• Limit simultaneous audio sources (target < 16)
• Spatialize audio using Meta's audio SDK for 3D positioning

Quick Review Checklist

| Area | Target | Notes | |------|--------|-------| | Draw calls | 80-200 (busy) to 400-600 (light) | Use batching, instancing, atlasing | | Triangles | 750K-1M/frame | Use LODs, occlusion culling | | Texture resolution | Max 2K, 4K sparingly | ASTC compression required | | Shader | URP mobile shaders | No Standard shader, no screen-space effects | | Rendering mode | Single-pass multiview | Must be enabled in XR settings | | FFR | Enabled (High or HighTop) | Fixed foveated rendering reduces edge fragment cost | | MSAA | 4x quality / 2x perf | Free on tile-based GPU when configured correctly | | Target frame rate | 72 Hz minimum | 90 Hz recommended, 120 Hz for smooth experiences | | GC allocations | 0 B/frame in steady state | No allocations in Update/LateUpdate/FixedUpdate | | Audio sources | < 16 simultaneous | Use pooling for audio sources |

What to Look For in Code

GC-Heavy Patterns

// Flag these patterns in code review:
Camera.main                          // Calls FindWithTag internally
GameObject.Find("name")             // Linear search every call
GetComponent<T>() in Update         // Cache the result
new List<T>() in Update             // Allocates on heap
string + string in Update           // Creates new string objects
foreach on non-List collections     // Enumerator allocation
LINQ queries (.Where, .Select)      // Multiple allocations
Boxing (int -> object)              // Heap allocation
delegate/lambda in hot paths        // Closure allocation

Update() Misuse

// BAD: Empty Update still has overhead
void Update() { }

// BAD: Logic that doesn't need per-frame execution
void Update() {
    SavePlayerPrefs();  // Should be event-driven
}

// GOOD: Use events, coroutines, or InvokeRepeating for non-per-frame logic
void OnScoreChanged(int newScore) {
    UpdateScoreUI(newScore);
}

Camera.main Anti-Pattern

// BAD: Camera.main uses FindWithTag internally
void Update() {
    transform.LookAt(Camera.main.transform);
}

// GOOD: Cache the reference
private Transform _cameraTransform;

void Start() {
    _cameraTransform = Camera.main.transform;
}

void Update() {
    transform.LookAt(_cameraTransform);
}

Find Calls in Hot Paths

// BAD: Expensive search every frame
void Update() {
    var player = GameObject.FindWithTag("Player");
    var rb = player.GetComponent<Rigidbody>();
}

// GOOD: Cache in Awake/Start or use dependency injection
private Rigidbody _playerRb;

void Awake() {
    _playerRb = GameObject.FindWithTag("Player").GetComponent<Rigidbody>();
}

Using hzdb for Validation

You can use the hzdb tool to validate builds and check device-side behavior. Invoke via npx -y @meta-quest/hzdb <args> — no install required.

# Check connected Quest device
hzdb device list

# Install and run a build
hzdb app install path/to/build.apk
hzdb app launch com.company.app

# Check device logs for errors
hzdb adb logcat --tag Unity

# Monitor GPU performance
hzdb perf capture

Use device-side profiling to validate that code review findings translate to real performance improvements.

Reference Documents

For detailed guidance on specific topics, see the following reference documents:

• Performance Checklist — comprehensive performance targets and optimization strategies
• Rendering Best Practices — Quest-specific rendering configuration and shader guidelines
• Input Handling — controller, hand tracking, and eye tracking implementation
• Common Pitfalls — frequently encountered mistakes and their fixes