VR-разработка под Oculus Quest 3

Особенности Quest 3 и основы standalone VR

Что такое Quest 3 в контексте разработки

Meta Quest 3 — это standalone VR/MR-устройство: оно запускает приложения прямо на гарнитуре, без ПК и внешних базовых станций. Для разработчика это означает, что вы создаёте полноценное приложение под ограничения мобильного железа, но при этом получаете доступ к современным возможностям трекинга, контроллеров и смешанной реальности.

Ключевые особенности, которые влияют на архитектуру проекта:

Приложение работает как Android-приложение (упаковка, разрешения, сборка, установка).

Производительность и память ограничены сильнее, чем на ПК, поэтому оптимизация — не опция, а часть процесса.

Пользователь ожидает стабильный FPS и комфорт, иначе появляется укачивание.

Важна поддержка VR и MR: Quest 3 умеет цветной passthrough и сценарии смешанной реальности.

Полезные источники (официальные):

Meta Quest Developer Documentation

OpenXR (Khronos)

Standalone VR: чем отличается от PCVR

Модель запуска и распространения

Standalone VR на Quest 3 ближе к мобильной разработке:

Сборка приложения в формат, совместимый с Android (обычно APK).

Установка на устройство через магазин (в продакшене) или через инструменты разработчика (на этапе тестов).

Работа с разрешениями (например, доступ к микрофону, hand tracking, в MR-сценариях — возможности, связанные с окружающим пространством).

Для контраста, в PCVR часть вычислений делает ПК, а гарнитура часто выступает как устройство вывода и трекинга.

Производительность и стабильность кадра

В VR важнее стабильность времени кадра, чем «красивые пики» производительности. Если приложение то выдаёт целевую частоту, то начинает проседать, пользователь ощущает дискомфорт.

Типичные целевые режимы частоты обновления на гарнитурах Quest могут включать 72/80/90/120 Гц (конкретные режимы зависят от приложения и настроек/политик платформы). Практический вывод:

выбирайте реалистичную цель по FPS с учётом сцены и устройства;

не проектируйте графику «на грани» — оставляйте запас.

Тепло и батарея

У standalone-гарнитуры есть тепловой и энергетический бюджет:

чем выше нагрузка на GPU/CPU, тем сильнее нагрев;

при длительной высокой нагрузке система может снижать частоты (троттлинг), и FPS станет нестабильным;

оптимизация напрямую улучшает время работы и комфорт.

Из чего состоит VR-система на Quest 3

!Блок-схема показывает, откуда берутся данные трекинга и как они проходят через движок и VR-runtime до изображения на дисплеях

Трекинг головы

Quest 3 использует inside-out трекинг: камеры на гарнитуре отслеживают окружающее пространство, а инерциальные датчики (IMU) помогают получать быстрые и плавные данные ориентации.

Что это значит в разработке:

вы не управляете «сырыми» данными камер напрямую в большинстве проектов;

вы получаете готовые позы (position/rotation) от VR runtime (обычно через OpenXR);

качество трекинга зависит от условий: освещение, контрастные объекты, закрытие камер руками.

Контроллеры и взаимодействие

В типичном VR-приложении есть два уровня ввода:

высокоуровневые действия (телепорт, захват, меню);

низкоуровневые сигналы (кнопки, триггеры, стики, поза контроллера, жесты).

Практика: проектируйте взаимодействия через действия (actions), а не через жёсткую привязку к конкретным кнопкам. Это упрощает поддержку разных устройств и раскладок.

Hand tracking

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

Типичные особенности hand tracking:

выше требования к UX (чёткие подсказки, крупные цели, ошибки распознавания);

важно избегать интерфейсов, где требуется «пиксельная точность»;

состояние рук может теряться (перекрытие камеры, плохое освещение) — нужен graceful fallback.

Смешанная реальность (MR) и passthrough

Quest 3 поддерживает цветной passthrough, что открывает сценарии MR: виртуальные объекты накладываются на реальный мир.

Для разработчика это добавляет новые вопросы:

безопасность: нельзя заставлять пользователя резко двигаться вслепую, если MR отключился;

контраст и читаемость: виртуальные элементы должны быть читаемы на реальном фоне;

масштаб и привязка: объекты должны выглядеть устойчиво и правильно «стоять» в пространстве.

Рекомендация по дизайну: если у вас VR-игра, начните с чистого VR (полностью виртуальная сцена), а MR добавляйте как режим или отдельные элементы, когда базовая производительность и взаимодействие уже стабильны.

OpenXR и runtime: базовая идея

OpenXR — это открытый стандарт API для VR/AR, который позволяет приложению взаимодействовать с устройством через единый слой. В реальности вы работаете с runtime, который:

принимает данные трекинга;

управляет композиции кадра (compositing);

предоставляет приложению интерфейсы ввода/вывода.

Почему это важно понимать с самого начала:

ваш проект должен быть «дружелюбным к runtime», а не пытаться «ломать» VR-пайплайн;

многие вещи (например, как именно кадр попадает на дисплей) в VR делаются не напрямую движком, а в связке движок + runtime.

Источник:

OpenXR (Khronos)

Производственные ограничения Quest 3: что учитывать с первого дня

Полигоны, материалы, пост-эффекты

Главное правило standalone VR: сцена должна быть проще, чем вам хочется.

Что обычно «дорого» на мобильном GPU:

большое количество динамических источников света и теней;

тяжёлые шейдеры (сложные BRDF, множество текстурных выборок);

прозрачности и сложный UI в мире (особенно если много перекрывающихся полупрозрачных элементов);

пост-эффекты, которые требуют нескольких проходов (например, некоторые виды blur).

Стратегия: сначала сделайте целевой FPS на простой графике, затем добавляйте красоту по одному элементу, постоянно проверяя стабильность.

Разрешение, FFR и «куда уходит FPS»

В VR рендеринг обычно дороже, чем в обычной 3D-игре:

нужно рисовать картинку для каждого глаза;

высокие требования к задержке;

часто требуется более высокое внутреннее разрешение для читаемости.

Оптимизационные подходы, которые вы будете встречать в экосистеме Quest:

снижение внутреннего разрешения рендера (динамическое или фиксированное);

упрощение шейдеров и геометрии;

фиксированное фовеированное рендеринг (FFR) как концепция: меньше качество на периферии ради скорости.

Важно: не используйте оптимизации «вслепую». Всегда измеряйте (профилирование), иначе можно потратить время и ухудшить качество без выигрыша.

Память и загрузки

В standalone-проектах часто всплывают проблемы:

большие текстуры и много уникальных материалов;

долгие загрузки сцен;

фризы при подгрузке ресурсов.

Практический вывод: планируйте ассеты и сцены так, чтобы вы могли контролировать:

количество уникальных материалов;

размер текстур;

потоковую подгрузку (когда дойдём до продвинутых тем).

Комфорт пользователя: базовые принципы

Комфорт — это техническое требование, а не «дизайнерская придирка».

Локомоция

Два самых распространённых подхода:

телепорт (обычно комфортнее, но может снижать динамику);

плавное перемещение (больше свободы, но выше риск укачивания).

Хорошая практика для первых прототипов:

начать с телепорта;

добавить плавное перемещение как опцию;

предусмотреть «comfort settings» (поворот рывками, виньетка при движении, ограничение скорости).

UI и масштаб

В VR интерфейс — это 3D-объекты и расстояния, а не пиксели на экране.

Базовые советы:

размещайте важный UI в комфортной зоне обзора (не слишком близко к глазам и не на периферии);

делайте интерактивные элементы крупнее, чем в desktop/mobile;

избегайте текста, который приходится читать на очень мелком размере.

Инструменты разработки: что вы будете использовать дальше

В этом курсе мы будем постоянно возвращаться к выбору стека и его настройке. На уровне понятий важно понимать следующие компоненты:

движок (обычно Unity или Unreal);

VR API (часто OpenXR);

SDK платформы (интеграции Quest-экосистемы);

Android-сборка, подпись, установка, логи.

Ссылки для ориентира:

Unity XR Plugin Management

Android Manifest overview

Meta Quest Developer Documentation

Типовой цикл разработки standalone VR

!Диаграмма показывает, что VR-разработка — это итерации с постоянным тестированием в гарнитуре

Почему нельзя «доделать на ПК, а потом проверить один раз»:

многие проблемы видны только в шлеме: масштаб, комфорт, качество трекинга, читаемость;

