Разработка спецификаций оптимизации графики под мобильные VR шлемы
Quest 3 рендерит два изображения по 2064×2208 пикселей каждое, на чипе Snapdragon XR2 Gen 2, при целевом фрейм-рейте 72–90 fps без возможности просадок. Каждый кадр ниже цели — либо ATW-артефакт (Asynchronous TimeWarp подтягивает старый кадр), либо реальная задержка, которая вызывает sick у игрока.
Спецификация оптимизации — это не список пожеланий «делать меньше полигонов». Это набор жёстких числовых ограничений по каждой категории ресурсов, выведенный из реальных замеров в Snapdragon Profiler и OVR Metrics Tool.
Что входит в GPU-бюджет мобильного VR
Главная метрика для Quest — GPU time per eye frame. При 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 sample.
Как выглядит документ спецификации
Спецификация — это не PDF с общими словами. Это живой технический документ, который команда открывает при каждом asset review.
Структура:
- Таблица бюджетов по категориям (draw calls, poly count, texture memory, shader complexity)
- Правила именования и группировки объектов для батчинга
- Чеклист для каждого типа ассета: персонаж, окружение, prop, UI
- Настройки Quality Settings в Unity (shadow distance, 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 дня для аудита и адаптации существующей. Стоимость определяется после анализа проекта.