Если коротко:
В Unreal Engine используйте VR Preview для быстрых проверок ввода и логики, а сборку на целевой гарнитуре для оценки производительности и комфорта. Записывайте модель устройства, runtime, версию движка и номер сборки для каждого прогона. Ошибку можно исправить быстрее, когда команда воспроизводит её в одинаковых условиях.
Тестирование VR-приложения в Unreal Engine нельзя свести к запуску уровня в редакторе. Нужны два контура: быстрые проверки в VR Preview и регулярный прогон на целевой гарнитуре. В первом ловят сломанный ввод, коллизии и логику сценария; во втором проверяют реальную частоту кадров, трекинг, комфорт и поведение сборки. Фиксируйте условия каждого прогона: устройство, runtime, версию UE, версию сборки и результат. Тогда ошибка перестаёт быть рассказом «у меня не работает» и становится воспроизводимым случаем.
Этот подход подходит и для небольшой VR-игры, и для учебного тренажёра. Разница будет в сценариях: в игре важны навигация и взаимодействие, в тренажёре добавляются корректность шагов, ошибки пользователя, подсказки и запись результата.
Сначала описать, что именно должен пройти человек в шлеме
Не начинайте с перечня настроек движка. Составьте короткие пользовательские маршруты: от запуска до понятного результата. Один маршрут должен занимать несколько минут и отвечать на один вопрос, например «сможет ли новичок поднять предмет и закончить упражнение».
Базовый набор для каждого маршрута:
- Запуск приложения и вход в XR-сеанс.
- Появление пользователя в безопасной стартовой точке.
- Видимость контроллеров или рук, если они нужны сценарию.
- Базовые действия: взять, отпустить, нажать, открыть меню, переместиться.
- Понятная реакция на ошибку, отмену действия и повторный запуск.
- Выход из сценария без зависания и потери сохранённых данных.
Для тренажёра не ограничивайтесь «кнопка сработала». Проверьте, что пользователь понимает следующий шаг без объяснений тестировщика; что неверное действие распознаётся; что система не засчитывает случайное касание как правильное выполнение.
VR Preview нужен для скорости, но не заменяет гарнитуру
В Unreal Engine режим VR Preview запускает предварительный просмотр на подключённом VR-устройстве. Он удобен после небольшого изменения: поправили Blueprint, сразу проверили захват объекта, коллайдер или положение UI. В обычном Play In Editor часть проблем можно не увидеть: изображение идёт в окно редактора, а не проходит весь путь до гарнитуры.
Но редактор не равен целевой сборке. На устройстве меняются загрузка, разрешение, runtime, поведение контроллеров и стоимость рендеринга. Документация Epic отдельно советует не заменять проверку на целевом железе приблизительным предпросмотром. Поэтому полезен ритм: быстрый VR Preview после изменения, затем запланированный прогон packaged build на каждой поддерживаемой конфигурации.
| Где проверять | Что это хорошо ловит | Чего недостаточно проверить |
|---|---|---|
| VR Preview | Логику взаимодействия, Blueprint, коллизии, расположение объектов | Итоговую производительность и особенности сборки |
| Standalone / packaged build на ПК | Загрузку, запуск вне редактора, параметры реального окружения | Поведение автономной мобильной гарнитуры |
| Целевая гарнитура | Ввод, трекинг, визуальный комфорт, производительность в реальном сценарии | Все другие модели и версии runtime |
Проверять сценарий, а не пустую сцену
Высокий FPS в пустом уровне не подтверждает готовность приложения. Соберите «тяжёлую минуту» проекта: пользователь перемещается, берёт объекты, открывает меню, слышит звук, срабатывают эффекты, появляется нужный объём интерфейса. Для каждого такого сценария укажите исходную точку и ожидаемый результат.
Полезная тестовая карточка может выглядеть так:
| Поле | Пример записи |
|---|---|
| Сценарий | «Взять инструмент, выполнить действие, подтвердить результат» |
| Стенд | Quest 3 через Link, ПК, выбранный OpenXR runtime |
| Сборка | Номер build и версия Unreal Engine |
| Шаги | Запуск, вход в уровень, три повтора действия, выход |
| Результат | Пройдено / ошибка / частично пройдено |
| Наблюдение | В каком месте, после чего и насколько стабильно возникает проблема |
Такой журнал помогает отличить дефект контента от проблемы стенда. Если сбой появляется только на одной конфигурации, не надо сразу переписывать логику уровня: сначала повторите его на том же устройстве и с той же версией runtime.
Смотрите на время кадра и причину, а не только на FPS
Для VR важна стабильность кадра: резкие просадки пользователь ощущает сильнее, чем на обычном мониторе. Epic рекомендует профилировать проект по ходу работы, а не пытаться срочно облегчить сцену перед релизом. В документации для быстрой первичной диагностики перечислены stat unit, stat gpu и FPS chart; внешние инструменты платформы показывают тайминги так, как их видит VR-композитор.
Не делайте вывод «виновата видеокарта», пока не разделили нагрузку:
- Game thread: gameplay-код, Blueprints, логика, AI, подготовка данных;
- render thread: подготовка команд отрисовки, в том числе количество draw calls;
- GPU: геометрия, материалы, свет, тени, прозрачность и постобработка.
stat unit пригоден, чтобы увидеть общую картину и время кадра. stat gpu помогает быстро заметить дорогие GPU-категории. Для более подробного разбора Epic указывает Unreal Insights, RenderDoc и внешние средства Oculus/SteamVR. Число FPS само по себе не объясняет, какой именно слой перегружен.
Отдельно следите за ступенчатым падением частоты. В VR-композитор может показать резкое переключение между режимами, когда приложение немного не укладывается в бюджет кадра. Это не повод «лечить» средний FPS вслепую: повторите сценарий, посмотрите времена CPU и GPU, затем меняйте один фактор и измеряйте снова. Подробный разбор оптимизации вынесен в материал «Оптимизация VR в Unreal Engine».
Минимальный регресс перед новой сборкой
Перед передачей сборки не нужен огромный список из сотен пунктов. Нужен стабильный регресс, который проходит каждый билд и со временем расширяется после найденных дефектов.
- Запустить приложение с чистого состояния на целевой гарнитуре.
- Пройти каждый критический пользовательский маршрут без подсказок разработчика.
- Проверить все варианты ввода, которые заявлены в проекте.
- Открыть меню, поставить приложение на паузу и вернуться в сценарий.
- Повторить тяжёлый фрагмент несколько раз и записать измерения.
- Проверить логи, падения, зависания и понятность сообщения об ошибке.
- Отметить версию приложения и параметры стенда в журнале.
Если проект поддерживает несколько шлемов, не называйте тест на одном устройстве проверкой совместимости со всеми. В матрице должны быть отдельные строки для гарнитуры, способа подключения и runtime. Начать достаточно с реально поддерживаемых конфигураций, а не с абстрактного списка всех устройств рынка.
Когда тест можно считать пройденным
Тест пройден не тогда, когда разработчик один раз дошёл до конца уровня. Нужны заранее определённый сценарий, повторяемый результат и запись о среде запуска. Если дефект остаётся, полезнее оставить короткое воспроизведение с логом, чем оценку «иногда тормозит».
Такой процесс сохраняет время команды. Он рано показывает несовпадение между редактором и гарнитурой, делает производительные проблемы измеряемыми и оставляет понятную историю решений для следующей версии проекта.