производительность на ПК не отражает standalone;

MR-поведение (passthrough, освещение) тоже проявляется только на устройстве.

Итоги: что нужно запомнить перед следующими темами

Quest 3 — standalone устройство: думайте как мобильный разработчик, но с VR-требованиями.

Стабильный FPS и комфорт важнее визуальных эффектов.

Архитектура ввода должна быть ориентирована на действия (actions), чтобы поддерживать контроллеры и руки.

MR/passthrough расширяет возможности, но добавляет требования к безопасности и читаемости.

Разработка должна быть итеративной: прототип → измерение → оптимизация → тест в шлеме.

В следующей статье логично перейти к настройке окружения разработки и первому проекту под Quest 3 (движок, OpenXR, сборка и установка на устройство).

Настройка среды: Unity/Unreal, Android и Meta XR SDK

Зачем эта настройка и как она связана с предыдущей темой

В прошлой статье мы зафиксировали ключевую реальность Quest 3: это standalone устройство, то есть вы собираете и запускаете приложение на гарнитуре, в формате Android-приложения. Отсюда следует практическая цель этой темы: настроить окружение так, чтобы вы могли быстро проходить цикл собрал → установил → посмотрел в шлеме → снял логи → поправил.

Ниже — два рабочих стека (Unity и Unreal), общие Android-компоненты и интеграция Meta XR SDK. К концу статьи у вас должен быть готовый минимальный проект, который собирается в APK и устанавливается на Quest 3.

!Диаграмма итерационного цикла сборки, установки и отладки на Quest 3

Выбор движка: Unity или Unreal

Оба движка подходят для Quest 3. Выбор стоит делать от задач команды и опыта.

Быстрое сравнение

| Критерий | Unity | Unreal Engine | |---|---|---| | Входной порог для прототипов | Обычно ниже | Обычно выше | | Типичный пайплайн VR-шаблонов | XR Interaction Toolkit + OpenXR | VR Template + OpenXR | | Гибкость UI и быстрых итераций | Часто удобнее | Тяжелее, но мощно | | Графический потенциал | Высокий, зависит от шейдеров/пайплайна | Очень высокий, но нужно следить за бюджетом Quest | | Интеграции Meta | Meta XR All-in-One SDK (Unity) | Meta XR Plugin/интеграции (Unreal) |

Рекомендация для курса: если вы делаете первый проект под Quest 3, чаще выбирают Unity из‑за скорости итераций и количества учебных материалов. Если вы уже уверенно работаете в Unreal — оставайтесь на нём, принципы Android-сборки и OpenXR всё равно будут теми же.

Общая база: что нужно для разработки под Quest 3

Quest 3 запускает Android-приложения, поэтому вам понадобятся компоненты Android-инструментария.

Термины, чтобы не путаться

SDK (Software Development Kit): набор инструментов и библиотек для сборки приложения.

JDK (Java Development Kit): нужен для части Android-инструментов и сборки.

NDK (Native Development Kit): нужен для нативного кода (C/C++) и части движков/плагинов.

ADB (Android Debug Bridge): утилита для установки APK, доступа к логам и отладки устройства.

OpenXR: стандартный API-слой для VR/AR, через который движок получает позы и ввод и отдаёт кадры runtime.

Подготовка Quest 3 к разработке

Чтобы устанавливать сборки не через магазин, гарнитуру нужно перевести в режим разработчика.

Шаги

Создайте (или используйте существующий) аккаунт Meta и включите режим разработчика для устройства в приложении Meta на телефоне.

На Quest 3 откройте настройки и убедитесь, что разрешена отладка (обычно это связано с подтверждением доверия к ПК при первом подключении).

Подключите Quest 3 к ПК по USB.

Проверьте ADB-связь.

Полезные официальные ссылки:

Meta Quest Developer Documentation

Android Debug Bridge (adb)

Проверка ADB (универсально для Unity и Unreal)

После установки Android SDK Platform Tools выполните в терминале:

Вы должны увидеть устройство в списке. Если устройство отображается как unauthorized, наденьте шлем и подтвердите доверие к компьютеру.

Android-инструменты: установка и типичные ошибки

Что ставить

Android Studio (как удобный способ поставить SDK/Platform Tools)

Android SDK Platform Tools (содержит adb)

Официальные ссылки:

Android Studio

Типичные проблемы

adb не находится в системе

- Решение: добавьте путь к Platform Tools в переменную окружения PATH или запускайте adb из папки Platform Tools.

Несовместимые версии SDK/NDK/JDK

- Решение: придерживайтесь рекомендаций конкретного движка/версии и не смешивайте случайные NDK.

Установка APK проходит, но приложение не запускается

- Решение: смотрите logcat и убеждайтесь, что сборка ARM64 и что разрешения/манифест корректны.

Стек Unity: установка и настройка под Quest 3

Что поставить

Unity Hub

Unity Editor (LTS-версия обычно предпочтительнее для продакшена)

Модуль Android Build Support

- Android SDK & NDK Tools - OpenJDK

Ссылки:

Unity Hub

Unity XR Plugin Management

Создание проекта и включение OpenXR

Создайте 3D-проект.

Установите пакет XR Plugin Management (если он не включён).

Откройте настройки XR Plugin Management и включите OpenXR для Android.

В настройках OpenXR включите необходимые interaction profiles для контроллеров.

Важно: идея OpenXR из прошлой статьи здесь становится практикой — мы стараемся опираться на стандартный VR-слой, чтобы ввод и трекинг работали предсказуемо через runtime.

XR Interaction Toolkit (для быстрого прототипа)

Если вам нужно быстро получить телепорт/лучевой указатель/захват, используйте XR Interaction Toolkit.

Ссылка:

XR Interaction Toolkit (Unity Manual)

Meta XR SDK (Unity)

Для Quest-проектов часто используют Meta XR All-in-One SDK, потому что он даёт доступ к платформенным возможностям (например, hand tracking, специфичные оптимизации/утилиты, MR-фичи) поверх базового OpenXR.

Официальная точка входа в документацию:

Meta XR All-in-One SDK (Unity) documentation

Практический подход:

Импортируйте Meta XR SDK в проект согласно официальной инструкции.

Включайте фичи постепенно.

- Сначала: базовый VR (голова + контроллеры) и стабильная сборка. - Затем: руки (hand tracking). - Затем: MR/passthrough.

Это напрямую следует из ограничений standalone VR из прошлой статьи: сначала стабильность и комфорт, потом расширение возможностей.

Ключевые настройки сборки (Unity)

В Build Settings и Player Settings проверьте:

Целевая платформа: Android

Архитектура: ARM64

Графический API: тестируйте Vulkan и OpenGL ES, но не меняйте без измерений

Минимизация лишней нагрузки

- отключайте тяжёлые пост-эффекты в первых прототипах - держите простую сцену, пока не подтвердите стабильный FPS

Стек Unreal Engine: установка и настройка под Quest 3

Что поставить

Epic Games Launcher

Unreal Engine

Android toolchain (набор SDK/NDK/JDK, который рекомендует ваша версия UE)

Официальная документация по Android-настройке в UE:

Android Development Requirements (Unreal Engine Documentation)

OpenXR в Unreal

В Unreal логика похожа: вы включаете OpenXR-плагины и используете шаблоны/компоненты для VR.

Документация по OpenXR в UE:

OpenXR in Unreal Engine

Meta XR интеграции для Unreal

Meta поддерживает наборы инструментов для Unreal, но конкретный способ установки зависит от версии движка и выбранного пути (через плагины/репозитории/документацию Meta).

Безопасная отправная точка:

Meta Quest Developer Documentation

Рекомендация: сначала добейтесь сборки чистого OpenXR-проекта под Android, а затем добавляйте Meta-специфичные плагины. Так проще локализовать проблему, если сборка перестанет запускаться.

Установка APK на Quest 3 и базовая отладка

Установка

Если вы собрали APK, установите его командой:

Ключ -r означает переустановку поверх предыдущей версии.

Логи (самое важное при первых запусках)

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

Практика работы с логами:

Запускайте adb logcat, затем стартуйте приложение в шлеме.

Ищите Exception, Fatal, ошибки загрузки библиотек, сообщения о разрешениях.

Если в логах видно, что приложение упирается в память или шейдеры, вернитесь к упрощению сцены и настройкам качества.

Официальная справка по logcat:

Logcat command-line tool

