Разработка мобильного VR-приложения для виртуальных туров

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

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

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

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Разработка мобильного VR-приложения для виртуальных туров
Сложный
от 2 недель до 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

Представьте: пользователь открывает ваше приложение, надевает Cardboard и оказывается в центре виртуального тура по дому. Он смотрит влево — кухня, вправо — гостиная, задерживает взгляд на телевизоре — всплывает спецификация. Но реальность мобильной VR-разработки — это борьба за каждую миллисекунду задержки head tracking и управление десятками 360-панорам высокого разрешения. Мы проектируем архитектуру, где latency стабильно ниже 20 мс, а контент обновляется на лету без релиза в App Store.

Готовы взяться за ваш проект под ключ: зафиксируйте требования, а мы предложим оптимальный стек — от Unity до нативного Metal или Vulkan. Типовой тур с 10-15 сценами и навигацией — 2–3 недели работы. Оценим вашу задачу за один день.

Проблемы, которые мы решаем

  • Задержка head tracking в VR. Используем нативный рендеринг (Metal на iOS, Vulkan на Android) с прямым доступом к IMU. На практике latency стабильно ниже 20 мс — в 3-5 раз лучше WebView.
  • Долгая загрузка панорам. Предзагрузка соседних сцен в фоне, сжатие текстур до 8K JPEG с поддержкой mipmap. Типичная экономия времени загрузки — 40%.
  • Сложность обновления контента. Встраиваем CMS или конфиг на CDN — новые туры появляются через пару минут после редактирования, без повторной аттестации в магазинах. Экономия бюджета на поддержке — до 50%.

Благодаря 7+ годам опыта и 50+ реализованным проектам мы гарантируем стабильную работу на устройствах от iPhone SE до Galaxy S24.

Как устроен граф сцен для VR-тура?

Тур — это граф. Каждая точка (node) — 360-панорама или 3D-сцена. Рёбра графа — переходы (hotspots). Данные хранятся в JSON-конфиге:

{
  "tour_id": "apartment_demo",
  "start_node": "living_room",
  "nodes": [
    {
      "id": "living_room",
      "type": "equirectangular",
      "media_url": "scenes/living_room_8k.jpg",
      "hotspots": [
        { "id": "to_kitchen", "target_node": "kitchen",
          "position": { "yaw": -45, "pitch": -10 },
          "label": "Кухня" },
        { "id": "info_tv", "type": "info",
          "position": { "yaw": 20, "pitch": 5 },
          "content": "Samsung QLED 65\"" }
      ]
    }
  ]
}

Клиентская часть загружает граф при старте, предзагружает медиа соседних нод. Для offline-режима — кеширование выбранных туров с проверкой версии конфига.

Какой рендерер выбрать: WebView или нативный?

Критерий WebView (Three.js) Нативный (Metal/Vulkan)
Задержка head tracking 50–100 мс (зависит от WebView) <20 мс (прямой доступ к IMU)
Поддержка Cardboard VR Нет Полная
Скорость обновления контента Мгновенно (серверный) Требуется релиз при смене движка
Производительность Средняя (WebGL) Высокая (оптимизация под GPU)
Сложность разработки Низкая (HTML/JS) Высокая (Metal/Vulkan/Unity)

Для полноценного VR в Cardboard VR нативный рендеринг в 3-5 раз лучше по качеству трекинга. Если VR не требуется, WebView достаточно и быстрее в разработке.

Как обеспечить плавные переходы между сценами?

Жёсткий jump между 360-сценами создаёт дискомфорт в VR. Мы используем один из трёх подходов:

Тип перехода Описание VR comfort Сложность
Fade to black Fade за 0.5 с, стандарт Google VR Design Guidelines Высокий Низкая
Fade + scale Сцена уменьшается/увеличивается Средний Средняя
Video transition Короткий ролик «прохода» Высокий Высокая

teleportation через fade — standard для VR. На non-VR платформах часто используем fade+scale, экономящий время съёмки.

// Unity: корутина перехода с fade
IEnumerator TransitionToScene(string targetNodeId) {
    yield return StartCoroutine(FadeOut(duration: 0.5f));
    LoadScene(targetNodeId);
    yield return StartCoroutine(FadeIn(duration: 0.5f));
}

Интерактивные hotspots: типы и реализация

Hotspot в пространстве — это raycast из центра взгляда + gaze dwell activation (удержание взгляда 1-2 секунды). Поддерживаемые типы:

  • Navigation — переход в другую точку.
  • Info panel — всплывающая карточка с текстом/фото/видео.
  • Media — воспроизведение видео на поверхности (TV в интерьере).
  • Link — открытие браузера для внешнего действия (забронировать, купить).

Hotspot рендерится в world space на Billboard, всегда повёрнут к камере. Масштаб — constant apparent size через transform.LookAt(camera) + scale = distance * constant.

Как интегрировать CMS для обновления контента без релиза?

Туры должны обновляться без повторной выкладки в магазины. Мы интегрируем админ-панель или храним конфиги на CDN. Приложение загружает актуальный граф при старте, для офлайна — кеширование с версионированием. Экономия на поддержке — до 50% по сравнению с частыми релизами.

Что входит в разработку (deliverables)

  • Архитектурный документ с графом сцен и типами hotspots.
  • Исходный код с документацией и CI/CD.
  • Инструкция по обновлению контента через CMS или конфиг.
  • Тестирование на 5+ реальных устройствах (iPhone, Android).
  • Гарантия 3 месяца на выявленные баги.

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

  1. Аудит контента — определяем тип медиа (фото/видео/3D), количество сцен, требования к обновлению.
  2. Проектирование — создаём граф сцен, выбираем рендерер и схему переходов.
  3. Разработка — реализуем рендеринг панорам, head tracking, взаимодействие с hotspots, переходы.
  4. CMS-интеграция — подключаем систему обновления контента без релиза.
  5. Тестирование — оцениваем качество head tracking в режиме Cardboard, производительность на budget-устройствах.

Ориентировочные сроки

  • Базовое приложение для одного тура с фото-панорамами и навигационными hotspots — 2-3 недели.
  • Полноценная платформа с CMS, несколькими типами hotspots, offline-режимом и Cardboard VR — 2-3 месяца.

Свяжитесь с нами для точной оценки вашего проекта. Закажите консультацию — мы поможем выбрать оптимальный стек и предложим прозрачное ценообразование.

Мы разрабатываем 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-идею.