Оптимизация графики под VR/AR устройства: аудит и правки для 72 fps

В VR кадр нужно рендерить дважды — для левого и правого глаза. На Quest 2 это 72 fps × 2 = 144 Draw Call-пачки в секунду. Если ваш проект не прошёл через Single Pass Instanced Rendering и у вас больше 100 batches на кадр, стереоскопическая сцена просто не уложится в тайм-слот GPU. Головная боль и тошнота у пользователей — прямое следствие dropped frames. Мы на практике знаем, как это исправить: за плечами десятки оптимизированных XR-проектов под разные платформы. Наша специализация — оптимизация графики под VR/AR устройства.

AR-проекты на ARCore/ARKit добавляют поверх этого захват с камеры, обработку плоскостей и occlusion mesh. Устройство уже загружено CPU-задачами трекинга до того, как ваш шейдер сделал первый вызов. Мы помогаем уложиться в FPS-бюджет даже на бюджетных устройствах. Закажите аудит — мы оценим ваш проект за 2 дня и предоставим план оптимизации с конкретными метриками.

Как оптимизация графики под VR/AR устройства решает проблему dropped frames?

Ключевые техники — Single Pass Instanced Rendering, Fixed Foveated Rendering, GPU Instancing и оптимизация шейдеров. Single Pass Instanced позволяет рендерить оба глаза за один проход, снижая количество Draw Calls вдвое. Fixed Foveated Rendering уменьшает нагрузку на GPU на 15–30% без заметного ухудшения картинки. GPU Instancing группирует одинаковые объекты в один Draw Call. Вместе эти методы обеспечивают стабильные 72 fps даже на мобильных XR-устройствах.

Почему стандартные методы оптимизации графики не работают в VR/AR?

Снижение полигонажа — это последнее, что мы делаем. Сначала смотрим на то, что реально убивает производительность на XR-устройствах.

Overdraw в мобильном VR

На Adreno и Mali GPU overdraw стоит непропорционально дорого — тайловый рендер не любит большое количество полупрозрачных объектов. Стандартные партикл-системы с Additive-блендингом на фоне HDR-скайбокса — типичный убийца frame rate на Quest. Frame Debugger в Unity покажет это мгновенно: ищем красные зоны в overdraw view.

Неправильная настройка Fixed Foveated Rendering

Fixed Foveated Rendering на Meta XR SDK снижает нагрузку на GPU на 15-30% — но только если правильно выбран уровень (Low/Medium/High) под конкретный контент. В динамичных сценах с быстрым движением камеры High-уровень даёт артефакты на периферии. Рекомендуем Medium для большинства проектов: он даёт до 20% прироста производительности без заметных артефактов.

Single Pass Instanced не работает с кастомными шейдерами

Если в проекте есть хоть один шейдер без UNITY_VERTEX_INPUT_INSTANCE_ID и UNITY_SETUP_INSTANCE_ID, весь рендер автоматически fallback'ается в Multi Pass. Это удваивает нагрузку. Находим через XR Plug-in Management → Rendering Stats. Мы гарантируем, что после аудита все шейдеры будут корректно поддерживать Single Pass Instanced.

Как мы работаем с XR-проектами

Начинаем с профилирования на целевом железе — не в Editor, а на устройстве. RenderDoc для Android, Xcode Instruments для iOS/visionOS, OVR Metrics Tool (часть Meta XR Best Practices Guide). Эмулятор не покажет реальных задержек памяти и bandwidth.

Из нашей практики: кейс клиента

Проект под Quest 3 — архитектурная визуализация, 8 комнат, PBR-материалы. Первый билд: 45 fps в центре сцены, 28 fps при взгляде в сторону окна. Анализ через OVR Metrics Tool показал 340 Draw Calls и 4 overdraw-слоя на оконных стёклах. Решение: GPU Instancing для повторяющейся мебели (стулья × 24 → 1 Draw Call), замена стёкол с Standard Transparent на кастомный шейдер с Surface Type Opaque + альфа в клипе, включение Fixed Foveated Rendering уровня Medium. Итог: 72 fps стабильные, thermal throttling исчез. Наши клиенты экономят до 30% времени на профилирование благодаря автоматизированным инструментам.

