Разработка мобильного VR-приложения для просмотра 360°-видео

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Разработка мобильного VR-приложения для просмотра 360°-видео
Сложный
от 1 недели до 3 месяцев
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Разработка мобильного VR-приложения для просмотра 360°-видео

Создание мобильного VR-плеера для 360-градусного видео — задача, которая выходит за рамки обычного видеоплеера. Equirectangular-проекцию нужно развернуть на сфере вокруг пользователя, синхронизировать с движением головы и исключить артефакты на сшивке — всё при частоте кадров, достаточной для комфортного VR. Ошибки на этапе рендеринга приводят к дискомфорту и motion sickness. Загрузка 10-минутного 4K видео через CDN может обходиться в 500 рублей за сессию — при пиковых нагрузках это миллионы. Наш подход с viewport-зависимым стримингом экономит до 80% трафика, а значит и денег.

Мы используем проверенные технологии: Unity LTS, Swift, Kotlin, а также адаптивные протоколы стриминга. Наш опыт — 7+ лет и 15+ VR-проектов — позволяет гарантировать качество и производительность. Свяжитесь с нами для консультации.

Согласно спецификации MPEG-OMAF, viewport-зависимая передача снижает битрейт в 3-5 раз. Для проекта с 1 млн сессий экономия на CDN может составлять до 2 млн рублей.

Техническая сторона: sphere mapping

Equirectangular-видео (2:1 соотношение сторон, стандарт YouTube и Facebook 360) отображается на инвертированную сферу — пользователь смотрит изнутри. Разрешение для комфортного просмотра: минимум 4K (3840×2160), желательно 5.7K или 8K. При 4K на каждый глаз приходится ~30 пикселей на градус — это граница, ниже которой видна «сетка» пикселей.

На Unity создаём инвертированную сферу с обращёнными нормалями внутрь:

// Стандартная Unity Sphere + специальный материал
// Или через пакет com.unity.xr.management

// Шейдер для 360-видео
// vert: передаём UV как есть
// frag: сэмплируем _MainTex с UV, горизонтальный flip для правильной ориентации

На нативном Android через MediaPlayer + OpenGL ES:

// Создаём Surface для MediaPlayer, рендерим как texture на сферу
SurfaceTexture surfaceTexture = new SurfaceTexture(textureId);
Surface surface = new Surface(surfaceTexture);
mediaPlayer.setSurface(surface);
mediaPlayer.prepareAsync();

На iOS — AVPlayer + SCNSphere в SceneKit или RealityKit:

let sphere = SCNSphere(radius: 10)
sphere.firstMaterial?.isDoubleSided = true // или инвертированные нормали
sphere.firstMaterial?.diffuse.contents = avPlayer
let sphereNode = SCNNode(geometry: sphere)
sphereNode.scale = SCNVector3(-1, 1, 1) // flip X для правильного direction
sceneView.scene.rootNode.addChildNode(sphereNode)

Стереоскопическое 360: top-bottom vs side-by-side

Для стереоскопического 360-видео используются два основных формата: top-bottom (TB) и side-by-side (SBS). В TB верхняя половина кадра отводится для левого глаза, нижняя — для правого, что даёт соотношение сторон 1:1 и более простую реализацию шейдера. Однако при этом теряется полезное разрешение по вертикали. SBS делит кадр по вертикали — левый глаз слева, правый справа, соотношение сторон 4:1. Этот формат меньше искажается при низком битрейте, но требует более сложного шейдера для разделения. Для большинства проектов мы рекомендуем TB из-за лучшей совместимости и простоты интеграции.

Формат Разрешение на глаз Сложность шейдера Совместимость Искажения при низком битрейте
TB 3840×1080 (50% высоты) Низкая Высокая Умеренные
SBS 1920×2160 (50% ширины) Средняя Средняя Минимальные

TB даёт вдвое меньше вертикальных пикселей на глаз, но проще в реализации. SBS сохраняет вертикальное разрешение, но требует более узкого поля зрения.

Потоковое воспроизведение: HLS/DASH для 360

360-видео — это файлы 2–8 GB для 10-минутного контента при 4K–8K. Загружать целиком перед воспроизведением неприемлемо. Решение — адаптивный стриминг.

Для 360 HLS нужна особая нарезка на сегменты с учётом spherical projection — идеально использовать Spatial Media spec от Google, который встраивает метаданные о типе проекции прямо в файл. ffmpeg с флагом --spherical при создании манифеста.

