/hz-unity-code-review

name: hz-unity-code-review
license: Apache-2.0
description: Reviews Unity code targeting Meta Quest and Horizon OS for performance issues, rendering best practices, and common VR pitfalls. Use during code review or when diagnosing Quest performance problems in Unity projects.
allowed-tools: Bash(metavr:*) Bash(hzdb:*)

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: U