Для AR-проектов отдельно прорабатываем occlusion — AR Foundation Environment Depth требует корректной настройки глубины в шейдерах, иначе виртуальные объекты «просвечивают» сквозь реальные поверхности.

Инструменты, которые используем

• Unity Profiler + Frame Debugger (GPU Usage module)
• RenderDoc (Android Vulkan/OpenGL ES)
• Meta Quest Developer Hub + OVR Metrics Tool
• XR Interaction Toolkit Profiling Guidelines
• ARM Mobile Studio (Streamline) для Adreno/Mali deep-dive

Shader Graph оптимизируем вручную — смотрим на instruction count в Preview окне, убираем лишние sample операции, переносим вычисления из Fragment в Vertex там, где допустима интерполяция.

Этапы работы над оптимизацией XR-графики

Сначала собираем билд в Release-конфигурации и снимаем baseline-метрики: fps, GPU time per frame, Draw Calls, memory footprint. Без baseline невозможно оценить результат.

Затем — аудит сцены: иерархия объектов, количество уникальных материалов, настройки освещения (статическое/динамическое), наличие real-time теней (на мобильном VR они почти всегда под запретом), LOD-группы.

После аудита готовим план оптимизации с приоритетами по impact/effort. Реализация идёт итерациями с промежуточными замерами — важно не потерять baseline и понимать, что именно дало прирост.

Финальный этап — тепловое тестирование на устройстве 20-30 минут в условиях нагрева. Thermal throttling на мобильных чипах (Snapdragon XR2) начинается раньше, чем кажется.

Стоимость рассчитывается индивидуально после аудита проекта и целевой платформы.

Сравнение методов оптимизации

Что входит в работу

• Аудит производительности на целевом устройстве с baseline-метриками
• Оптимизация шейдеров и настройка рендеринга (Single Pass Instanced, Foveated Rendering)
• Снижение Draw Calls через batching, Instancing, LOD
• Настройка освещения и теней (baked lighting, blob shadows)
• Тепловое тестирование и финальный отчёт
• Документация по использованным техникам и рекомендации по дальнейшему развитию

Частые ошибки при подготовке XR-графики

• Real-time тени на мобильном VR. Cascaded Shadow Maps с 4 каскадами на Quest — это гарантированные dropped frames. Заменяем на запечённые в Lightmap или Blob Shadow (простой проектор).
• Не отключён MSAA выше 4x. На тайловых GPU (Adreno) MSAA 8x ломает производительность. В XR Project Settings ставим 4x максимум, в сложных сценах — 2x.
• Текстуры без Mipmap. В VR объекты могут быть на разных расстояниях от камеры одновременно. Без Mipmap GPU берёт полное разрешение для далёких объектов — bandwidth растёт без причины.
• Physics Colliders сложнее необходимого. Mesh Collider на объектах интерьера там, где достаточно Box/Capsule. В VR physics tick тоже влияет на frame time.

Закажите аудит вашего XR-проекта — мы оценим его за 2 дня и предоставим план оптимизации с конкретными метриками. Single Pass Instanced эффективнее Multi Pass в два раза на одинаковой сцене, а оптимизация может сократить затраты на облачные инстансы до 2 раз. Получите консультацию, чтобы узнать, как наши решения подходят вашему проекту.

Типичные проблемы производительности игр

Проект запускается на топовых девайсах разработчика без вопросов. На mid-range Android пятилетней давности — 20 fps и перегрев через 5 минут. На iPhone 11 — стабильные 60, но на iPhone XR — просадки в тяжёлых сценах. Мы сталкиваемся с этим каждый день. Оптимизация — не «потом», а архитектурное решение с первого коммита. За 8 лет работы мы провели оптимизацию более чем для 50 игр — от гиперказуалки до AAA на консолях. Гарантируем: после нашего аудита вы получите не просто список проблем, а конкретный план с измеримыми целями и сроками. Закажите аудит производительности — оценим ваш проект за 3 дня и покажем, как снизить draw calls на 40% без потери качества.

Как профилировать производительность игр: инструменты и правила

Прежде чем оптимизировать — измерить. Оптимизация без профилирования — угадывание.

