OpenXR
Khronos OpenXR открытый, бесплатный стандарт, положивший конец кризису фрагментации XR — полной технической поломке API, который лежит в основе всех основных гарнитур виртуальной реальности и MR, представленных на рынке в 2025 году.

OpenXR стандарт, положивший конец фрагментации XR
OpenXR — это открытый, бесплатный стандарт интерфейса прикладного программирования (API) для устройств виртуальной, дополненной и смешанной реальности, известных под общим названием extended reality (XR). Разработанный и поддерживаемый Khronos Group, открытым некоммерческим консорциумом из более чем 180 ведущих компаний отрасли. OpenXR обеспечивает единый унифицированный интерфейс между приложениями XR и оборудованием XR. Она была анонсирована на конференции GDC 27 февраля 2017 года, выпущена как версия 1.0 на SIGGRAPH 29 июля 2019 года и обновлена до версии 1.1 15 апреля 2024 года. Последней версией спецификации является версия 1.1.59.
OpenXR решает проблему, которая мешала разработке XR с первых дней возрождения виртуальной реальности: фрагментацию. До появления OpenXR каждому крупному производителю гарнитур требовался свой, несовместимый SDK. Создание VR game, которая работала бы как на основе мета—квеста, так и на основе индекса Valve, означало написание двух совершенно разных путей написания кода — не просто изменение настроек, но и создание отдельных интеграций API с нуля для каждой платформы. Стандарт OpenXR определяет, как приложения XR взаимодействуют с оборудованием XR. В итоге заменяя множество проприетарных API-интерфейсов единым универсальным интерфейсом. В итоге который теперь поддерживает каждый крупный производитель оборудования.
К 2025 году OpenXR стал стандартом для разработки XR: Meta Quest, SteamVR, Windows Mixed Reality и большинство корпоративных платформ XR изначально поддерживают OpenXR. Его внедрение было настолько полным, что Meta, чьи устаревшие интерфейсы VRAPI и LibOVR были частью проблемы фрагментации, официально объявили устаревшими в августе 2022 года, указав OpenXR в качестве единственного рекомендуемого пути развития в будущем.
Эпоха фрагментации, которая сделала OpenXR необходимым
Чтобы понять, почему OpenXR имеет значение, необходимо понять, как выглядела разработка XR до него. В 2016 году существовало три API для управления поведением XR:
- LibOVR (также известный как CAPI), созданный Oculus для ПК, использующих гарнитуры Rift; VrApi,
- созданный Samsung для мобильных устройств, использующих гарнитуры;
- и OpenVR, созданный Valve и HTC для ПК, использующих гарнитуры Vive.
Эта экосистема требовала переписывания и исправления ошибок для разработчиков, выпускающих на нескольких платформах.
Помимо этих трех, платформа Microsoft Windows Mixed Reality Platform имела свою собственную среду выполнения. PlayStation VR от Sony требовала совершенно другой интеграции. К тому же у корпоративных поставщиков, таких как Varjo и Magic Leap, были собственные SDK. Разработчику, ориентированному на весь рынок, потребовалось бы поддерживать шесть или более отдельных путей кода для одних и тех же фундаментальных операций:
- считывания положения головы,
- опроса входных данных контроллера,
- отправки визуализированных кадров,
- управления жизненным циклом сеанса.
До появления OpenXR создание виртуальной игры, которая запускалась бы как на основе мета-квеста, так и на основе индекса Valve, означало написание двух совершенно разных путей написания кода. Не просто изменение настроек — написание отдельных интеграций API с нуля для каждой платформы, которую вы хотели поддерживать. Эта избыточность была не просто неудобством; это был структурный налог на всю экосистему XR, который замедлял скорость разработки, увеличивал затраты и делал непрактичным для небольших студий работу на нескольких платформах. В 2017 году группа компаний Khronos собрала крупнейших поставщиков оборудования, чтобы коллективно решить эту проблему.
Многоуровневая архитектура OpenXR — Уровни загрузчика, среды выполнения и API
OpenXR — это многоуровневая архитектура, состоящая из трех основных компонентов: приложения, загрузчика и среды выполнения. OpenXR — это интерфейс между приложением и системой XR runtime, работающей в процессе или вне процесса. Среда выполнения может обрабатывать такие функциональные возможности как
- композиция кадров,
- управление периферийными устройствами
- необработанная информация отслеживания.
Загрузчик OpenXR — это общая библиотека для конкретной платформы, которая находится между приложением и одним или несколькими средами выполнения, установленными в системе. Загрузчик был разработан со следующими целями: он должен поддерживать одну или несколько сред выполнения с поддержкой OpenXR в компьютерной системе пользователя; он должен поддерживать уровни API OpenXR (дополнительные модули, которые могут быть включены приложением, разработчиком или стандартными системными настройками); и он должен стремиться к сокращению объема занимаемой памяти и влияние на производительность приложения OpenXR.
Уровни API (API Layers) — это необязательные компоненты, вставляемые между приложением и средой выполнения. Уровни API — это необязательные компоненты, которые дополняют систему OpenXR. Они могут перехватывать, оценивать, изменять и вставлять существующие команды OpenXR на пути от приложения к среде выполнения. Khronos предоставляет уровень проверки, который проверяет правильность использования API, и уровень дампа API для отладки. В 2024 году был выпущен уровень проверки наилучших практик, который помогает разработчикам создавать более надежные переносимые приложения.
Среда выполнения — это реализация для конкретной платформы, предоставляемая каждым производителем гарнитур:
- среда выполнения Meta,
- среда выполнения SteamVR от Valve,
- среда выполнения Microsoft для смешанной реальности и так далее.
Каждая среда выполнения должна пройти набор тестов соответствия OpenXR (CTS). Чтобы быть внесенной в реестр продуктов, соответствующих требованиям Khronos, и легально использовать торговую марку OpenXR.
Пять основных объектов — строительных блоков каждого приложения OpenXR
Основными элементами OpenXR API являются:
- XrInstance (представление среды выполнения OpenXR),
- XrSystemId (представление устройств, включая устройства виртуальной или дополненной реальности и контроллеры),
- XrSession (представляет сеанс взаимодействия между приложением и пользователем),
- XrSpace (представление трехмерного пространства),
и XrActions (используются для обработки пользовательских вводимых данных). Пожалуй каждое приложение OpenXR, независимо от платформы или устройства, структурировано вокруг этих пяти типов объектов.
XrInstance
Корневой объект. Создается один раз для каждого приложения с помощью вызова функции xrCreateInstance(). Представляет подключение к среде выполнения OpenXR. Все остальные объекты являются дочерними объектами экземпляра. Уничтожается при завершении работы приложения.
XrSystemId
Определяет физическое аппаратное обеспечение XR — гарнитуру и связанные с ней устройства ввода. Запрашивается с помощью xrGetSystem(). Это не дескриптор, а идентификатор, который сопоставляется с доступным оборудованием в текущей системе.
XrSession
Интерфейс active XR. Создан на основе экземпляра и привязки к графическому API (Vulkan, OpenGL, D3D11/12). Управляет жизненным циклом сеанса: простаивание → готовность → запуск → остановка → выход. Цикл фреймирования находится внутри сеанса.
XrSpace
Система отсчета в трехмерном пространстве. Приложения запрашивают XrSpace для получения данных о позе (положении + ориентации) в прогнозируемое время. Ключевые пространства: ВИД (голова), ЛОКАЛЬНОЕ (исходное положение в масштабе помещения), СЦЕНА (уровень пола). Пользовательские пространства из привязок или пространственных отображений.
XrActions
Система абстрагирования входных данных. XrActionSets группирует связанные действия; XrActions сопоставляются с входными данными контроллера (кнопки, триггеры, оси джойстиков, тактильные ощущения). Профили взаимодействия сопоставляют действия с входными данными, зависящими от оборудования — по одному профилю для каждого типа контроллера.
XrSwapchain
Цепочка буферов изображений, совместно используемая приложением и компоновщиком среды выполнения. Приложение преобразует изображения в swapchain; среда выполнения компонует их на дисплее, используя свой собственный конвейер перепроецирования и искажения объектива.
Конечный автомат сеанса — Как OpenXR управляет фокусом и видимостью
Как оказалось одним из наиболее важных шаблонов проектирования OpenXR является его явный автомат состояний сеанса. В итоге типичный сеанс XR координирует работу приложения и среды выполнения с помощью функций управления сеансом и событий состояния сеанса. В итоге конечный автомат гарантирует, что приложения корректно реагируют на системные события — снятие пользователем гарнитуры, появление системного оверлея, переход устройства в режим ожидания — без необходимости использования кода, зависящего от платформы. Все платформы XR используют одни и те же переходы состояний, передаваемые через событие XrEventDataSessionStateChanged.
Компоновщика с циклом прогнозируемых временных рамок и нулевой копией
Конструкция фреймового цикла в OpenXR принципиально отличается от обычного игрового цикла. Как правило понимание этого различия имеет решающее значение для достижения низкой задержки в XR. OpenXR использует модель прогнозируемого времени. Вызовы xrWaitFrame, xrBeginFrame и xrEndFrame не являются предложениями. Они представляют собой механизм, с помощью которого compositor синхронизирует рендеринг с циклом обновления дисплея.
Впрочем ключевой концепцией является прогнозируемое время отображения. Ввиду того что компоновщик точно знает, когда следующий кадр будет представлен глазам пользователя. Он передает эту временную метку приложению через xrWaitFrame, который блокируется до тех пор, пока компоновщик не будет готов к приему нового кадра. Приложение должно запрашивать все позы — положение головы, рук, данные контроллера. Притом на этой прогнозируемой временной отметке в будущем, а не на текущее время. Этот прогнозирующий поиск позы позволяет системе компенсировать задержку рендеринга, отображая правильное изображение с учетом того, где будет находиться голова пользователя при включении пикселей, а не с учетом того, где она была при запуске рендеринга.
К тому же визуализированный результат передается через общую цепочку изображений XrSwapchain. Потому как вместо копирования пикселей приложение получает изображение swapchain, рендерит его с помощью своего графического API (Vulkan, D3D12 и т.д.), публикует его, а runtime compositor считывает изображение напрямую — конвейер с нулевым копированием, который устраняет значительную задержку, характерную для более ранних XR SDK.
Система действий — Аппаратно-независимая привязка входных данных
Модель ввода в OpenXR — одно из самых элегантных дизайнерских достижений. Вместо того, чтобы отображать необработанные состояния аппаратных кнопок, которые различаются в зависимости от контроллера, в ней используется абстракция, основанная на действиях. Приложение объявляет, какие действия ему нужны (например, «захват», «запуск», «телепортация»). Притом среда выполнения сопоставляет эти действия с физическими кнопками на любом подключенном контроллере. Кроме того используя набор профилей взаимодействия, которые описывают привязку для каждого конкретного типа оборудования.
К тому же OpenXR 1.1 добавил 13 новых профилей взаимодействия в базовую спецификацию, наряду с новыми стандартными типами идентификаторов, включая thumb_resting_surfaces, stylus, trigger_curl и trigger_slide. Это означает, что приложениям не нужно обновляться при запуске нового типа контроллера. В результате среда выполнения предоставляет соответствующий профиль взаимодействия, а заявленные действия приложения автоматически сопоставляются с правильными физическими входными данными.
Отслеживание рук доступно с помощью расширений — XR_EXT_hand_tracking предоставляет полный скелет из 26 суставов для каждой руки. В то время как XR_META_hand_tracking_aim и аналогичные расширения поставщика предоставляют дополнительные данные отслеживания для конкретного оборудования. Тактильный вывод использует ту же систему действий. XrHapticActionInfo нацелен на конкретное действие, а среда выполнения направляет команду вибрации на соответствующий контроллер.
Расширения — Инновации без фрагментации
Как известно система расширения OpenXR — это механизм, который позволяет производителям оборудования предоставлять новые возможности — сквозные камеры, отслеживание взгляда, лица, пространственные привязки — без нарушения стабильности базовой спецификации. К тому же расширения соответствуют строгому соглашению об именовании, которое указывает на их происхождение и степень зрелости. Притом расширения KHR совместно согласованы рабочей группой и почти наверняка будут внедрены в ядро. Расширения EXT широко использующиеся разными поставщиками, но еще не ратифицированы. А у расширений с префиксами поставщиков (META_, FB_, VALVE_, MSFT_, VARJO_) появляются собственные возможности, доступные через стандартный API.
OpenXR 1.1 интегрирует широко используемые расширения API непосредственно в свою основную спецификацию. Буквально снижая сложность для разработчиков и сводя к минимуму расхождения между различными платформами. Этот процесс продвижения, в ходе которого расширения проверенных поставщиков переходят на уровень дополнительных услуг между поставщиками. И в конечном итоге, на базовый уровень, — это то, как развивается стандарт, не нарушая работу существующих приложений. К счастью рабочая группа OpenXR непосредственно управляет набором расширений для разработки. Как следствие получения отзывов о новых функциональных возможностях. Вместе с тем одновременно активно интегрируя проверенные технологии в основную спецификацию.
От анонса к универсальному стандарту
27 февраля 2017 года — GDC 2017 Компания Khronos Group объявила об открытии OpenXR
Группа компаний Khronos публично анонсирует инициативу OpenXR на Конференции разработчиков игр. В число учредителей входят Oculus, Valve, Epic Games, Unity, Microsoft, Samsung, Qualcomm, ARM, Google и HTC. Цель заявлена четко: покончить с фрагментацией XR, создав единый, бесплатный, открытый стандарт для всего оборудования XR.
29 июля 2019 — SIGGRAPH 2019 Выпущен OpenXR 1.0 — Стандарт появился на свет
Как известно опубликована спецификация OpenXR 1.0. Причем первая версия спецификации OpenXR была выпущена на выставке SIGGRAPH 2019. Как следствие результатом стал хорошо разработанный, хорошо документированный и гораздо более низкоуровневый API, чем OpenVR. Едва только предварительные версии от Oculus (для Quest) и Microsoft (для HoloLens 2) будут доступны в течение нескольких месяцев. Так или иначе Valve выпускает предварительный просмотр для SteamVR. Вдобавок начинается разработка среды выполнения с открытым исходным кодом Monado.
Июль 2020 г. Выпущено несколько совместимых реализаций
В то время как Microsoft выпускает совместимую с OpenXR среду выполнения для HoloLens 2. А Facebook в свою очередь — совместимую среду выполнения для Oculus Quest на базе Android, демонстрируя гибкость OpenXR для автономных и привязанных устройств XR, использующих различные базовые операционные системы. Помимо этого Valve выпускает OpenXR 1.0 в SteamVR. Вдобавок Varjo выпускает предварительный просмотр для разработчиков. В свою очередь Blender 2.83 интегрирует OpenXR для проверки сцен виртуальной реальности. Причем Google Chromium 81 выпускает WebXR с OpenXR в качестве серверной части по умолчанию.
Август 2022 В Meta устаревшие API не используются — OpenXR становится обязательным
Поскольку с 31 августа 2022 года Meta больше не поддерживает библиотеку VrApi. Потому OpenXR является стандартным API для разработки новых VR/XR-приложений на гарнитурах Meta Quest. Поскольку устаревшие API, VrApi и LibOVR, использовались в предыдущих поколениях. Пожалуй это решающий момент — крупнейшая автономная платформа виртуальной реальности в мире делает OpenXR своим эксклюзивным направлением развития, сигнализируя всей отрасли о том, что старые проприетарные API мертвы.
15 апреля 2024 года Выпущен OpenXR 1.1 — Объединение расширений в ядро
OpenXR 1.1 объединяет широко используемые расширения API в основной спецификации для уменьшения фрагментации. Вместе с тем добавляет новые функциональные возможности для разработки более эффективных приложений XR. В частности, OpenXR 1.1 объединяет несколько расширений от производителей для обеспечения ключевых функциональных возможностей. Для того чтобы уменьшить различия в коде приложений на разных платформах, оставаясь при этом гибким и расширяемым. Последняя спецификация: версия 1.1.59. Pico подтверждает соответствие OpenXR 1.1. Android XR достигнет соответствия требованиям среды выполнения в декабре 2024 года.
2025 — Всеобщее внедрение OpenXR Используется по Умолчанию для всех Разработок XR
В итоге к 2025 году OpenXR стал стандартом для разработки XR: Meta Quest, SteamVR, Windows Mixed Reality. В силу чего большинство корпоративных платформ XR изначально поддерживают OpenXR. Как следствие Samsung Galaxy XR запускается с Android XR, который использует OpenXR в качестве основного стандарта среды выполнения. К примеру гарнитура Samsung Galaxy XR, которая использует операционную систему Android XR, запускает приложения, совместимые с OpenXR 1.1. К слову сказать Sony PSVR2 поддерживает OpenXR через PC adapter в Steam. В свою очередь NVIDIA CloudXR обеспечивает соответствие требованиям OpenXR для потоковой передачи XR в облачном режиме.
Сильные стороны и ограничения
✓ Сильные стороны
- Универсальность — единая кодовая база предназначена для всех основных платформ XR одновременно
- Бесплатна и открыта — ни для одного разработчика или поставщика лицензионные сборы не взимаются
- Управляется более чем 180 участниками отрасли — на основе консенсуса, а не под контролем поставщика
- Система ввода, основанная на действиях, полностью исключает использование кода для каждого контроллера
- Прогнозируемая временная модель обеспечивает рендеринг с минимальной задержкой на всех аппаратных средствах
- Конструкция цепочки подкачки с нулевым количеством копий устраняет основной источник задержки кадров
- Система расширений позволяет внедрять аппаратные инновации, не нарушая работу существующих приложений
- Набор тестов соответствия гарантирует, что все среды выполнения будут одинаково работать с базовым API
- Поддержка движков: Unity, Unreal Engine, Godot, Blender, O3DE — universal
- Поддерживается в Windows, Linux и Android /Android XR
- Отслеживание движений рук, глаз, лица и тела стандартизировано с помощью расширений
Meta, Valve, Microsoft и Google отказались от проприетарных API в пользу OpenXR
✗ Ограничения
- API C99 является многословным и гораздо более стандартным, чем OpenVR или SDK для конкретной платформы
- Изначально нет серверной части Metal — Apple Vision Pro (visionOS) не поддерживает OpenXR
- Экосистема расширений фактически создает фрагментацию для расширенных функций (сквозное использование, понимание сцены)
- Расширения от поставщиков требуют тестирования для каждой платформы даже при наличии общей кодовой базы
- Нет стандарта для шаблонов пространственного взаимодействия UI/UX — каждая платформа отличается
- WebXR (основанный на браузере) работает отдельно и не предоставляет полный низкоуровневый OpenXR API
- Тестирование соответствия не распространяется на поведение расширений — только на спецификации ядра
- Управление версиями спецификаций может отставать от быстро развивающихся возможностей оборудования
Вердикт: Самый важный открытый стандарт в истории XR
OpenXR, без сомнения, является наиболее важной частью инфраструктуры в современной индустрии XR. Его достижение заключается не в технической сложности, хотя цикл прогнозируемых временных рамок, система ввода данных на основе действий и цепочка обмена с нулевым копированием являются по—настоящему элегантными инженерными решениями. Ее достижение носит политический и организационный характер: она убедила конкурирующие компании, производящие аппаратное обеспечение, каждая из которых инвестировала миллиарды долларов в собственные экосистемы, отказаться от этих экосистем и стандартизировать их на основе общей спецификации. Meta объявила VrApi и LibOVR устаревшими. Valve больше не добавляет функции в OpenVR. Microsoft HoloLens 2 поставляется в совместимом исполнении. Android XR от Google является родным. Pico, Varjo, HTC, Magic Leap, XREAL — все они совместимы.
Уместна аналогия: OpenXR для XR — это то же самое, чем OpenGL был для 3D-графики в 1990-х годах или чем TCP/IP является для сетей. Это уровень протокола, на котором построена вся экосистема. Для разработчиков это имеет серьезные последствия: проект Unity, ориентированный на Meta Quest 3, практически не требует изменений, чтобы также использовать SteamVR, Samsung Galaxy XR, Pico 4 Ultra, HTC Vive и Varjo. Та же кодовая база. Тот же цикл создания кадров. Те же действия ввода. Один двоичный файл для всех устройств.
Единственное заметное отсутствие — Apple. visionOS не поддерживает OpenXR, что подтверждает характерное для Apple неприятие открытых стандартов сторонних производителей. Для экосистемы XR это создает существенный раскол — Vision Pro остается островком, требующим разработки специально для visionOS, — но это не подрывает доминирующего положения OpenXR во всем остальном мире. По мере того, как аппаратная экосистема расширяется за счет создания очков с искусственным интеллектом и проводных дисплеев XR, архитектура OpenXR имеет все возможности для внедрения этих новых форм-факторов с помощью того же расширительного конвейера, который до них включал отслеживание движений рук, глаз и сквозного доступа.