Минимальный чек-лист “среда готова”

Вы можете считать окружение настроенным, если выполняются все пункты:

ПК видит гарнитуру через adb devices

Проект в Unity или Unreal собирается под Android без ошибок

APK устанавливается на Quest 3

Приложение запускается в шлеме и показывает хотя бы простую сцену

Вы умеете открывать adb logcat и находить причину падения

Итоги

Настройка под Quest 3 — это настройка Android-сборки плюс VR-стек (обычно OpenXR) и, при необходимости, Meta XR SDK.

Начинайте с минимальной конфигурации: стабильная сборка и запуск на устройстве важнее, чем сразу включить все XR-фичи.

ADB и logcat — обязательные инструменты, потому что standalone-ошибки часто проявляются только на гарнитуре.

В следующем логичном шаге курса — сделать первый VR-прототип взаимодействия (камера/контроллеры, телепорт или простой grab), постоянно проверяя результат в шлеме.

XR-проект: сцена, камера, трекинг и рендеринг

Как эта тема связана с предыдущими статьями

В предыдущих статьях вы:

разобрались, почему Quest 3 — это standalone VR и почему важны комфорт и стабильный FPS;

настроили окружение (Android-инструменты, OpenXR, Meta XR SDK) так, чтобы собирать APK и запускать на гарнитуре.

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

!Схема, показывающая правильное разделение трекинга и перемещения игрока

Ключевые понятия

Что такое XR-проект

XR-проект — это приложение, где:

положение и поворот головы пользователя приходят из VR runtime (обычно через OpenXR);

контроллеры тоже трекаются runtime и дают позы и кнопки;

движок рендерит стерео-картинку (для двух глаз) и отдаёт её runtime.

Что такое VR runtime

VR runtime — это системный слой на устройстве (на Quest — runtime от Meta), который:

объединяет данные датчиков (камеры, IMU) в стабильные позы;

управляет композицией кадра и выводом на дисплеи;

предоставляет API (например, OpenXR) вашему приложению.

С точки зрения кода это означает простое правило:

вы не вычисляете трекинг сами;

вы не двигаете камеру напрямую как обычную игровую камеру.

Ориентир по OpenXR:

OpenXR (Khronos)

Сцена и система координат: базовые правила

Единицы измерения и масштаб мира

В VR масштаб — часть комфорта. Ошиблись с масштабом, и мир ощущается как игрушечный или гигантский.

Практическое правило для Unity:

1 единица Unity примерно равна 1 метру.

Практическое правило для Unreal:

1 Unreal Unit равен 1 сантиметру.

Следствия:

держите реальную высоту глаз (например, около 1.6–1.8 м для стоящего игрока) через корректный tracking origin и настройки XR-рига;

не масштабируйте весь мир «на глаз» без причины.

Пол и гравитация

Даже если у вас нет физики, вам нужно договориться, где «пол».

В VR-сценах обычно ось Y направлена вверх.

Пол — это условная плоскость, относительно которой вы выбираете тип трекинга: от пола или от устройства.

Камера и риг: как устроен трекинг

Почему нельзя просто двигать Camera

В обычной 3D-игре камера — это объект, которым вы управляете.

В VR:

runtime постоянно обновляет позу HMD (шлема);

камера должна следовать этой позе;

если вы начнёте дополнительно двигать саму камеру, вы получите конфликт: «движок двигает» + «runtime двигает».

Правильная архитектура:

камера и контроллеры живут внутри XR-рига и получают локальные позы от трекинга;

перемещение игрока по миру делается перемещением корня (XR Origin / Pawn root), а не камеры.

Tracking space и world space

Удобно разделять два пространства:

tracking space — локальное пространство, где runtime выдаёт позы головы и рук;

world space — пространство вашей сцены (уровня).

Связка выглядит так:

HMD поза применяется к Camera локально внутри рига;

позиция игрока в мире задаётся корневым объектом рига.

Unity: минимальный XR-каркас для Quest 3

Ниже описан практический путь, который хорошо стыкуется с тем, что вы настроили в статье про Unity/OpenXR/Android.

Пакеты и плагины

В Unity вам обычно нужны:

XR Plugin Management

OpenXR Plugin

XR Interaction Toolkit (для быстрого прототипа взаимодействий)

Официальные страницы Unity:

XR Plugin Management (Unity Manual)

OpenXR Plugin (Unity Package)

XR Interaction Toolkit (Unity Package)

XR Origin

XR Origin (или аналогичный объект) — это корень игрока.

Типичный состав:

XR Origin (корень)

Camera Offset (смещение под высоту/режим трекинга)

Main Camera (HMD)

Left Controller

Right Controller

Основная идея:

XR Origin перемещается по миру (телепорт, ходьба, скрипт);

Main Camera получает позу головы из OpenXR.

Tracking Origin: от пола или от устройства

Обычно встречаются два режима:

Floor (от пола)

Device (от устройства)

Практический смысл:

Floor: удобно для стоячих/комнатных сцен, пол в сцене совпадает с реальным полом.

Device: удобно, когда вы сами задаёте высоту (например, сидячий режим), или когда приложение не опирается на реальный пол.

Если у пользователя «камера в полу» или «слишком высоко», чаще всего причина в несоответствии:

выбранного tracking origin;

высоты Camera Offset;

ожиданий вашей сцены (где вы считаете пол).

Перемещение игрока

Запомните базовое правило:

двигаете игрока — двигаете XR Origin;

не двигаете Main Camera напрямую.

Типовые варианты перемещения:

телепорт (комфортнее)

плавное перемещение (нужны comfort-настройки)

XR Interaction Toolkit даёт готовые компоненты для обоих вариантов, что полезно для первых прототипов.

Recenter и «сброс ориентации»

Recenter — это действие, которое помогает пользователю заново «выставить» направление вперёд и/или позицию относительно вашего приложения.

Практика:

поддерживайте recenter как часть UX (кнопка в меню, подсказка при старте);

не делайте recenter неожиданно без запроса пользователя.

Unreal Engine: минимальный XR-каркас

В Unreal логика похожа, но термины другие.

Типовая структура:

Pawn или Character как объект игрока

Camera Component, которой управляет HMD

Motion Controller Components для рук

OpenXR включается через плагины, а базовый старт часто делают через VR Template.

Официальные страницы:

OpenXR in Unreal Engine

Главное правило остаётся тем же:

перемещайте корень Pawn/Character;

не пытайтесь «перебить» трекинг камеры ручным управлением.

Рендеринг в VR на Quest 3: что важно с первого прототипа

Почему VR рендеринг дороже

Даже простая сцена в VR обычно тяжелее, чем на плоском экране, потому что:

рендер идёт для двух глаз;

выше требования к задержке;

часто нужно повышенное внутреннее разрешение ради читаемости.

Поэтому базовые рендер-настройки лучше выставить правильно до того, как вы начнёте добавлять контент.

Render pipeline в Unity

Практичный выбор для Quest-проектов в Unity — URP, потому что он:

лучше контролируется по качеству и производительности;

подходит для мобильного железа;

даёт удобные настройки MSAA и освещения.

Официальная документация:

Universal Render Pipeline overview (Unity Manual)

Антиалиасинг и читаемость

В VR «лесенки» и мерцание заметнее. Частая базовая рекомендация для мобильного VR:

использовать MSAA (если ваш пайплайн и сцена это позволяют).

Важно:

пост-эффекты типа тяжёлого blur, сложной цветокоррекции или многопроходных эффектов добавляйте только после того, как подтвердили стабильную частоту кадров.

Однопроходный стерео-рендеринг

Идея оптимизации: рисовать для двух глаз эффективнее, чем два независимых прохода.

В разных движках и настройках это может называться по-разному, но смысл один:

меньше накладных расходов на рендер;

выше шанс удержать стабильный FPS.

Foveated rendering

Foveated rendering — подход, где качество изображения снижается на периферии, чтобы сэкономить ресурсы.

Практический вывод для Quest:

это один из инструментов производительности, но его нужно включать и настраивать осознанно, проверяя, не стало ли изображение неприятным.

Документация Meta для Unity — точка входа, где дальше вы найдёте разделы по производительности и XR-фичам:

Meta Quest Unity Documentation

Базовый «производственный» чек-лист сцены

Если первый прототип уже подтормаживает, чаще всего виноваты не «сложные алгоритмы», а сцена.

Проверьте базовые вещи:

минимум динамических источников света