Профилируйте на целевом железе, а не в редакторе. Editor добавляет оверхед — цифры из Play Mode не репрезентативны. Разделяйте GPU и CPU bottleneck: на CPU много draw calls или тяжёлая логика, на GPU — сложные шейдеры или overdraw. Документация Unity: профилирование на устройстве — обязательный шаг для мобильных игр. Типичное время профилирования одного сценария — 5–8 часов, включая сбор метрик на 3–5 устройствах разных поколений.

Как уменьшить количество draw calls: от статического батчинга до SRP Batcher

Draw call — команда CPU к GPU «нарисуй это». Каждый вызов имеет overhead независимо от сложности геометрии. На мобильных 200–300 draw calls за кадр — граница. Цель: минимизировать их количество, объединяя геометрию с одинаковым материалом.

Static Batching объединяет неподвижные меши при сборке. Требование: флаг Static на объекте и одинаковый материал. Эффективен для статичного окружения, но увеличивает потребление памяти — объединённый меш хранится отдельно. В сценах с тысячами статичных объектов следите за памятью через Memory Profiler.

Dynamic Batching объединяет меши в рантайме с жёсткими ограничениями: меньше 900 вертексных атрибутов на меш, одинаковый материал и масштаб. На практике эффективен только для мелких объектов (партиклы, UI). В URP по умолчанию отключён — его вытеснил SRP Batcher.

SRP Batcher — не классический батчинг, а оптимизация CPU-overhead при подготовке draw calls. Вместо того чтобы каждый кадр заново загружать uniform-данные шейдера, SRP Batcher кэширует их в GPU-памяти и обновляет только изменившиеся. Draw calls остаются прежними по количеству, но каждый занимает меньше времени CPU — иногда в 2–3x по CPU-времени рендера. Требование: шейдер должен быть совместим с SRP Batcher (декларировать per-object свойства в UnityPerDraw CBUFFER). Стандартные URP Lit/Unlit шейдеры совместимы. Кастомные — проверяем в Inspector материала: SRP Batcher compatible: Yes/No. Для включения убедитесь, что в URP Asset опция SRP Batcher активна, а для кастомных шейдеров используйте макрос UNITY_INSTANCING_BUFFER и объявляйте per-object свойства в блоке CBUFFER_START(UnityPerDraw). После включения в Profiler должно снизиться время RenderLoop.Draw на CPU.

GPU Instancing — для множества копий одного меша с одним материалом (деревья, трава, NPC). Отправляет один draw call с массивом per-instance данных. Включается на материале: Enable GPU Instancing. Ограничение: все инстансы в одном batch должны иметь одинаковый материал и меш. Graphics.DrawMeshInstanced / Graphics.DrawMeshInstancedIndirect — для процедурного рендеринга без GameObject overhead.

Выбор метода зависит от сценария: Static Batching подходит для статичного окружения, SRP Batcher выигрывает в проектах с множеством уникальных материалов, GPU Instancing незаменим для массовых объектов (лес, толпа), Dynamic Batching — только для мелких и редких случаев. На практике мы комбинируем всё, начиная с профилирования.

Подробнее о технологии — на Wikipedia.

Почему оптимизация памяти критична для мобильных игр?

Мобильные платформы — жёсткие ограничения по RAM. iOS убивает приложение при превышении памяти без предупреждения (memory pressure kill). Android — аналогично, но с onLowMemory callback. Целевые бюджеты: iOS — <1 GB для современных устройств, <512 MB для поддержки iPhone 8/X; Android — <800 MB для широкой совместимости (ОС занимает 400–600 MB). Типичная экономия после нашей оптимизации — 30–50% оперативной памяти при сохранении качества.

Addressables и Asset Bundles: как не превысить бюджет

Загружать всё сразу при старте — неприемлемо для больших проектов. Addressables (надстройка над Asset Bundles) — система адресуемой асинхронной загрузки ассетов. Явная выгрузка: Addressables.ReleaseInstance / Addressables.Release. Addressables не выгружают ассеты автоматически при уничтожении объекта. Типичная ошибка: Addressables.InstantiateAsync в цикле без Release — память растёт до краша. Reference counting: ассет выгружается только когда все его handles освобождены. Архитектурный паттерн: сервис/менеджер держит handle загруженного ассета, освобождает при переходе между сценами.

Groups и Bundle Strategy: группируем ассеты по логике загрузки. Например, все ассеты одного уровня — в один bundle, шаренные (UI, шрифты) — в отдельную группу с Prevent Updates. Такая стратегия экономит до 30% памяти.

