Оптимизация VR в Unreal Engine: измерения до настроек

Оптимизация VR в Unreal Engine начинается не со списка «правильных» галочек, а с измерения времени кадра на целевом устройстве. Для VR важна стабильность: один тяжёлый кадр заметен сильнее, чем в обычной игре, потому что изображение связано с поворотом головы. Если проект работает на автономной гарнитуре, проверка в редакторе на мощном ПК не заменяет запуск сборки на устройстве.

Полезная цель первой итерации проста: понять, что ограничивает сцену сейчас. Это может быть игровая логика на CPU, подготовка отрисовки, GPU, прозрачные материалы, геометрия, физика, интерфейс или нагрев устройства. Пока причина не названа, снижение качества «на всякий случай» часто портит картинку и почти не меняет результат.

Сначала соберите повторяемый замер

Выберите короткий маршрут по сцене: например, вход в помещение, взгляд на самый насыщенный участок, взаимодействие с объектом. Запускайте его одинаково после каждого изменения. В Unreal для начальной диагностики подходят stat unit и stat gpu: первый показывает общее время кадра и время основных потоков, второй помогает увидеть дорогие категории работы GPU. Документация Epic также советует смотреть фактические тайминги через инструменты платформы и композитора, потому что они учитывают накладные расходы вывода в гарнитуру.

Запишите четыре вещи: устройство, режим запуска, участок сцены и результат. Фраза «стало плавнее» не позволяет сравнить две версии. Гораздо полезнее: «на Quest в сборке, в зоне склада, после открытия панели интерфейса выросло время GPU». Тогда следующая проверка становится конкретной.

Разделите проблему на CPU и GPU

Если дорогим оказывается CPU, ищите частую логику: множество обновлений каждый кадр, тяжёлые проверки столкновений, спавн и удаление объектов, сложные Blueprint-цепочки, аудио и UI. Не нужно угадывать, какой из них виноват. Сначала оставьте в сцене один подозрительный блок, повторите маршрут и сравните замер. Подход «одна гипотеза — один тест» быстрее, чем одновременная переделка всех систем.

Если узкое место на GPU, обычно проверяют количество вызовов отрисовки, сложность материалов, прозрачность, освещение, тени, постобработку и объём геометрии, который всё ещё отправляется на рендер. Google в руководстве по VR отдельно обращает внимание на overdraw: прозрачные объекты могут заставлять GPU рисовать одни и те же пиксели несколько раз. Это не запрет на стекло, дым или интерфейс, а причина измерять их стоимость в реальной сцене.

Не рендерьте то, чего пользователь не видит

В большой сцене легко оставить активными соседние помещения, декорации за стеной или целый подуровень, хотя игрок туда не смотрит. В руководстве Epic для VR упомянуты cull volumes и управление видимостью Actors или sublevels: цель в том, чтобы скрытая часть мира не продолжала тратить бюджет без необходимости. Реальный эффект зависит от структуры уровня, поэтому после каждого шага снова проходите тот же маршрут.

Настройки Unreal — это стартовая гипотеза, а не рецепт

В старом руководстве Epic для UE 4.27 перечислены VR Template, Forward Shading, MSAA, Instanced Stereo и Mobile Multi-View для мобильных VR-опытов. Эти пункты полезны как список для проверки, но их нельзя переносить в текущий проект без оглядки на версию движка и платформу. Настройки, названия функций и их эффект меняются; часть возможностей может не подходить конкретной графике или целевому устройству.

Поэтому порядок безопаснее такой: зафиксировать версию Unreal Engine и гарнитуру, проверить документацию именно для этой связки, включить один вариант, измерить, затем решить, оставлять ли его. Если пришлось упростить свет, тени или эффекты, проверьте сцену глазами в шлеме. У VR есть отдельный критерий качества: картинка должна оставаться читаемой и не мешать ориентироваться, а не только выглядеть лучше на мониторе.

Проверьте сборку на устройстве и после нагрева

Тест на одном компьютере не отражает ограничения автономной гарнитуры. Устройства отличаются производительностью, тепловым поведением и настройками системы. Для длинного тренажёра или игры полезно повторить маршрут не только после холодного запуска, но и после непрерывной работы. Так можно обнаружить проблему, которая не видна в коротком демо.

Перед передачей сборки пройдите короткий чек-лист:

1. Есть сохранённый замер на проблемной сцене и понятный способ его повторить.
2. Известно, какой ресурс был ограничением до изменения и после него.
3. Изменения проверены в packaged build на целевой гарнитуре, а не только в редакторе.
4. В самой тяжёлой точке сцены не пропадают важные подсказки, коллизии и взаимодействия.
5. Для настройки есть запись версии движка, устройства и профиля качества.

Оптимизация VR не заканчивается одним «лёгким» пресетом. Это цикл: измерить конкретную сцену, назвать ограничение, изменить одну причину и проверить тот же пользовательский сценарий на устройстве. Так графическая настройка не разрушает механику, а техническое решение можно объяснить команде и повторить в следующей сборке.