минимум теней или очень аккуратные тени

простые материалы и шейдеры

мало прозрачностей (особенно перекрывающихся)

без тяжёлых пост-эффектов на старте

Как проверить, что трекинг и рендеринг настроены правильно

Признаки корректного XR-рига

при повороте головы мир стоит стабильно, без дрожания и «подплывания»

контроллеры совпадают с руками пользователя по положению и ориентации

высота камеры ощущается естественно относительно пола

при телепорте перемещается «вы как игрок», а не камера отдельно от тела

Типовые симптомы проблем

| Симптом | Частая причина | Что проверить | |---|---|---| | Камера «в полу» | неверный tracking origin или offset | Floor/Device, Camera Offset | | Камера «улетает» при движении | двигаете Camera вместо XR Origin | скрипты перемещения | | Дрожит изображение | перегруз по CPU/GPU или конфликт обновления | упрощение сцены, XR настройки | | Плохая читаемость | низкое разрешение/неудачный AA | настройки качества, MSAA |

Обязательная практика

проверяйте изменения в шлеме как можно чаще

если приложение упало на устройстве, смотрите логи через adb logcat

Официальная справка по logcat:

Logcat command-line tool

Итоги

XR-риг — это разделение ответственности: runtime трекает голову и руки, а вы перемещаете корень игрока.

Tracking origin определяет, как ваше приложение трактует «пол» и высоту пользователя.

В VR нельзя «как в обычной игре» управлять камерой: перемещайте XR Origin/Pawn root.

Рендер в VR дороже: начинайте с простых сцен и базовых оптимизаций (разумный пайплайн, AA, минимум тяжёлых эффектов).

Проверка в шлеме и работа с логами — часть ежедневного цикла разработки.

Взаимодействие в VR: контроллеры, hand tracking и UI

Связь с предыдущими темами курса

Ранее вы настроили среду (Android, OpenXR, Meta XR SDK) и собрали правильный XR-каркас проекта: XR-риг, трекинг головы и рук, базовые рендер-настройки. Теперь следующий обязательный слой — взаимодействие: как пользователь выбирает объекты, нажимает UI, берёт предметы, получает обратную связь и что происходит, когда вместо контроллеров используются руки.

Ключевая идея: в Quest 3 вы строите взаимодействие поверх данных, которые выдаёт runtime (обычно через OpenXR), и делаете это так, чтобы оно было:

стабильным (не «дрожит», не ломается при потере трекинга)

предсказуемым (одинаково работает в разных сценах)

расширяемым (контроллеры сейчас, руки и MR позже)

!Диаграмма, показывающая где заканчивается трекинг runtime и где начинается логика взаимодействия в приложении

Термины, которые понадобятся

Pose (поза) — позиция и поворот устройства (контроллера или руки) в пространстве.

Action (действие) — абстрактная команда вроде Grab, Teleport, UI Click, не привязанная жёстко к конкретной кнопке.

Ray interaction (лучевое взаимодействие) — выбор объектов и UI лучом (как указка).

Direct interaction (прямое взаимодействие) — касание/захват «рукой» вблизи, без луча.

Haptics (тактильная отдача) — вибрация контроллеров как обратная связь.

Hand tracking — трекинг рук без контроллеров: поза ладони/пальцев и жесты распознаются системой.

Почему взаимодействие нужно проектировать через actions, а не «кнопки»

На практике кнопки и раскладки могут различаться, а ввод может переключаться между контроллерами и руками. Поэтому архитектурно выгодно описывать намерение пользователя, а не конкретный физический сигнал.

Что это даёт:

проще сделать переназначение и доступность (accessibility)

проще поддерживать разные устройства и режимы

проще добавить hand tracking без переписывания всей логики

Ориентир по стандарту и концепции действий: OpenXR

Контроллеры Quest: базовый набор взаимодействий

Что вы получаете от runtime

В типичном VR-проекте движок через OpenXR получает:

позу левого и правого контроллера

состояние кнопок/триггеров/стика

события трекинга (например, контроллер временно не трекается)

Важно: вы обычно не «угадываете» положение контроллера сами. Вы используете то, что возвращает runtime.

Виды взаимодействия, которые стоит заложить сразу

#### Луч (дальние взаимодействия)

Луч полезен для:

выбора объектов на расстоянии

взаимодействия с UI в мире

телепорта

Типовые UX-правила для луча:

показывайте видимый луч и понятный курсор на поверхности

делайте подсветку объекта до клика

делайте явное состояние hover и select

#### Прямое взаимодействие (вблизи)

Прямой захват и касание нужны для:

поднятия предметов

кнопок, рычагов, ручек

реалистичных манипуляций

Типовые UX-правила:

зона захвата должна быть «щедрой» по размеру

объект должен давать обратную связь: подсветка, звук, хаптика

физика должна быть стабильной (без рывков и «взрывов»)

!Иллюстрация различий ray и direct взаимодействий

Обратная связь: что обязательно, а что опционально

Без обратной связи VR быстро становится «непонятным»: пользователь не уверен, сработало ли действие.

Минимальный набор:

визуальная обратная связь (подсветка, изменение состояния)

звуковая обратная связь (клик, подтверждение)

тактильная отдача на контроллере (вибрация при наведении/захвате)

В Unity концептуально удобно держать это в одном месте: когда объект переходит в состояние hover или select, вы централизованно вызываете визуал, звук и haptics.

Документация Unity по XR Interaction Toolkit (как одной из частых основ для прототипа): XR Interaction Toolkit

Hand tracking: особенности и отличия от контроллеров

Что меняется, когда пользователь без контроллеров

Hand tracking почти всегда усложняет UX:

меньше «кнопок», больше жестов

выше вероятность потери трекинга (закрытие камер, плохой свет)

ниже точность «указания» по сравнению с лучом контроллера

Поэтому hand tracking стоит рассматривать как отдельный режим ввода, для которого вы:

упрощаете требования к точности

делаете крупнее интерактивные цели

добавляете явные подсказки, что система «видит руки»

Технический ориентир по стандартному API трекинга рук: OpenXR XR_EXT_hand_tracking

Дизайн жестов: избегайте «магии»

Если вы делаете жесты, они должны быть:

простыми и естественными (pinch, grab)

хорошо различимыми системой

обучаемыми (пользователь должен понять за 5–10 секунд)

Плохой признак: действие срабатывает «иногда» и пользователь не понимает почему.

Стратегия отказоустойчивости (fallback)

В Quest-сценариях важно заранее решить, что произойдёт, если трекинг рук пропал.

Рабочая стратегия:

Приоритетный режим: контроллеры, если они активны и трекаются.

Режим рук: если контроллеры не используются и руки распознаны.

Безопасный режим: если трекинг потерян, показывать подсказку и отключать критичные действия.

В UX это обычно выглядит так:

индикатор состояния рук (видим/не видим)

мягкое отключение интеракций при потере трекинга

понятная инструкция «верните руки в поле зрения»

!Схема fallback-логики между контроллерами и руками

UI в VR: как сделать, чтобы было удобно и не раздражало

Главное отличие VR UI от обычного

В VR UI — это объект в 3D-пространстве, а не «плоский слой экрана». Из этого следуют практические правила:

размещайте UI на комфортной дистанции и не слишком близко к глазам

не перегружайте мелким текстом

используйте крупные кнопки и большие зоны нажатия

Два основных подхода к VR UI

#### World-space UI (панели в мире)

Подходит для:

меню, терминалов, панелей настроек

подсказок в окружении

Плюсы:

естественно в VR

хорошо сочетается с лучом и прямым нажатием

Риски:

если панель «приклеена» к лицу, это может быть некомфортно

если панель далеко, ухудшается читаемость

#### Diegetic UI (UI как часть мира)

Это когда интерфейс встроен в объект: кнопки на устройстве, экран монитора, рычаги.

Плюсы:

высокая «присутствие» и правдоподобие

Риски:

требует хорошего уровня дизайна и тестирования

Луч для UI и «клик»

Для UI на расстоянии луч — самый предсказуемый паттерн:

наведение (hover)

подтверждение (click/select)

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

В Unity это обычно делается через связку системы ввода и компонентов UI, а в качестве основы часто используют XR Interaction Toolkit и стандартные UI-компоненты Unity.

Справка Unity по UI-системе: Unity UI Manual

UI и производительность

UI в VR тоже может стоить дорого, особенно если:

