@zigrivers/scaffold 3.4.1 → 3.5.0

package/content/knowledge/game/game-vr-ar-design.md

@@ -0,0 +1,313 @@
+---
+name: game-vr-ar-design
+description: VR comfort and locomotion, stereo rendering budgets, spatial UI, hand tracking, gaze interaction, motion sickness, and certification
+topics: [game-dev, vr, ar, comfort, locomotion, spatial-ui]
+---
+
+VR and AR development is fundamentally constrained by human physiology in ways that flat-screen development is not. Every design decision — camera movement, UI placement, rendering performance, input method — must account for the vestibular system, visual comfort, and spatial cognition of the player. A frame drop that is a minor annoyance on a monitor becomes nausea-inducing in a headset. A UI panel that works at arm's length on a screen becomes unreadable at 0.5 meters or causes eye strain at 0.3 meters. Motion that the player did not initiate with their own body creates a sensory conflict that the brain interprets as poisoning. VR/AR design is not flat-screen design with head tracking bolted on — it requires rethinking interaction, performance, and comfort from first principles.
+
+## Summary
+
+### Performance Targets
+
+VR has the most demanding performance requirements in real-time rendering because dropped frames directly cause motion sickness:
+
+- **Quest 3 / Quest Pro**: 72 Hz or 90 Hz (90 Hz strongly recommended). Per-eye resolution: 2064x2208. Total pixels per frame: ~9.1 million (both eyes). GPU: Mobile Adreno, roughly equivalent to a 2018 mid-range phone GPU.
+- **PlayStation VR2**: 90 Hz or 120 Hz. Per-eye resolution: 2000x2040. Total pixels: ~8.2 million. GPU: PS5 AMD RDNA2 — much more capable than Quest but still must hit 90+ Hz.
+- **PC VR (Valve Index, Pimax)**: 90 Hz, 120 Hz, or 144 Hz. Per-eye resolution varies (Index: 1440x1600). GPU: Desktop RTX-class, but driving high refresh rates at high resolution is still demanding.
+- **Apple Vision Pro**: 90 Hz with dynamic foveated rendering. Per-eye resolution: ~3660x3200. GPU: M2+R1 chip with dedicated real-time sensor processing.
+
+**The golden rule**: Never drop below the headset's target frame rate. A single dropped frame is noticeable. Sustained drops below target cause discomfort within 30 seconds and nausea within 2-3 minutes for sensitive users.
+
+**Motion-to-photon latency**: The time between the player moving their head and the display updating. Must be below 20 ms. Above 20 ms, the visual world lags behind head movement, creating a disconnect that triggers motion sickness. Headset runtimes (SteamVR, Oculus Runtime) provide reprojection/timewarp as a safety net, but it is a fallback, not a strategy.
+
+### Comfort Ratings
+
+Platform holders (Meta, Sony, Apple) require games to self-rate their comfort level:
+
+- **Comfortable**: Stationary or room-scale with no artificial locomotion. Suitable for all players. (Example: Beat Saber, puzzle games)
+- **Moderate**: Slow artificial locomotion with comfort options. Most players tolerate with breaks. (Example: Walkabout Mini Golf, seated cockpit games)
+- **Intense**: Fast movement, artificial rotation, or camera control not driven by head movement. Many players experience discomfort. (Example: fast FPS games, roller coaster simulations)
+
+### Locomotion Options
+
+Locomotion is the most contentious design problem in VR. Every method trades off between immersion, comfort, and accessibility.
+
+**Teleportation:**
+- Player points a parabolic arc, selects a destination, and instantly moves there
+- Most comfortable (zero vestibular conflict)
+- Breaks spatial continuity — players lose sense of distance traveled
+- Standard for Quest platform and first-time VR users
+
+**Smooth locomotion (thumbstick movement):**
+- Continuous movement in the direction the player is looking or pointing
+- Familiar to flat-screen gamers
+- Causes motion sickness in 30-60% of new VR users
+- Always offer as an option alongside teleportation, never as the only choice
+
+**Snap turn vs smooth turn:**
+- Snap turn rotates in fixed increments (30, 45, or 90 degrees) — eliminates rotational vestibular mismatch
+- Smooth turn rotates continuously — more immersive but more nauseating
+- Default to snap turn; offer smooth turn as an advanced option
+
+**Room-scale (1:1 physical movement):**
+- Player walks in real space; movement is tracked 1:1 in the virtual world
+- Zero motion sickness (vestibular and visual signals match perfectly)
+- Limited by physical play area (typically 2x2 m to 3x3 m)
+- Best for experiences designed around small spaces
+
+## Deep Guidance
+
+### Stereo Rendering Architecture
+
+VR renders every frame twice — once per eye — with slightly different camera positions to create stereoscopic depth. This doubles the rendering cost compared to flat-screen at the same resolution.
+
+**Single-pass stereo rendering:**
+
+Modern VR SDKs (OpenXR, Unity XR, Unreal VR) support single-pass stereo, which renders both eyes in a single draw call using instanced rendering. This eliminates the CPU overhead of submitting draw calls twice.
+
+```hlsl
+// Single-pass instanced stereo vertex shader (HLSL / Unity URP example)
+// The GPU renders each triangle twice — once per eye — using SV_InstanceID
+// or unity_StereoEyeIndex to select the correct view-projection matrix.
+
+struct VertexInput {
+    float3 positionOS : POSITION;
+    float3 normalOS   : NORMAL;
+    float2 uv         : TEXCOORD0;
+    UNITY_VERTEX_INPUT_INSTANCE_ID
+};
+
+struct VertexOutput {
+    float4 positionCS : SV_POSITION;
+    float2 uv         : TEXCOORD0;
+    float3 normalWS   : TEXCOORD1;
+    UNITY_VERTEX_OUTPUT_STEREO
+};
+
+VertexOutput vert(VertexInput input) {
+    VertexOutput output;
+    UNITY_SETUP_INSTANCE_ID(input);
+    UNITY_INITIALIZE_VERTEX_OUTPUT_STEREO(output);
+
+    float3 positionWS = TransformObjectToWorld(input.positionOS);
+    output.positionCS = TransformWorldToHClip(positionWS);
+    output.normalWS   = TransformObjectToWorldNormal(input.normalOS);
+    output.uv         = input.uv;
+    return output;
+}
+```
+
+**Foveated rendering:**
+
+Foveated rendering reduces pixel workload by rendering the periphery at lower resolution than the center of the player's gaze. Fixed foveated rendering uses a static center region; eye-tracked foveated rendering dynamically follows the player's gaze.
+
+Performance impact:
+- Fixed foveated rendering (Quest 3): 20-30% GPU time savings at high foveation levels
+- Eye-tracked foveated rendering (PSVR2, Vision Pro): 40-50% GPU time savings with no perceptible quality loss
+- Outer ring can render at 1/4 to 1/16 resolution with minimal visual impact because peripheral vision has very low acuity
+
+**Rendering budget for Quest 3 (mobile VR):**
+- Target: 90 FPS = 11.1 ms per frame
+- Draw calls: 50-100 maximum (batching and instancing are critical)
+- Triangles: 100K-300K per frame (both eyes combined)
+- Texture memory: 200-400 MB (compressed ASTC textures mandatory)
+- Shader complexity: avoid multi-pass shaders; one directional light, baked GI, no real-time shadows if possible
+- Post-processing: avoid or minimize — bloom, SSAO, and motion blur are expensive and motion blur in VR causes nausea
+
+**Rendering budget for PC VR:**
+- Target: 90-120 FPS depending on headset
+- Draw calls: 500-2,000 (still much lower than flat-screen games due to frame rate target)
+- Triangles: 1-3 million per frame
+- Real-time shadows: one cascade, limited distance
+- Post-processing: use sparingly; temporal anti-aliasing is recommended but must be tuned to avoid ghosting at high head rotation speeds
+
+### Spatial UI Design
+
+VR UI cannot follow flat-screen conventions. Flat HUDs locked to the camera (head-locked UI) cause eye strain and nausea. VR UI must exist in 3D space.
+
+**UI placement guidelines:**
+
+- **Comfortable viewing distance**: 1.5-3.0 meters from the player. Closer than 1.0 m forces uncomfortable eye convergence. Farther than 5.0 m loses readability.
+- **Comfortable viewing angle**: Within 30 degrees of center gaze (horizontally and vertically). UI at extreme angles requires neck rotation, which fatigues players.
+- **Text size**: Minimum 1.0 degree of visual arc per line height. At 2 meters distance, this is approximately 3.5 cm tall text. For Quest 3 resolution, aim for 1.5+ degrees per line to remain crisp.
+- **Panel curvature**: Curve large UI panels to maintain consistent distance from the player's eyes across the panel's width. A flat 2-meter-wide panel has edges 15-20% farther from the player than the center, causing focus mismatch.
+
+**UI anchoring strategies:**
+
+```
+World-locked UI:
+  - Attached to a fixed position in the game world
+  - Example: A scoreboard on a virtual wall, a label above an NPC
+  - Feels most natural and immersive
+  - Disappears when the player turns away (can be disorienting if critical)
+
+Body-locked UI:
+  - Follows the player's body position but not head rotation
+  - Example: A wrist-mounted menu (look at your virtual wrist to open)
+  - Good for persistent info (health, ammo) without head-lock nausea
+  - Requires the player to consciously look at it
+
+Tag-along UI:
+  - Lazily follows head gaze with damping and deadzone
+  - Stays roughly in front of the player but does not track head 1:1
+  - Soft spring behavior: UI drifts into view when the player looks away for a few seconds
+  - Good for notifications, subtitles, and non-critical persistent info
+  - NEVER lock UI rigidly to the head — this is the most common VR UI mistake
+
+Hand-attached UI:
+  - Anchored to the player's tracked hand or controller
+  - Example: Inventory panel that appears when the player flips their hand palm-up
+  - Natural interaction metaphor but can be jittery on hand tracking (vs controllers)
+```
+
+### Hand Tracking and Gaze Interaction
+
+Hand tracking (Quest, Vision Pro) eliminates controllers but introduces new design constraints:
+
+**Hand tracking limitations:**
+- Accuracy: ±5-10 mm positional, ±5-10 degree rotational (much worse than controller tracking)
+- Occlusion: Hands behind the back, behind the head, or overlapping each other lose tracking
+- Latency: 20-40 ms higher than controller input
+- False positives: Casual hand movements may trigger unintended interactions
+- Fatigue: Sustained arm-raised interactions cause "gorilla arm" fatigue within 2-3 minutes
+
+**Design rules for hand tracking:**
+- Use large interaction targets (minimum 6 cm diameter at arm's length)
+- Provide visual and audio feedback for hover, select, and release states
+- Rest position for hands should be below chest height — do not require raised arms for extended interactions
+- Avoid precision tasks (small buttons, fine sliders) — hand tracking does not have the precision
+- Always provide a controller fallback for accessibility
+
+**Gaze interaction (eye tracking):**
+- Eye tracking (PSVR2, Vision Pro, Pimax Crystal) allows gaze to act as a pointer
+- Gaze + pinch (Vision Pro model): Look at a target, pinch thumb-and-finger to select
+- Gaze + dwell: Look at a target for a threshold duration (1.0-1.5 seconds) to select
+- Dwell timers need visual feedback (radial progress indicator on the target)
+- Midas touch problem: Players look at things they do not intend to interact with; require explicit confirmation (pinch, button press, or dwell) rather than gaze-alone activation
+
+### Motion Sickness Mitigation
+
+Motion sickness in VR (technically "cybersickness") is caused by conflict between vestibular (inner ear) and visual signals. The inner ear reports "not moving" while the eyes report "moving." The brain interprets this conflict as potential poisoning and triggers nausea.
+
+**Proven mitigation techniques:**
+
+```
+Technique               | Effectiveness | Immersion Cost
+────────────────────────┼───────────────┼───────────────
+Teleportation           | High          | High (breaks continuity)
+Snap turn               | High          | Low
+Vignetting during move  | Medium-High   | Low (reduces FOV temporarily)
+Stationary reference    | Medium        | Low (cockpit, nose)
+Reduced FOV during move | Medium        | Medium
+Comfort cage / grid     | Medium        | Medium (visible overlay)
+Slower movement speed   | Medium        | Low
+Head-bob removal        | Medium        | Low
+Fixed horizon line      | Medium        | Low
+```
+
+**Vignetting (tunnel vision):**
+- During artificial locomotion, darken or black out the peripheral vision
+- Reduces the visual area that conflicts with vestibular signals
+- Player adjustable: some players want full FOV, others need heavy vignetting
+- Implementation: post-process shader that blends a dark vignette from the edges inward when velocity exceeds a threshold
+
+**Stationary reference frame:**
+- Add a fixed visual element that does not move with the virtual world
+- A virtual nose, cockpit dashboard, or helmet rim provides a stable reference that reduces conflict
+- Even a subtle grid overlay on the floor during movement reduces discomfort
+
+**Developer testing protocol:**
+- Test with VR-naive users (not just the dev team, who have developed "VR legs")
+- Minimum 20-minute test sessions — sickness often appears after 10-15 minutes of continuous play
+- Include a post-session questionnaire (Simulator Sickness Questionnaire / SSQ)
+- Track drop-off points where testers request to stop
+- Any feature that causes 20%+ of testers to report discomfort must be optional or removed
+
+### VR-Specific Certification Requirements
+
+Platform holders impose VR-specific certification requirements beyond standard console certification:
+
+**Meta Quest Store requirements:**
+- Must maintain 72 Hz or 90 Hz with zero dropped frames during normal gameplay
+- Must not render anything closer than 0.5 m to the camera (causes eye strain)
+- Must include a "recenter" option accessible at any time
+- Must pause when the headset is removed (proximity sensor)
+- Must render a passthrough or guardian boundary when the player approaches play area edges
+- Must include comfort rating metadata in the store listing
+- Must not artificially move the camera without player input (no forced camera animations, no cutscenes that rotate the player)
+
+**PlayStation VR2 requirements:**
+- Must support 90 Hz minimum; 120 Hz mode recommended for fast-paced games
+- Must implement reprojection correctly (Sony provides the SDK)
+- Must use eye-tracking-based foveated rendering (PlayStation SDK provides the API)
+- Must support the Sense controller haptics (adaptive triggers, haptic feedback)
+- Must implement the "cinematic mode" fallback for non-VR displays
+- Must display health and safety warnings at first launch
+
+**Apple visionOS requirements:**
+- Must use RealityKit or Metal with the Compositor Services API
+- Must support Shared Space (runs alongside other apps) or Full Space (exclusive VR mode)
+- Must implement passthrough correctly — never render over the user's real environment without explicit consent
+- Must support eye-and-pinch interaction as the primary input method
+- Must handle "Digital Crown" press to return to the home view
+- Must not cause the system thermal throttling warning (sustained thermal headroom)
+
+### AR-Specific Design Considerations
+
+AR overlays virtual content onto the real world, introducing unique constraints:
+
+**Spatial anchoring:**
+- Virtual objects must be anchored to real-world surfaces (planes, walls, floors) detected by the device's scene understanding
+- Anchors drift over time (1-5 cm per minute without re-localization)
+- Save and restore anchors across sessions using persistent world maps (ARKit, ARCore, or OpenXR spatial anchors)
+- Test on various surface types: glossy floors, textured carpet, low-light rooms, outdoor grass
+
+**Lighting estimation:**
+- AR devices estimate real-world lighting direction and intensity
+- Virtual objects must match the real-world lighting to avoid looking "pasted on"
+- Use the AR framework's light estimation API (ARKit provides ambient intensity + color temperature + directional light probes)
+- Cast virtual shadows onto real-world surfaces for grounding
+
+**Occlusion:**
+- Real-world objects should occlude (block) virtual objects that are behind them
+- LiDAR-equipped devices (iPhone Pro, iPad Pro, Vision Pro) provide depth maps for real-time occlusion
+- Non-LiDAR devices can approximate with plane-based occlusion (objects behind detected floor/wall planes are hidden)
+- Imperfect occlusion is more distracting than no occlusion — if the device cannot produce clean occlusion, consider disabling it
+
+**Interaction distance:**
+- AR content at arm's length (0.3-1.0 m) works for tabletop experiences and close-up inspection
+- AR content at room scale (1-5 m) works for furniture placement, navigation overlays
+- AR content beyond 5 m has significant tracking drift and parallax issues on phone-based AR
+- Head-mounted AR (Vision Pro, HoloLens) handles distance better due to stereoscopic depth
+
+### Performance Profiling for VR
+
+Standard profiling tools miss VR-specific issues. Use platform-specific VR profilers:
+
+```
+Platform        | Profiling Tool              | Key Metrics
+────────────────┼─────────────────────────────┼─────────────────────────────
+Quest 3         | Meta Quest Developer Hub    | FPS, GPU utilization %,
+                | (MQDH) + OVR Metrics Tool   | CPU/GPU frame time,
+                |                             | thermal state, foveation level
+────────────────┼─────────────────────────────┼─────────────────────────────
+PC VR           | SteamVR Frame Timing        | Frame time, reprojection %,
+                | + fpsVR + GPU vendor tools  | GPU/CPU bound indicator,
+                | (Nsight, RenderDoc)         | motion-to-photon latency
+────────────────┼─────────────────────────────┼─────────────────────────────
+PSVR2           | PlayStation Performance     | Frame time per eye,
+                | Analyzer (Razor)            | foveated rendering savings,
+                |                             | Sense controller haptic load
+────────────────┼─────────────────────────────┼─────────────────────────────
+Vision Pro      | Xcode Instruments +         | Render pipeline timeline,
+                | RealityKit Trace            | thermal headroom %,
+                |                             | compositor latency
+```
+
+**Key VR profiling metrics:**
+- **Frame time (per eye)**: Must stay under the frame budget (11.1 ms at 90 Hz)
+- **Reprojection/timewarp ratio**: Percentage of frames that required reprojection. Above 5% indicates consistent performance problems. Above 20% causes visible artifacts.
+- **Thermal state**: Mobile VR (Quest) throttles GPU/CPU when overheating. Monitor thermal headroom and reduce quality settings proactively before thermal throttling kicks in.
+- **Draw call count**: VR amplifies draw call overhead because each call may be issued twice (once per eye, unless using single-pass stereo). Batch aggressively.
+- **Shader complexity**: Profile per-pixel shader cost. In VR, the pixel count is 2-3x a 1080p flat-screen game, so expensive fragment shaders hit much harder.

package/content/knowledge/review/review-art-bible.md

@@ -0,0 +1,305 @@
+---
+name: review-art-bible
+description: Failure modes and review passes specific to Art Bible documents — budget consistency, naming conventions, LOD coverage, and pipeline validation
+topics: [game-dev, review, art, assets, lod, naming]
+---
+
+# Review: Art Bible
+
+The Art Bible defines visual standards, asset specifications, and production pipelines for every art asset in the game. It must be consistent with performance budgets, complete in naming conventions and LOD tier definitions, and actionable for artists working in DCC tools. This review uses 7 passes targeting the specific ways Art Bibles fail.
+
+Follows the review process defined in `review-methodology.md`.
+
+## Summary
+
+- **Pass 1 — Budget Consistency**: Polygon counts, texture sizes, and draw call limits align with performance budgets defined elsewhere; no asset exceeds its tier's budget.
+- **Pass 2 — Naming Convention Completeness**: Every asset type (mesh, texture, material, animation, audio, VFX) has a naming convention; no gaps force artists to invent names.
+- **Pass 3 — LOD Tier Coverage**: LOD tiers are defined for every asset category with specific poly reduction targets, transition distances, and quality fallback rules.
+- **Pass 4 — Pipeline Validation Steps**: Every stage from DCC export to engine import has a validation step; no "hope it works" gaps in the pipeline.
+- **Pass 5 — Platform-Specific Compression**: Texture compression formats, audio codecs, and mesh optimization targets are specified per target platform.
+- **Pass 6 — DCC-to-Engine Import Validation**: Export settings, coordinate systems, scale factors, and material mappings are documented for every DCC-to-engine path.
+- **Pass 7 — Style Guide Enforceability**: Visual style rules are objectively verifiable, not subjective; an artist can determine compliance without asking the art director.
+
+## Deep Guidance
+
+---
+
+## Pass 1: Budget Consistency
+
+### What to Check
+
+Polygon counts, texture memory budgets, draw call targets, and shader complexity limits in the Art Bible align with performance budgets defined in the technical design or performance-budgets document. No individual asset spec exceeds what the performance budget allocates for its category.
+
+### Why This Matters
+
+An Art Bible that specifies 50K polygons per character while the performance budget allocates 200K polygons for 10 on-screen characters has a math problem — 10 × 50K = 500K, which is 2.5x over budget. This disconnect is invisible until the game runs at 15 FPS on target hardware. Budget consistency between the Art Bible and performance constraints is the single most impactful review pass.
+
+### How to Check
+
+1. Extract per-asset-type budgets from the Art Bible: characters, props, environment tiles, VFX, UI elements
+2. Extract scene composition limits from the performance budget: max simultaneous characters, max props in view, max active VFX
+3. Multiply: (per-asset budget) × (max simultaneous count) = total budget consumption per category
+4. Sum all categories — does the total exceed the frame budget for the target platform?
+5. Check texture memory: total unique textures × resolution × format size vs. available VRAM on minimum spec hardware
+6. Verify draw call budget: each material instance is typically one draw call — count materials × max instances
+7. Check shader complexity: are there real-time shadowing, SSR, volumetric, or post-process budgets that conflict with art specifications?
+
+### What a Finding Looks Like
+
+- P0: "Art Bible specifies 4K textures for hero characters (4 × 4096×4096 RGBA = 256MB). With 4 characters on screen, texture memory alone is 1GB — exceeding the 2GB VRAM target when environment textures are included."
+- P1: "Character polygon budget is 30K but no LOD specification exists. At 200m distance, 30K characters consume the same budget as at 5m distance."
+- P2: "VFX particle budget says 'up to 10,000 particles per effect' but does not specify max simultaneous effects. 3 effects × 10K = 30K particles may exceed the GPU particle budget."
+
+---
+
+## Pass 2: Naming Convention Completeness
+
+### What to Check
+
+Every asset type in the production pipeline has an explicit naming convention. Naming covers prefixes/suffixes for type identification, platform/LOD/variant tagging, and version control disambiguation. No asset type requires an artist to invent a naming scheme.
+
+### Why This Matters
+
+Inconsistent naming breaks automated pipelines. When the build system expects `T_CharacterName_D.png` for diffuse textures and an artist names it `CharacterName_diffuse.tga`, the import pipeline either fails silently or imports the asset incorrectly. At scale, naming inconsistency makes asset search, batch processing, and automated validation impossible. Every hour spent fixing naming retroactively costs 10x the effort of defining conventions upfront.
+
+### How to Check
+
+Use this checklist to verify every asset type is covered:
+
+```markdown
+## Naming Convention Coverage Checklist
+
+### Meshes
+- [ ] Static meshes: prefix, category, variant, LOD suffix
+- [ ] Skeletal meshes: prefix, character/creature name, variant
+- [ ] Collision meshes: prefix convention (UCX_, UBX_, USP_ or equivalent)
+- [ ] LOD suffix convention: _LOD0, _LOD1, _LOD2, etc.
+
+### Textures
+- [ ] Diffuse/Albedo: suffix convention (_D, _Albedo, _BaseColor)
+- [ ] Normal map: suffix convention (_N, _Normal)
+- [ ] Roughness/Metallic/AO: suffix conventions for each channel
+- [ ] Packed channel maps: channel order documented (e.g., RGBA = R:Metallic, G:Roughness, B:AO, A:Height)
+- [ ] Emissive: suffix convention (_E, _Emissive)
+- [ ] Resolution suffix if multiple resolutions exist (_2K, _4K)
+
+### Materials
+- [ ] Master material naming
+- [ ] Material instance naming: parent reference in name
+- [ ] Material function naming
+
+### Animations
+- [ ] Animation clip naming: character_action_variant format
+- [ ] Animation blend space naming
+- [ ] Animation montage naming
+- [ ] Additive vs. override distinction in name
+
+### Audio
+- [ ] Sound cue naming
+- [ ] Waveform file naming
+- [ ] Music track naming
+- [ ] Attenuation preset naming
+
+### VFX
+- [ ] Particle system naming
+- [ ] VFX texture naming (flipbook, noise, gradient)
+- [ ] VFX material naming
+
+### UI
+- [ ] Widget/component naming
+- [ ] Icon naming: category_name_state format
+- [ ] Font asset naming
+
+### Folders
+- [ ] Folder hierarchy convention documented
+- [ ] Per-asset-type folder location specified
+- [ ] Shared vs. unique asset folder rules
+```
+
+### What a Finding Looks Like
+
+- P0: "Texture naming convention exists for diffuse and normal maps but packed channel maps (ORM, MRAO) have no convention. Artists will invent inconsistent suffixes and channel orders."
+- P1: "Animation naming convention uses character_action format but does not address variants. 'Hero_Run' and 'Hero_Run_Injured' need a variant convention or the library becomes unsearchable."
+- P2: "VFX textures have no naming convention distinct from material textures. A search for 'Smoke' returns both VFX flipbooks and environment material textures."
+
+---
+
+## Pass 3: LOD Tier Coverage
+
+### What to Check
+
+LOD (Level of Detail) tiers are defined for every asset category that appears at varying distances. Each tier specifies polygon reduction targets, texture downscale ratios, transition distances, and quality fallback rules for when LOD transitions are visible.
+
+### Why This Matters
+
+Without LOD specifications, every asset renders at maximum quality regardless of screen size. A 50K polygon character at 500m distance occupies 3 pixels but consumes the same GPU budget as at 5m. LOD is the primary tool for maintaining frame rate in open environments. Missing LOD specs mean either every asset is over-budgeted for distance viewing (wasting GPU) or under-budgeted for close-up viewing (visible quality loss).
+
+### How to Check
+
+1. Verify LOD tiers exist for: characters, props, environment assets, foliage, vehicles, weapons
+2. For each asset category, check that each LOD tier specifies: polygon count or percentage reduction, texture resolution, transition distance
+3. Verify transition method: distance-based, screen-size-based, or manual — is it consistent across categories?
+4. Check for LOD transition artifacts: does the Art Bible specify dithering, cross-fade, or hard-cut transitions?
+5. Verify that LOD0 (highest quality) budget matches the performance budget from Pass 1
+6. Check for imposter/billboard LODs for distant foliage and crowd characters
+7. Verify that skeletal meshes have LOD-appropriate bone reduction (fewer bones at lower LODs to reduce skinning cost)
+
+### What a Finding Looks Like
+
+- P0: "No LOD specification exists for any asset type. The game has open-world environments where assets are visible at 50m-2000m distances."
+- P1: "Character LODs are defined (LOD0-LOD3) but environment props have no LOD specification. Dense environments with hundreds of props will exceed frame budget."
+- P1: "LOD transition distance is specified as 'appropriate for the asset size' — this is not a specification. Each asset category needs concrete distance thresholds."
+- P2: "Foliage LODs exist but no imposter/billboard LOD is specified for distances beyond 200m. Dense forests will render full 3D meshes at any distance."
+
+---
+
+## Pass 4: Pipeline Validation Steps
+
+### What to Check
+
+The Art Bible defines validation checkpoints at every stage of the asset pipeline: DCC authoring constraints, export settings verification, automated import validation, in-engine quality checks, and integration testing. No stage relies on "the artist will check it looks right."
+
+### Why This Matters
+
+Art pipelines without validation gates produce assets that are technically correct in the DCC tool but broken in-engine. Typical failures: non-manifold geometry that renders in Maya but creates lighting artifacts in-engine, textures with wrong color space (sRGB vs. linear) that look correct in Photoshop but are washed out in-engine, animations with baked scale that cause character size to change. Each failure is discovered late and costs exponentially more to fix.
+
+### How to Check
+
+1. Map the pipeline stages: concept → modeling → texturing → rigging → animation → export → import → integration
+2. For each stage, verify a validation step exists with specific pass/fail criteria
+3. Check that validation criteria are automatable where possible (polygon count check, texture size check, naming convention check)
+4. Verify that DCC-side validation exists: artists should catch problems before export, not after import
+5. Check for batch validation tooling: can the entire asset library be validated in one pass?
+6. Verify that validation failures have a documented remediation path (not just "fix it")
+7. Check that the validation pipeline handles asset updates (re-imported assets) not just new assets
+
+### What a Finding Looks Like
+
+- P0: "No automated validation steps exist in the pipeline. Asset quality is verified manually by the art lead reviewing each asset in-engine."
+- P1: "Export validation checks polygon count but not UV layout. Overlapping UVs cause lightmap artifacts that are only discovered during level lighting builds."
+- P2: "Validation exists for new assets but re-imported assets (updates) bypass validation. An artist updating a texture could introduce a color space error that goes undetected."
+
+---
+
+## Pass 5: Platform-Specific Compression
+
+### What to Check
+
+Texture compression formats, audio codecs, mesh optimization targets, and shader feature levels are specified per target platform. The Art Bible does not assume a single platform — it documents the differences and provides per-platform asset specifications.
+
+### Why This Matters
+
+Each platform has different compression format requirements (ASTC for mobile, BC7 for PC/console, ETC2 for older Android), memory constraints, and GPU capabilities. An Art Bible that specifies "use DXT5 compression" without acknowledging mobile targets will produce assets that either cannot be loaded on mobile or are decompressed at runtime (doubling memory usage). Platform-specific compression is not optional — it is a correctness requirement.
+
+### How to Check
+
+1. List all target platforms from the GDD or technical design
+2. For each platform, verify texture compression formats are specified: PC (BC1-BC7), Console (BC1-BC7, platform-specific), Mobile (ASTC, ETC2), Web (basis/KTX2)
+3. Verify audio codec specifications per platform: Vorbis, Opus, ADPCM, platform-native
+4. Check that mesh complexity targets differ per platform where hardware diverges (mobile vs. PC)
+5. Verify that shader feature level targets per platform are documented
+6. Check for a fallback chain: if the preferred format is unsupported, what is the fallback?
+7. Verify that platform-specific build configurations are documented for the asset pipeline
+
+```markdown
+## Platform Compression Matrix
+
+| Asset Type    | PC (DX12/Vulkan) | Console (PS5/XSX) | Mobile (iOS/Android) | Switch     |
+|---------------|-------------------|--------------------|----------------------|------------|
+| Diffuse       | BC7               | BC7                | ASTC 4x4             | ASTC 4x4   |
+| Normal        | BC5               | BC5                | ASTC 6x6             | ASTC 6x6   |
+| ORM Pack      | BC7               | BC7                | ASTC 4x4             | ASTC 4x4   |
+| UI            | BC7 (sRGB)        | BC7 (sRGB)         | ASTC 4x4 (sRGB)     | ASTC 4x4   |
+| Audio (SFX)   | Vorbis Q6         | Platform native    | Opus 96kbps          | ADPCM      |
+| Audio (Music) | Vorbis Q8         | Platform native    | Opus 128kbps         | Vorbis Q6  |
+| Mesh LOD0     | 100%              | 100%               | 50%                  | 60%        |
+```
+
+### What a Finding Looks Like
+
+- P0: "Art Bible specifies BC7 texture compression with no mobile platform section. The game targets iOS and Android where BC7 is not natively supported."
+- P1: "Audio is specified as 'WAV in production, compressed for shipping' without specifying the target codec or quality per platform."
+- P2: "Switch platform is listed as a target but has no platform-specific compression or budget section. Switch has significantly lower GPU and memory budgets than PS5/XSX."
+
+---
+
+## Pass 6: DCC-to-Engine Import Validation
+
+### What to Check
+
+Export settings from every DCC tool (Maya, Blender, 3ds Max, Substance, ZBrush, Houdini) to the target engine are documented. Coordinate system handedness, scale factors, axis orientation, FBX settings, material channel mappings, and animation export options are all specified.
+
+### Why This Matters
+
+Every DCC tool uses different conventions. Blender is Z-up right-handed, Unreal is Z-up left-handed, Unity is Y-up left-handed. A model exported from Blender without the correct axis conversion will appear rotated 90 degrees in Unreal. Scale factor mismatches (1 unit = 1cm vs. 1 unit = 1m) produce assets that are 100x too large or too small. Material channel mappings differ between Substance Painter's export presets and engine material inputs. Each mismatch is a bug that wastes time to diagnose.
+
+### How to Check
+
+1. List all DCC tools used in the pipeline
+2. For each DCC-to-engine path, verify these are documented:
+   - Coordinate system and axis orientation
+   - Scale factor (units per meter)
+   - FBX export version and settings (if FBX is the interchange format)
+   - Material/texture channel mapping (Substance channels to engine material inputs)
+   - Animation export settings (bake vs. curves, frame rate, root motion handling)
+   - Skeletal mesh: bone naming convention, required root bone, max bone count
+3. Verify that import settings in the engine are documented (not just export settings)
+4. Check for automated import rules (engine import settings presets per asset type)
+5. Verify that round-trip workflows are documented (export → import → modify in engine → re-export to DCC if needed)
+
+### What a Finding Looks Like
+
+- P0: "No DCC-to-engine export documentation exists. Artists must discover correct export settings by trial and error."
+- P1: "Blender export settings are documented but Substance Painter texture channel mappings are not. Artists exporting from Substance must guess which channel maps to which engine input."
+- P1: "Animation export settings do not address root motion. Locomotion animations may have root motion baked in or extracted — the convention is undocumented."
+- P2: "FBX export version is not specified. FBX 2020 and FBX 2014 handle blend shapes differently — inconsistent versions across the team will produce different results."
+
+---
+
+## Pass 7: Style Guide Enforceability
+
+### What to Check
+
+Visual style rules are defined in objectively verifiable terms. An artist can determine whether their work complies without subjective judgment. Color palettes have specific hex/RGB values, proportions have ratios, and stylization rules reference concrete visual examples rather than mood descriptions.
+
+### Why This Matters
+
+A style guide that says "warm, inviting color palette" is not enforceable. Five artists will produce five different interpretations of "warm and inviting." When the art lead must manually review every asset for style compliance, the art lead becomes a bottleneck and a single point of failure. Objectively verifiable style rules enable self-review and automated validation (hue range checks, proportion ratio checks), scaling art production without scaling art direction overhead.
+
+### How to Check
+
+1. Check color specifications: are palettes defined with specific values (hex, RGB, HSV ranges) or subjective descriptions ("warm tones")?
+2. Verify proportion rules: character head-to-body ratios, prop scale references, environment module dimensions — are they numeric?
+3. Check stylization rules: if the style is "stylized," what are the specific deviations from realism? (Edge softness, saturation boost, proportion exaggeration percentages)
+4. Verify material property ranges: roughness 0.3-0.7, metallic 0 or 1 only (no partial metallic), emissive intensity ranges
+5. Check for visual reference sheets per asset category: characters, props, environments, UI — do they exist?
+6. Verify that "do" and "don't" examples exist for common style violations
+7. Check that the style guide addresses edge cases: what happens when gameplay clarity conflicts with style? (Enemy readability vs. environmental cohesion)
+
+### What a Finding Looks Like
+
+- P0: "Color palette is described as 'earthy tones with vibrant accents' with no specific values. This is a mood description, not a specification."
+- P1: "Character proportion guide shows a reference image but no numeric ratios. Subtle proportion differences between artists will accumulate into an inconsistent character roster."
+- P2: "Roughness values for wood materials are described as 'fairly rough' — specify a range (0.6-0.8) so artists and material validation tools have a concrete target."
+
+---
+
+## Common Review Anti-Patterns
+
+### 1. Art Bible Without Performance Budget Cross-Reference
+
+The Art Bible defines beautiful, detailed asset specifications that were never compared against the game's performance budget. The specs are aspirational quality targets that will produce a game running at 15 FPS. The review must catch this disconnect before production begins.
+
+**How to spot it:** The Art Bible contains no references to frame budget, VRAM budget, or draw call limits. Asset specifications are described in terms of quality ("high-quality PBR materials") rather than budgets ("2048×2048 textures, 3 texture sets per character").
+
+### 2. Naming Convention for Meshes Only
+
+The naming convention section thoroughly covers mesh naming but skips textures, materials, animations, audio, or VFX. In practice, texture naming inconsistency causes more pipeline failures than mesh naming because textures have more variants (diffuse, normal, ORM, emissive, mask) and more naming ambiguity.
+
+**How to spot it:** Count the asset types covered by the naming convention. If fewer than 6 categories are covered, significant gaps exist.
+
+### 3. Single-Platform Art Bible for Multi-Platform Game
+
+The Art Bible specifies one set of asset standards (typically the highest-end target platform) and assumes other platforms will be "optimized later." Platform-specific compression, budget, and quality targets are absent. In practice, "optimize later" means a 6-month crunch to make assets work on lower-end platforms.
+
+**How to spot it:** The Art Bible has no platform-specific sections. Texture formats, poly budgets, and shader targets reference only one platform. Words like "we will optimize for mobile later" appear.