Адаптивное переключение битрейта критично: при поворотах головы вся сфера видна, но основная нагрузка — на зоне перед взглядом. Viewport-dependent streaming (или Tile-based streaming) отдаёт высокое разрешение только для текущего направления взгляда. Это снижает трафик в 3–5 раз — для проекта с 1 млн сессий экономия на CDN может составлять до 2 млн рублей. Реализуется через MPEG-OMAF или кастомный DASH-сервер с информацией о Viewport.

Spatial audio

360-видео без позиционного звука — это полвпечатления. Ambisonics (формат B-format или AmbiX) — пространственный формат, в котором звук автоматически ориентируется под направление взгляда.

На Android — AndroidMediaPlayer + Resonance Audio SDK от Google (встроен в Google Cardboard SDK). На iOS — AVAudioEngine с AVAudioEnvironmentNode для пространственного позиционирования источников.

Unity: пакет com.google.resonance-audio или встроенный Unity Spatial Audio с Ambisonics поддержкой из Audio Settings.

Кеширование и offline

Пользователь хочет смотреть 360-туры без интернета. Предзагрузка: фоновый DownloadManager (Android) / URLSessionDownloadTask (iOS), хранение сегментов HLS на устройстве. Для каталога туров — SQLite с метаданными (preview-frame, длительность, описание) и путями к локальным файлам.

Почему важно качественное отображение 360-видео?

Качество отображения напрямую влияет на восприятие VR. При разрешении ниже 4K глаз различает «сетку» пикселей — это разрушает иллюзию присутствия. Наши инженеры оптимизируют шейдеры для каждого устройства: для iOS используем Metal API, для Android — Vulkan. Это даёт прирост производительности до 40% по сравнению со стандартным OpenGL ES. Кроме того, мы интегрируем адаптивное сжатие текстур (ASTC/ETC2) и мультисэмплинг для сглаживания артефактов. Результат — плавное воспроизведение даже на устройствах трёхлетней давности.

Как мы обеспечиваем бесшовный VR-опыт?

Разработка ведётся с учётом всех аспектов: от рендеринга до ввода/вывода. Мы гарантируем:

  • Адаптивный стриминг с переключением битрейта в зависимости от скорости соединения. Используем HLS и DASH с поддержкой MPEG-OMAF.
  • Viewport-dependent streaming — высокое разрешение только в направлении взгляда, что снижает трафик в 3–5 раз.
  • Spatial audio с помощью Resonance Audio (Android) и AVAudioEnvironmentNode (iOS) — звук автоматически поворачивается за движением головы.
  • Офлайн-режим — предзагрузка сегментов HLS на устройство с кэшированием в SQLite.

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

  • Архитектурная документация (описание компонентов, диаграммы потоков)
  • Настройка CI/CD для автоматических билдов и выкладки в сторах
  • Интеграция с App Store Connect и Google Play Console (включая сертификаты и provisioning profiles)
  • Пост-релизная поддержка в течение месяца (баг-фиксинг, мониторинг крашей через Firebase Crashlytics)
  • Обучение вашей команды работе с плеером (2-3 сессии)

Процесс работы

  1. Аналитика — изучение контента, выбор формата (монокуляр/стерео), целевые устройства.
  2. Проектирование — архитектура плеера, выбор SDK и инструментов.
  3. Разработка — рендеринг, стриминг, spatial audio, кэширование.
  4. Тестирование — на реальных устройствах (Cardboard, Google Daydream, Gear VR) с замером latency и motion sickness.
  5. Деплой — публикация в сторах, настройка краш-репортинга (Firebase Crashlytics).
Этап Длительность Результат
Аналитика 2–3 дня Техническое задание
Проектирование 3–5 дней Архитектура и прототип
Разработка 2–4 недели Рабочий плеер
Тестирование 1 неделя Отчёт о багах и оптимизация
Деплой 2 дня Приложение в сторах

Ориентиры по срокам

Базовый плеер для монокулярного 360-видео с локальным воспроизведением — от 1 недели. Полнофункциональный плеер со стримингом, spatial audio, стереоскопическим форматом и offline — от 3 до 6 недель. Стоимость рассчитывается индивидуально после анализа вашего контента и требований. Закажите разработку VR-приложения — и ваши пользователи увидят 360-контент без компромиссов. Получите консультацию для оценки проекта.

Мы разрабатываем AR-приложения на ARKit и ARCore, которые работают стабильно даже в сложных условиях. Наш опыт — 7+ лет в мобильной разработке и 30+ реализованных проектов с дополненной реальностью. Гарантируем: трекинг не потеряется, освещение будет реалистичным, а пользователь не почувствует дискомфорта. Сертифицированные разработчики Apple и Google.

Почему трекинг теряется и как это исправить?