много полупрозрачных элементов, которые перекрывают друг друга

вы используете сложные шейдеры/эффекты на UI

UI занимает большую часть экрана постоянно

Практика для Quest 3:

начинайте с простого визуала

избегайте «стеклянных» панелей с множеством прозрачных слоёв

профилируйте на устройстве, а не в редакторе

Типовые ошибки взаимодействия и как их диагностировать

Ошибка: «Я двигаю камеру, чтобы приблизить руку к объекту»

Это почти всегда приводит к конфликтам с трекингом.

Правильный подход:

камеру и контроллеры не двигают напрямую

двигают корень игрока (XR Origin / Pawn root), а руки остаются в локальном трекинге

Эта логика продолжает фундамент из статьи про XR-риг.

Ошибка: «Граб срабатывает не всегда»

Частые причины:

слишком маленькие коллайдеры у объекта

объект не настроен как интерактивный (нет нужных компонентов/слоёв)

конфликтуют два интерактора (например, луч и прямой захват одновременно)

Практика:

сделайте явную визуализацию состояния hover/selected

временно упростите сцену до 1 объекта и 1 типа интеракции

Ошибка: «В UI можно промахнуться, приходится целиться пиксельно»

Решения:

увеличьте размеры кнопок и зоны нажатия

добавьте магнит (snap) на ближайший элемент

используйте задержку подтверждения или явное нажатие вместо автоактивации

Рекомендованный минимальный набор для первого прототипа

Если ваша цель — быстро получить рабочий вертикальный срез под Quest 3, держите минимальный объём:

Два режима интеракции: луч для дальнего + прямой захват вблизи.

Единый набор actions: Grab, UI Click, Teleport.

Обратная связь на каждом действии: визуал + звук + haptics.

Простое world-space меню с большими кнопками.

План добавления рук: отдельный режим, крупные цели, fallback при потере трекинга.

Итоги

Взаимодействие в VR выгоднее строить через actions, а не через жёсткие «кнопки».

Закладывайте два базовых паттерна: ray для дистанции и direct для ближнего взаимодействия.

Обратная связь — обязательна: визуал, звук и (для контроллеров) haptics.

Hand tracking требует упрощения UX и обязательного fallback-поведения при потере трекинга.

VR UI проектируется как 3D-объект: крупнее элементы, понятное наведение, аккуратность с прозрачностями и производительностью.

Дальше по логике курса обычно переходят к локомоции и комфорту в деталях (телепорт, smooth locomotion, повороты, comfort settings) и к системной оптимизации под standalone-устройство.

Локомоция и комфорт: перемещение, телепорт, sickness

Как эта тема связана с предыдущими статьями

В прошлых темах курса вы:

настроили сборку под Quest 3 (Android + OpenXR + Meta XR SDK);

собрали правильный XR-каркас (XR Origin/Pawn root, трекинг головы и рук, базовый рендеринг);

заложили взаимодействие (луч, прямой захват, UI, hand tracking и fallback).

Теперь логично перейти к локомоции — способам перемещения игрока в VR. Это одна из самых практически важных частей VR-разработки: локомоция напрямую влияет на комфорт, риск укачивания и оценки приложения.

Ключевой принцип, который связывает тему с XR-ригом:

вы перемещаете корень игрока (XR Origin / Pawn root), а не HMD-камеру напрямую;

вы выбираете такой способ движения, который не провоцирует конфликт между тем, что видит глаз, и тем, что чувствует вестибулярный аппарат.

!Как локомоция должна двигать корень игрока, а не камеру

Термины и базовые понятия

Локомоция — любой способ перемещения пользователя по виртуальному миру.

Телепорт — перемещение на новую точку мгновенно (часто с затемнением экрана или «прыжком» без промежуточного движения).

Плавное перемещение — постоянное движение с управлением (например, стик на контроллере) и промежуточными кадрами.

Поворот рывками (snap turn) — поворот на фиксированный угол (например, 30° или 45°) по нажатию/сдвигу.

Плавный поворот (smooth turn) — непрерывный поворот с заданной скоростью.

VR sickness (укачивание) — дискомфорт (тошнота, головокружение, потливость), который возникает, когда ощущения движения в VR расходятся с ощущениями тела.

Полезный обзор принципов комфорта (общий, не завязанный на конкретный движок):

Google VR Comfort

Почему укачивает: понятная модель причины

Самая полезная для разработчика модель — конфликт сигналов:

глаза видят, что вы ускоряетесь/поворачиваете/едете;

тело и вестибулярный аппарат не подтверждают эти ускорения (вы физически стоите на месте).

С практической точки зрения особенно «опасны»:

ускорение и торможение камеры при плавной локомоции;

плавные вращения (smooth turn) без физического поворота телом;

движение вбок и назад (strafe), когда голова смотрит вперёд;

нестабильный FPS и рывки времени кадра, которые воспринимаются как микроподёргивания мира.

Важно связать это с standalone-реальностью Quest 3 из первой статьи: даже хороший дизайн локомоции может быть испорчен просадками производительности.

Стратегия выбора локомоции для проекта

На практике удобно мыслить не «один способ перемещения», а набор режимов + настройки комфорта.

Базовая стратегия для большинства приложений

Сделайте телепорт как режим по умолчанию.

Добавьте плавное перемещение как опцию (в настройках).

Добавьте snap turn как опцию по умолчанию.

Плавный поворот — опционально, и обычно не по умолчанию.

Почему так:

телепорт и snap turn чаще всего дают наименьший процент укачивания;

опытные пользователи часто хотят smooth locomotion, но им важна возможность выбрать.

Быстрый чек-лист «правильного поведения»

Локомоция двигает XR Origin / Pawn root.

Камера HMD продолжает получать позу только от runtime (OpenXR).

Есть понятная обратная связь: куда вы телепортируетесь, как вы поворачиваетесь, какое состояние режима.

Телепорт: самый безопасный базовый паттерн

Виды телепорта

Point-and-teleport: луч указывает точку на поверхности.

Arc teleport: дуга показывает траекторию (удобно для «на пол», на возвышения).

Blink: телепорт с кратким затемнением (уменьшает дискомфорт от мгновенной смены картинки).

!Как выглядит arc-teleport и как подсказать допустимые/недопустимые зоны

Правила UX для телепорта

Показывайте маркер точки приземления и ориентацию «куда будете смотреть после телепорта».

Ограничивайте телепорт на поверхности/зоны, где это логично (например, пол, навигационная сетка).

Добавляйте небольшой fade-out/fade-in (blink), если сцена «жёсткая» по контрасту или пользователь часто телепортируется.

Типовая ошибка

Телепорт двигает камеру, а не корень игрока.

Симптомы:

руки «отрываются» от тела;

появляется ощущение, что мир «прыгает», а вы — нет.

Исправление:

перемещайте XR Origin / Pawn root, а камера остаётся внутри рига под управлением трекинга.

Плавное перемещение (smooth locomotion): риск выше, но иногда необходимо

Плавная локомоция нужна, когда:

жанр требует точного позиционирования и скорости (экшен, шутер, спортивные игры);

телепорт ломает темп или механику;

проект рассчитан на аудиторию с VR-опытом.

Что делает smooth locomotion более комфортной

Постоянная скорость без резких ускорений: избегайте «рывка» при старте и сильного торможения.

Ограничение максимальной скорости: лучше медленнее, но стабильно.

Опция виньетки (vignette): при движении затемнять периферию, оставляя центральную область более чистой.

Опция режима направления:

- движение «по направлению взгляда» (head-oriented) — часто проще понять; - движение «по направлению руки/контроллера» (hand-oriented) — иногда комфортнее, если пользователь смотрит в сторону, но идёт вперёд.

Практический вывод: smooth locomotion почти всегда должен иметь comfort settings.

Strafe (вбок) и движение назад

Это часто усиливает дискомфорт. Рабочие варианты:

ограничивать strafe (или снижать скорость strafe относительно forward);

делать отдельную настройку «разрешить strafe»;

предлагать пользователю физически разворачиваться корпусом вместо виртуального поворота.

Повороты: snap turn против smooth turn

Повороты часто укачивают сильнее, чем движение вперёд, потому что виртуальная камера вращается, а тело — нет.

Snap turn

Плюсы:

обычно заметно комфортнее;

проще контролировать.

Параметры, которые дают пользователю контроль:

угол поворота (например, 30°/45°);

задержка между срабатываниями;