Texture Memory: откуда берётся 70% занимаемого объёма

Текстуры — основной потребитель памяти. Анализ через Memory Profiler: вкладка All Of Memory → Texture2D — сразу виден список самых тяжёлых текстур. На практике мы находим текстуры с завышенным Max Size (4096 для мобильной иконки — типичная ошибка). Меры: Mipmap для 3D-текстур (включить), для UI (выключить); Streaming Mipmaps для open world — загружает mip-уровни по мере приближения камеры. Крассовская проблема: текстуры, на которые ссылаются неиспользуемые Materials, остаются в памяти — Memory Profiler покажет reference chain. Удаляйте лишние материалы. После замены всех текстур формата RGBA32 на ASTC 6×6 на Android экономия достигает 60% без потери качества.

GC Allocations: как устранить фризы в Hot Path

C# garbage collector в Unity — stop-the-world. Если за кадр аллоцировано много heap-памяти, GC-пауза вызывает видимый фриз. Цель: нулевые аллокации в hot path (Update, FixedUpdate, рендер). Типичные источники: string конкатенация в Update (заменяем на StringBuilder), LINQ в hot path (ручные циклы с предаллоцированными списками), GetComponent<T>() каждый кадр (кэшируем в Awake/Start), boxing value types при передаче в object параметры. После профилирования с помощью Unity Profiler мы снижаем аллокации в hot path на 95% — фризы исчезают.

LOD и Culling: как отсечь лишние 40% draw calls

LOD Group — переключение на упрощённую геометрию при удалении объекта от камеры. Стандарт для 3D окружения: LOD0 (100%), LOD1 (30–50% треугольников), LOD2 (10–15%), Culled. Для мобильных порог Culled ставим агрессивнее — меньше рисуем за кадр.

Occlusion Culling — Unity не рендерит объекты за стенами. Требует запечённые occlusion данные. Для indoor сцен снижает draw calls на 20–40%.

Frustum Culling работает автоматически — объекты вне FOV камеры не рендерятся. Но draw call на проверку всё равно происходит. Для сцен с тысячами объектов — кастомный spatial partitioning (Quadtree, Octree). В одном из проектов внедрение окклюзионного калинга и LOD снизило общее количество draw calls с 2800 до 450 на Android.

Оптимизация VR: как удержать 72 FPS на Quest 3

VR — отдельный класс задач. Фреймрейт 72/90 Hz нельзя нарушать, иначе motion sickness. Дополнительно к стандартным методам: Single Pass Instanced Rendering — рендер для обоих глаз за один проход (снижает draw calls в 2 раза); Fixed Foveated Rendering (Quest) — снижение разрешения на периферии; Late Latching (Quest 3) — обновление позиции контроллера максимально поздно перед рендером; Dynamic Resolution в URP/HDRP — автоматическое снижение разрешения рендера при просадке fps. Для Quest профилируем через OVR Metrics Tool — показывает CPU/GPU time прямо в гарнитуре. После применения этих методов частота кадров на Quest 2 стабилизируется на 72 FPS даже в сценах с 1.5 млн полигонов.

Что входит в работу по оптимизации: этапы и сроки

Мы предлагаем комплексную услугу «под ключ»:

1. Профилирование на целевых устройствах — сбор метрик (FPS, draw calls, память, GC). Анализируем 5–7 основных сценариев за 3–5 рабочих дней.
2. Отчёт с приоритетами — какие проблемы критичны, какие можно отложить. Приоритеты выставляем на основе влияния на игровой опыт.
3. Внедрение оптимизаций — батчинг, LOD, Addressables, шейдеры, occlusion culling. Средний цикл внедрения — 2–4 недели.
4. Повторное профилирование — замер улучшений. Типичный прирост FPS — 30–60% на мобильных устройствах.
5. Документация — рекомендации по поддержке и дальнейшей разработке.
6. Обучение команды — как не допустить регресса. Проводим воркшопы по профилированию и оптимизации.

Средняя экономия заказчика за счёт предотвращения переделок на поздних этапах — от $15,000 до $40,000 на проекте. Получите консультацию — мы бесплатно оценим ваш проект и покажем потенциал оптимизации. Обращайтесь, чтобы узнать точные сроки и стоимость для вашего стека.