Розроблення специфікацій оптимізації графіки для мобільних VR шолемів
Quest 3 рендерить два зображення розміром 2064×2208 пікселів кожне на чіпсеті Snapdragon XR2 Gen 2 з цільовою частотою кадрів 72–90 fps без падінь. Кожний кадр нижче цільового – це або артефакт ATW (Asynchronous TimeWarp витягує старий кадр), або реальна затримка, що викликає motion sickness у гравця.
Специфікація оптимізації графіки – це не список бажань «рендерити менше полігонів». Це набір жорстких числових обмежень для кожної категорії ресурсів, виведених із реальних вимірів у Snapdragon Profiler та OVR Metrics Tool.
Що входить у GPU-бюджет мобільного VR
Головна метрика для Quest – GPU час на кадр для кожного ока. При 72 fps кожне око має приблизно 6.9 мс. При 90 fps – 5.5 мс. Все, що не укладається – це або ATW, або падіння кадру.
Типовий розподіл бюджету за категоріями:
Draw calls. На Adreno 740 (Quest 3) комфортна границя – 100–150 draw calls на око зі статичними батчами. Без батчингу 300 об'єктів у сцені легко дають 300+ draw calls і падінь кадру. Специфікація прописує правила батчингу: які об'єкти йдуть у Static Batching, які – у GPU Instancing, які потребують ручного Mesh Combining.
Бюджет текстур. VRAM на Quest 3 розділяється з RAM. Стандарт – не більше 512 МБ на текстури сцени. Для мобільного VR єдиний розумний формат – ASTC (Adaptive Scalable Texture Compression): ASTC 6×6 для diffuse/albedo, ASTC 8×8 для карт roughness/metallic-packed. PNG або невстисла RGBA у білді – негайний червоний прапор при аудиті.
Бюджет полігонів. Для сцени загалом – зазвичай не більше 200–300k трикутників для комфортного рендеру. Але розподіл важливіше: персонаж першого плану – до 15k, фонові NPC – 3–5k, environmental props – від 50 до 2000 залежно від розміру й позиції.
Шейдери. Для мобільного VR єдиний розумний вибір – URP Lit або кастомний шейдер на базі URP. HDRP на Quest не працює. Кожний кастомний шейдер має бути профільований: кількість інструкцій, наявність discard у fragment stage (убиває early-z), залежні texture samples.
Як виглядає документ специфікації
Специфікація – це не PDF із загальними словами. Це живий технічний документ, який команда відкриває при кожному asset review.
Структура:
- Таблиця бюджетів за категоріями (draw calls, кількість полігонів, пам'ять текстур, складність шейдера)
- Правила імен та групування об'єктів для батчингу
- Чеклист для кожного типу ассету: персонаж, оточення, prop, UI
- Налаштування Quality Settings у Unity (тінь距ання, shadow cascades = 1 або вимкнено, pixel light count, anti-aliasing – MSAA 2x або 4x, рівень Fixed Foveated Rendering)
- Вимоги LOD: мінімум 3 рівні для великих об'єктів, дистанції переключення
- Правила роботи з Occlusion Culling: розмітка Static/Dynamic occluders
Окремий блок – специфіка Multi-View рендерингу. Meta SDK та OpenXR підтримують Single Pass Instanced / Multi-View, де геометрія рендерується один раз із двома проекціями. Не всі шейдери та не всі Unity-компоненти коректно працюють у цьому режимі – специфікація містить список винятків.
Процес розроблення специфікації
Починається з платформного аудиту: який шолем, який SDK (Meta OpenXR SDK, OpenXR через Unity XR Plugin Management), цільова частота кадрів, тип контенту (action із великою кількістю об'єктів vs. narrative із малою).
Потім – аналіз існуючих ассетів, якщо проект вже в роботі, або розроблення обмежень з нуля для нового проекту. Обмеження верифікуються на тестовій сцені із реальними вимірами.
Фінальний документ здається з прикладом compliant-сцени: сцена, яка укладається в усі обмеження й служить еталоном для команди.
Терміни: 3–7 робочих днів для нової специфікації; 1–3 дні для аудиту й адаптації існуючої. Вартість визначається після аналізу проекту.