Уявіть: користувач відкриває ваш додаток, одягає 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 місяці на виявлені баги.
Процес роботи
- Аудит контенту — визначаємо тип медіа (фото/відео/3D), кількість сцен, вимоги до оновлення.
- Проектування — створюємо граф сцен, обираємо рендерер та схему переходів.
- Розробка — реалізуємо рендеринг панорам, head tracking, взаємодію з hotspots, переходи.
- CMS-інтеграція — підключаємо систему оновлення контенту без релізу.
- Тестування — оцінюємо якість head tracking у режимі Cardboard, продуктивність на бюджетних пристроях.
Орієнтовні терміни
- Базовий додаток для одного туру з фото-панорамами та навігаційними hotspots — 2-3 тижні.
- Повноцінна платформа з CMS, кількома типами hotspots, offline-режимом та Cardboard VR — 2-3 місяці.
Зв'яжіться з нами для точної оцінки вашого проєкту. Замовте консультацію — ми допоможемо обрати оптимальний стек і запропонуємо прозоре ціноутворення.