включение/выключение.

Smooth turn

Плюсы:

точность;

привычность для игроков.

Минусы:

выше риск sickness.

Практика:

оставляйте smooth turn как опцию и задавайте умеренную скорость;

при первом запуске предлагайте выбор режима (или используйте профиль по умолчанию «комфортный»).

Comfort settings: что должно быть в настройках почти всегда

Ниже — набор настроек, который сильно повышает шансы, что приложение подойдёт большему числу пользователей.

| Настройка | Что делает | Почему важно | |---|---|---| | Режим перемещения | Телепорт / плавное | Сильнее всего влияет на sickness | | Режим поворота | Snap / плавный | Поворот — частый триггер укачивания | | Виньетка при движении | Да/Нет/Интенсивность | Снижает дискомфорт у части пользователей | | Скорость движения | Ползунок или пресеты | Позволяет «подстроить» комфорт | | Скорость поворота | Ползунок (для smooth) | Компромисс между контролем и комфортом | | Recenter | Кнопка в меню | Помогает восстановить удобную ориентацию |

Важно: все эти настройки лучше делать доступными в VR, через world-space UI, который вы уже умеете строить из предыдущей статьи про UI.

Реализация в Unity: XR Interaction Toolkit как практическая база

Ниже — типовой подход, который хорошо ложится на OpenXR и XR Interaction Toolkit.

Официальная документация:

XR Interaction Toolkit

Локомоция в терминах XR Interaction Toolkit

Обычно используются компоненты:

Locomotion System (координирует локомоцию и блокирует конфликтующие действия);

Teleportation Provider (телепорт);

Continuous Move Provider (плавное движение);

Snap Turn Provider или Continuous Turn Provider (повороты);

XR Ray Interactor (луч для выбора точки телепорта и UI).

Практическая рекомендация:

Сначала поднимите телепорт и snap turn.

Затем добавляйте continuous move и виньетку.

Каждый шаг проверяйте в шлеме на стабильном FPS.

Минимальный пример: включение/выключение режимов локомоции

Идея: у вас есть два набора компонентов (телепорт и continuous move), и вы переключаете их из меню настроек.

Что важно понимать в этом примере:

мы не двигаем Main Camera напрямую;

мы включаем/выключаем компоненты, которые управляют перемещением корня XR Origin;

переключение удобно вызывать из VR UI.

Реализация в Unreal Engine: VR Template как отправная точка

В Unreal самый быстрый практический путь для прототипа локомоции — использовать VR Template и OpenXR.

Документация:

OpenXR in Unreal Engine

Типовая логика:

Pawn содержит Camera (HMD) и Motion Controller компоненты;

телепорт и snap turn реализуются через Blueprint в шаблоне;

перемещение делается изменением положения Pawn root, а не «камера летит сама по себе».

Практика курса:

если вы делаете проект на Unreal, сначала разберите, где именно в Blueprint изменяется позиция Pawn, и убедитесь, что поведение совпадает с принципами из статьи про XR-риг.

Как локомоция связана с производительностью и стабильностью

Даже идеальная локомоция «ломается», если:

FPS нестабилен;

есть микрофризы при загрузке;

время кадра скачет.

Связка с предыдущими темами:

из статьи про standalone VR: оставляйте запас по производительности;

из статьи про XR-проект: начните с простого рендера и только потом усложняйте;

из статьи про взаимодействие: не перегружайте UI прозрачностями и тяжёлыми эффектами.

Практическое правило: прежде чем «тюнить» локомоцию, убедитесь, что сцена держит стабильный кадр на устройстве.

Тестирование комфорта: как проверять, что вы не делаете хуже

Минимальная программа тестов

Протестируйте сами:

- телепорт + snap turn; - smooth locomotion + snap turn; - smooth locomotion + smooth turn.

Протестируйте на другом человеке (лучше на нескольких):

- кто с VR-опытом; - кто без VR-опыта.

Проверьте крайние случаи:

- быстрые развороты; - движение назад; - подъёмы/спуски (если есть лестницы/рамповые поверхности).

Что измерять как разработчик

частоту жалоб на дискомфорт;

где именно становится плохо (поворот, ускорение, лестницы);

какие настройки спасают (snap, виньетка, снижение скорости).

Итоги

Локомоция в VR — ключ к комфорту: делайте телепорт и snap turn как базу, smooth locomotion — как опцию.

Двигайте корень игрока (XR Origin / Pawn root), а не HMD-камеру.

Укачивание чаще всего провоцируют ускорения, плавные повороты и нестабильный FPS.

Добавляйте comfort settings (режимы перемещения, повороты, виньетка, скорости, recenter) и делайте их доступными внутри VR.

Тестируйте на устройстве и на реальных пользователях: комфорт нельзя «доказать в редакторе».

Оптимизация под Quest 3: FPS, память, графика и профилинг

Зачем оптимизация выделена в отдельную тему

В предыдущих статьях курса мы построили основу: standalone-реальность Quest 3, Android-сборка, XR-риг, взаимодействие и локомоция. На этом этапе почти любой проект начинает сталкиваться с одним и тем же: в редакторе всё нормально, а в шлеме появляются просадки FPS, микрофризы, перегрев и нестабильность.

В VR оптимизация — это не «полировка в конце», а часть архитектуры:

комфорт напрямую зависит от стабильности времени кадра

локомоция и UI становятся неприятными, если появляются рывки

ошибки памяти и подгрузок на Android проявляются чаще и жёстче, чем на ПК

Дальше в статье — практический подход: как измерять, как понимать, что именно тормозит, и какие изменения обычно дают наибольший эффект на Quest 3.

!Воронка «измерить → найти узкое место → исправить → перепроверить»

Базовые метрики: что именно измерять

FPS и время кадра

FPS — количество кадров в секунду. Для VR важнее не сам FPS, а его стабильность.

Время кадра — сколько миллисекунд ушло на расчёт и рендер одного кадра. Даже если средний FPS высокий, редкие кадры, которые «вываливаются» из бюджета, ощущаются как подёргивания.

Практическая мысль:

оптимизируем не «в среднем», а так, чтобы плохие кадры стали редкими и чтобы их длительность уменьшилась

CPU bound и GPU bound

Две типовые ситуации:

CPU bound: процессор не успевает подготовить кадр (логика, физика, скрипты, анимация, подготовка рендера)

GPU bound: видеочип не успевает отрисовать кадр (пиксели, шейдеры, пост-эффекты, тени, прозрачность)

Почему это важно:

если вы GPU bound, оптимизация кода почти ничего не даст

если вы CPU bound, упрощение шейдера может не помочь

Память и фризы

На Quest 3 приложение может «держаться» по FPS, но страдать от:

резких фризов при подгрузке ассетов

падений из-за нехватки памяти

скачков времени кадра из-за сборщика мусора и временных аллокаций

Оптимизация памяти в VR часто даёт эффект именно в стабильности.

Инструменты профилинга: чем пользоваться в реальной работе

Общее правило

Профилировать нужно на устройстве, потому что:

производительность ПК и Quest несопоставима

часть проблем появляется только в Android-сборке (IL2CPP, шейдеры, загрузки)

реальный XR-пайплайн (стерео, runtime-композиция) корректно виден именно на устройстве

Unity: минимальный набор инструментов

Unity Profiler для CPU/GPU, памяти, рендер-статистики

Unity Frame Debugger чтобы увидеть, из каких проходов и вызовов отрисовки состоит кадр

Unity Memory Profiler для анализа снимков памяти и поиска утечек или «раздува» текстур/мешей

Практика:

сначала найдите, CPU вы ограничены или GPU

затем раскопайте конкретные «дорогие» места, а не оптимизируйте вслепую

Unreal Engine: минимальный набор

Unreal Insights для профилирования задач CPU, потоков, времени кадра, событий

Android-уровень

Android Studio Profiler для части CPU/памяти/сети и поведения приложения как Android-процесса

Logcat для ошибок, падений, предупреждений о памяти, загрузке плагинов и разрешениях

Документация Meta как точка входа

Для Quest-специфичных инструментов, рекомендаций и ограничений удобно держать под рукой официальный портал:

Meta Quest Developer Documentation

Практический алгоритм оптимизации под Quest 3

Ниже — алгоритм, который уменьшает шанс «потратить неделю и не получить эффекта».

Зафиксируйте сценарий воспроизведения

Соберите билд для устройства

Измерьте базовые метрики в этом сценарии