ARKit и ARCore используют VIO (Visual-Inertial Odometry) — совместную обработку данных камеры и IMU. Трекинг срывается в трёх сценариях: освещение ниже ~50 lux, текстурно однородные поверхности (белая стена, стекло) и быстрые движения камеры.

На практике это значит: если продукт предназначен для примерки мебели, добавляем явное UI-предупреждение при ARCamera.TrackingState.limited(.insufficientFeatures). Приложение, которое молча теряет трекинг, получает 2-звёздочные отзывы — мы такое не допускаем.

Обнаружение плоскостей настраивается через ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Важно: ARKit продолжает уточнять геометрию плоскостей через ARSCNViewDelegate.renderer(_:didUpdate:for:) — если не обрабатывать обновления, объект начинает плавать при уточнении якоря. Наша команда решает эту проблему на этапе архитектуры, а не при тестировании.

AR Foundation: кросс-платформа с нюансами

Unity AR Foundation — слой абстракции поверх ARKit и ARCore. Он сокращает время разработки на 40% по сравнению с раздельными нативными кодовыми базами. Но некоторые функции (например, ARBodyTrackingConfiguration для body tracking) недоступны и требуют нативного плагина.

Для React Native и Flutter прямой AR Foundation отсутствует. Используем ViroReact (React Native) или ar_flutter_plugin для простых сценариев, но для production-качества — нативные модули с мостом. Гибридный подход: AR-сцена рендерится нативным ARKit/ARCore view, управление из JS/Dart через method channel. Входит в нашу стандартную поставку.

Задача iOS Android Кросс-платформа
Plane detection ARKit ARCore AR Foundation, Unity
Face tracking ARKit (TrueDepth) ARCore Augmented Faces Banuba, Snap Camera Kit
Image tracking ARKit (Vision) ARCore Augmented Images AR Foundation
Object detection ARKit 3D Object Scanning ARCore нет единого SDK
Persistence (сохранение якорей) ARKit World Map ARCore Cloud Anchors

Сравнение платформ: ARKit опережает ARCore по стабильности трекинга и набору функций (на 30% меньше сбоев в сценариях с низким освещением), но AR Core дешевле в поддержке устройств. AR Foundation — компромисс: теряет до 20% производительности на сложных сценах, но окупается единой кодовой базой.

Try-on: примерка товаров через AR

Примерка очков, украшений, косметики — отдельный класс задач. Здесь нужен face tracking, а не plane detection.

ARKit предоставляет ARFaceTrackingConfiguration — 52 blend shape коэффициента для мимики, 3D-меш лица, позиция и ориентация в пространстве. Работает только на устройствах с TrueDepth-камерой (iPhone с Face ID).

Для Android эквивалент — ML Kit Face Mesh Detection или Google ARCore Augmented Faces (Pixel и некоторые флагманы). Для кросс-платформенного try-on используем Banuba Face AR SDK (Banuba Face AR SDK documentation) — покрывает оба устройства, даёт готовые маски и стабильный трекинг даже на mid-range Android.

Качество try-on критически зависит от 3D-моделей товаров. Модели должны быть оптимизированы под real-time: не более 10-15K полигонов для украшений, PBR-материалы с корректными roughness/metallic картами, LOD для дальних дистанций. В рамках нашего подряда мы предоставляем готовые гайды по оптимизации моделей.

Как добиться реалистичного освещения в AR?

ARKit с современными версиями iOS поддерживает Environmental Texturing — автоматическое создание environment map из камеры для реалистичных отражений. Включается через ARWorldTrackingConfiguration.environmentTexturing = .automatic. Без этого металлические и стеклянные материалы выглядят пластиково.

ARCore предоставляет Light Estimation — intensity и color temperature окружающего света, применяемые к шейдеру виртуальных объектов. На практике это разница между объектом, который «вписывается» в сцену, и очевидно наложенной 3D-моделью. Мы гарантируем, что финальное изображение не выдаёт виртуальности.

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

  • Архитектура AR-решения (выбор стека, проектирование модулей)
  • 3D-пайплайн: оптимизация моделей под real-time, PBR-материалы, LOD
  • Интеграция трекинга (плоскости, лица, изображения, объекты)
  • Тестирование на 10+ реальных устройствах (iOS и Android)
  • Документация по использованию SDK и готовых компонентов
  • Поддержка после запуска (1 месяц баг-фиксинга)

Сроки и оценка

Простая AR-сцена с размещением одной 3D-модели на плоскости — 1–2 недели. Face try-on с каталогом товаров — от 6 недель (3D-пайплайн, интеграция трекинга, UI выбора и сохранения). Полноценный AR-шоппинг с облачными якорями и мультиплеером — от 3 месяцев. Оценим проект за 1 день — пишите, обсудим вашу AR-идею.