Определите тип узкого места: CPU bound, GPU bound, память, загрузки

Внесите одно заметное изменение

Повторно измерьте, сравните с базовой точкой

Зафиксируйте результат и переходите к следующему по влиянию пункту

Практический принцип: одно изменение — одно измерение.

Оптимизация GPU: графика и рендер

Самые частые GPU-«пожиратели» в standalone VR

динамические тени

много источников света

тяжёлые шейдеры и сложные материалы

высокая плотность пикселей, особенно при высоком внутреннем разрешении

прозрачности и UI-слои, которые перекрывают друг друга

пост-эффекты с несколькими проходами

Геометрия, LOD и culling

Что обычно даёт ощутимый выигрыш:

LOD: упрощённые версии мешей на расстоянии

Occlusion culling: не рисовать то, что закрыто стенами и крупными объектами

Frustum culling: не рисовать то, что вне поля зрения камеры

Риск, о котором часто забывают:

слишком агрессивный culling может вызывать «поппинг», который заметен в VR сильнее

Материалы и шейдеры

Практические советы для Quest-класса устройств:

уменьшайте количество уникальных материалов

избегайте дорогих эффектов в шейдере без явной необходимости

осторожнее с прозрачностью: она часто ломает раннее отсечение и делает кадр дороже

Свет и тени

Самый частый «быстрый выигрыш» в VR-проекте:

запечь освещение там, где это возможно

ограничить количество динамических источников света

уменьшить разрешение теней или отключить тени для второстепенных объектов

Если вам нужна динамика, подумайте о компромиссах:

тени только от одного ключевого света

тени только в небольшой зоне вокруг игрока

Разрешение, антиалиасинг и читаемость

В VR хочется увеличить качество, потому что текст и мелкие детали быстро становятся нечитаемыми. Но цена ошибки высокая.

Практический подход:

сначала добейтесь стабильности на умеренных настройках

затем поднимайте качество постепенно и измеряйте

для читаемости часто разумнее улучшить AA или шрифты/масштаб UI, чем «крутить всё вверх»

Оптимизация CPU: логика, физика, скрипты

Частые источники CPU bound в VR

тяжёлая физика и большое количество коллайдеров

частые вызовы в Update без необходимости

постоянные поиски объектов и компонентов

аллокации в кадре, вызывающие сборку мусора

дорогие системы анимации или IK без ограничения по частоте

Практики, которые обычно помогают

кэшировать ссылки на компоненты вместо постоянного GetComponent

уменьшать частоту обновления второстепенных систем

использовать object pooling для объектов, которые часто создаются и уничтожаются

следить, чтобы логика взаимодействия и UI не порождала мусор каждый кадр

В VR это особенно важно, потому что:

даже короткий фриз ощущается как «мир дёрнулся»

фриз часто совпадает с движением пользователя, усиливая дискомфорт

Память: текстуры, меши, аудио и подгрузка

Чем опасна память в standalone VR

Проблемы памяти редко выглядят как «немного ниже FPS». Чаще это:

внезапные фризы при подгрузке

краши

нестабильность после долгой сессии

Текстуры

Самая частая причина раздувания памяти — текстуры.

Практики:

включайте mipmaps там, где объект может быть далеко

уменьшайте разрешение текстур, которые не находятся близко к глазам

избегайте множества уникальных 2K/4K-текстур без необходимости

используйте атласы там, где это упрощает батчинг и снижает количество материалов

Меши и количество уникальных ассетов

следите за количеством уникальных мешей и материалов в кадре

используйте инстансинг там, где повторяются одинаковые объекты

Загрузка и фризы

Если при открытии меню или телепорте появляются фризы, часто виноваты:

синхронная загрузка ресурсов

создание сложных объектов «на месте» без прогрева

Практический подход:

прогревайте важные шейдеры и UI заранее

загружайте тяжёлые ассеты до того, как они срочно понадобятся

избегайте создания больших иерархий объектов в момент активного взаимодействия пользователя

Оптимизация VR UI: незаметная причина просадок

UI в VR часто делают «красивым», но это может быть дорого.

Частые проблемы:

много полупрозрачных слоёв

большие панели, которые постоянно перекрывают значительную часть экрана

анимированные маски, blur и эффекты

Практики:

минимизируйте прозрачность и перекрытия

делайте UI простым по материалам

показывайте только то, что нужно прямо сейчас

Связь с предыдущей статьёй про взаимодействие:

если у вас есть лучевой UI, подсветки и курсоры, убедитесь, что они не создают лишние рендер-проходы и не обновляют дорогостоящие элементы каждый кадр

Типовая диагностика: симптомы и вероятные причины

| Симптом в шлеме | Вероятная причина | Что проверить первым делом | |---|---|---| | Постоянно низкий FPS | GPU bound | тени, шейдеры, прозрачность, разрешение | | Рывки каждые несколько секунд | сборка мусора или подгрузка | аллокации в кадре, создание объектов, загрузки | | Нормально в одной сцене, плохо в другой | контент и освещение | количество источников света, уникальные материалы | | Плохо только при открытии меню | UI дорого рисуется | прозрачности, анимации, количество элементов | | Становится хуже через 10–15 минут | нагрев и троттлинг или утечки | профилинг на длительной сессии, память |

Как связать оптимизацию с комфортом и локомоцией

Из статьи про локомоцию вы уже знаете, что укачивание усиливают:

ускорения и повороты камеры

нестабильный FPS

Отсюда практическое правило разработки под Quest 3:

любые изменения локомоции тестируйте только после того, как сцена держит стабильный кадр

И наоборот:

если пользователь жалуется на дискомфорт, проверяйте не только настройки движения, но и микрофризы

Минимальный «боевой» чек-лист перед добавлением контента

сцена держит стабильный FPS на устройстве в целевом сценарии

включены и проверены базовые инструменты профилинга

свет и тени настроены осознанно, нет «случайных» динамических теней везде

UI не построен на множестве прозрачных слоёв

нет регулярных аллокаций в кадре в ключевых системах (взаимодействие, локомоция, UI)

тяжёлые ассеты не грузятся синхронно в момент действия пользователя

Итоги

Оптимизация под Quest 3 начинается с измерений на устройстве: стабильность важнее среднего FPS.

Сначала определяйте, CPU вы ограничены или GPU, и оптимизируйте по главному узкому месту.

На GPU чаще всего «дороги» тени, свет, шейдеры, прозрачность и пост-эффекты.

На CPU часто «съедают» кадр физика, лишняя логика в кадре и аллокации.

Память и подгрузка влияют на микрофризы и стабильность, что напрямую бьёт по комфорту.

В следующем развитии курса обычно идут более прикладные практики под выбранный движок: настройка качества, стабильной частоты, конкретные профили XR и системная работа с ассетами и сценами под standalone VR.

Сборка, тестирование и публикация в Meta Horizon Store

Как эта тема связана с предыдущими статьями курса

Ранее вы собрали базу проекта под Quest 3: настроили Android/OpenXR/Meta XR SDK, правильно построили XR-риг, сделали взаимодействия и локомоцию, а также разобрались, что оптимизация в standalone VR критична для комфорта.

Дальше возникает практический вопрос: как превратить рабочий прототип в релизный билд, стабильно протестировать его на устройстве и довести до публикации в Meta Horizon Store.

Цель этой статьи:

собрать релизную версию приложения так, чтобы она корректно устанавливалась и обновлялась

провести тестирование так, чтобы поймать типовые Quest-проблемы (падения, разрешения, ввод, производительность)

подготовить проект и материалы к публикации и прохождению модерации

!Схема жизненного цикла: от релизной сборки до публикации и обновлений

Что значит «релизная сборка» для Quest 3

Релизная сборка отличается от сборки “для себя” тем, что она должна быть:

подписана вашим релизным ключом, чтобы обновления работали корректно

повторяемо собираема (вы можете собрать тот же вариант снова)

предсказуема по производительности (нет случайных «дебаг»-накладных расходов)

готова к проверке: корректные разрешения, корректный ввод, корректная реакция на потерю трекинга

Практическое правило для standalone VR:

финальную оценку стабильности и FPS делайте только на устройстве, а не в редакторе

Версионирование и идентификация приложения

Перед публикацией важно зафиксировать три понятия.

Package name (Application ID)

Это уникальный идентификатор приложения на Android, обычно выглядит как com.company.product.

Правила:

после релиза нельзя менять package name без выпуска фактически “нового” приложения

package name должен быть стабильным между версиями, иначе обновления не будут устанавливаться поверх

Version name и version code

В Android обычно есть два “уровня” версии:

version name — человекочитаемая версия (например, 1.2.0)

version code — целое число для системы обновлений

Ключевой смысл version code:

при выпуске обновления его значение должно строго увеличиваться, иначе платформа может отклонить обновление или устройство не установит его как апдейт

Официальный ориентир по версиям и публикации на Android:

App versioning (Android Developers)

Подпись приложения: почему без этого нельзя публиковаться

Android-приложения должны быть подписаны. Подпись определяет, что “это то же самое приложение”, и разрешает обновления.

Debug-подпись против релизной

Debug-подпись создаётся для разработки и может отличаться на разных машинах

Релизная подпись должна быть вашей стабильной подписью проекта

Практические последствия:

если вы случайно выпустите публичный билд, подписанный не тем ключом, вы усложните или сделаете невозможным нормальный апдейт поверх старой версии

хранение релизного ключа становится частью “производственной дисциплины” команды

Официальный ориентир по подписи:

Sign your app (Android Developers)

Рекомендации по безопасности ключа

храните keystore в защищённом месте и делайте резервную копию

ограничьте доступ и зафиксируйте, кто в команде отвечает за релизную подпись

документируйте пароль/процесс хранения так, чтобы проект не «умер» при смене одного человека

Сборка релизного билда

Ниже общая логика для Unity и Unreal: конкретные галочки в UI движков зависят от версии, но принципы одинаковы.

Что проверить в релизной конфигурации

целевая платформа Android

архитектура ARM64

отключены лишние debug-функции (development build, autoconnect profiler и подобные)

корректно выставлены версия и version code

приложение подписывается релизным ключом

Если вы используете OpenXR и Meta XR SDK, убедитесь, что:

включены нужные interaction profile для контроллеров

включены или отключены hand tracking и MR-функции осознанно, с пониманием разрешений и UX

Формат сборки для загрузки

Для Quest-публикации чаще всего используется APK.

Практическое правило:

перед загрузкой билда ориентируйтесь на требования в панели разработчика Meta, так как требования могут обновляться

Официальная точка входа в документацию Meta:

Meta Quest Developer Documentation

Установка и проверка билда на устройстве

Минимальный цикл проверки

Установите билд на Quest 3.

Запустите приложение как пользователь (не только из движка).

Пройдите ключевой сценарий (меню → игра/сцена → взаимодействия → локомоция).

Соберите логи при любых ошибках.

ADB: установка и логирование

Базовые команды:

adb install -r переустанавливает приложение поверх существующей версии

adb logcat показывает системные и приложенческие логи, которые нужны для диагностики падений

Официальные ссылки:

Android Debug Bridge (adb)

Logcat command-line tool

Meta Quest Developer Hub

Meta Quest Developer Hub часто используют как удобный инструмент для работы с устройством (установка, базовая диагностика, управление девайсами).

Официальная страница загрузки:

Meta Quest Developer Hub

Тестирование перед публикацией: практический чек-лист

Тестирование под Quest 3 отличается тем, что ошибки часто проявляются не в логике игры, а в связке “XR runtime + ввод + комфорт + производительность”.

Функциональные проверки

запуск без чёрного экрана и без зависаний при старте

корректная работа трекинга головы

корректная работа контроллеров: луч, grab, UI click

корректный fallback, если меняется режим ввода (контроллеры убрали, руки появились или наоборот)

корректная реакция на потерю трекинга (например, руки временно пропали)

корректная работа локомоции и доступность comfort-настроек

Проверки разрешений и системных состояний

запросы разрешений происходят ожидаемо и не ломают UX

приложение не требует лишних разрешений “на всякий случай”

приложение корректно переживает “сняли шлем” или “приложение свернули”

Проверки производительности и комфорта

стабильное время кадра в целевой сцене

нет регулярных микрофризов при открытии меню, телепорте, появлении UI

нет долгих фризов на подгрузках в момент активного движения пользователя

Эта часть напрямую связана с предыдущей статьёй про оптимизацию: прежде чем идти в публикацию, убедитесь, что вы не выпускаете проект с “плавающим” FPS.

Регрессионный сценарий

Перед каждым кандидатом в релиз полезно прогонять один и тот же короткий маршрут, чтобы сравнивать версии:

Старт приложения.

Открытие меню.

Телепорт 3–5 раз.

Захват 2–3 объектов.

Переход в следующую сцену (если есть).

Возврат в меню.

Смысл:

вы быстрее замечаете, что новая версия стала тяжелее или менее стабильной

Распространение на тестировщиков: релизные каналы

Перед публичной публикацией почти всегда полезно раздать билд ограниченному кругу людей.

Типовая модель:

отдельные билды и доступы для тестировщиков

фиксация “кандидата в релиз” и его проверка на разных пользователях

Что важно организовать на практике:

список тестовых устройств и пользователей

сбор обратной связи: где укачивает, что непонятно, где ломается ввод

сбор логов при падениях (попросите тестировщика повторить и прислать время/сценарий)

Официальная точка входа для управления публикацией и дистрибуцией в экосистеме Meta:

Meta Quest Developer Documentation

Подготовка к публикации: что обычно требуется для Store Listing

Публикация — это не только APK, но и “упаковка продукта”. Часть пунктов может различаться в зависимости от типа приложения и требований Meta на момент подачи.

Метаданные и материалы

Обычно вам нужны:

название и описание приложения

иконка и визуальные материалы (скриншоты)

промо-материалы (часто видео)

Рекомендация:

делайте скриншоты и видео из устройства, чтобы не обещать качество, которого нет на standalone

Политики и пользовательская информация

Подготовьте заранее:

ссылку на политику конфиденциальности (если вы собираете данные, используете аккаунты, аналитику)

понятное описание, что именно делает приложение и для какой аудитории

Если вы используете Android-пермишены или платформенные возможности, полезно ориентироваться на Android-справку:

Permissions on Android (Android Developers)

Типовые причины проблем при модерации и как их избежать

Ниже не “официальный список”, а практические причины, с которыми разработчики сталкиваются чаще всего.

Приложение падает или зависает при старте

Как снижать риск:

тестируйте “чистый запуск” после установки

проверяйте adb logcat на ошибки загрузки библиотек, шейдеров, разрешений

прогревайте тяжёлые ресурсы заранее или переносите загрузки на безопасные моменты

Непредсказуемый ввод и отсутствие базовых сценариев

Как снижать риск:

убедитесь, что приложение можно пройти на контроллерах без “секретных жестов”

если поддерживаете hand tracking, сделайте понятный fallback и подсказки

не смешивайте одновременно несовместимые интеракторы без явной логики приоритетов

Проблемы комфорта

Как снижать риск:

телепорт и snap turn как безопасные дефолты

настройки комфорта доступны внутри VR

нет резких ускорений и неожиданных поворотов камеры

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

Как снижать риск:

профилируйте на устройстве

фиксируйте целевую частоту и держите запас по кадру

избегайте тяжёлых прозрачных UI-панелей и лишних теней

Публикация и обновления: дисциплина релизов

После первой публикации работа обычно становится более “продуктовой”. Важно не потерять управляемость.

Минимальные правила обновлений

каждый новый билд увеличивает version code

обновления подписываются тем же релизным ключом

перед апдейтом прогоняйте регрессионный сценарий

Стратегия «release candidate»

Практичный подход для небольших команд:

Собираете билд-кандидат.

Раздаёте тестировщикам.

Если нет блокирующих багов, этот же билд становится релизом.

Смысл:

вы не «пересобираете на коленке» финальную версию в последний момент

Итоги

Релиз под Quest 3 начинается с дисциплины: стабильный package name, растущий version code, релизная подпись.

Тестируйте на устройстве и собирайте логи через adb logcat, иначе вы будете “гадать”, почему билд падает.

Перед публичной публикацией организуйте тестирование на ограниченной аудитории и фиксируйте релиз-кандидата.

На модерации чаще всего “валятся” не редкие кейсы, а базовые: падение при старте, непредсказуемый ввод, проблемы комфорта и производительности.

Дальше курс можно расширять практикой под выбранный движок: автоматизация сборок (CI), сбор аналитики, A/B тестирование настроек комфорта, и более глубокая работа с производительностью на длительных сессиях.