Розробка мобільного AR-додатка для музею

Розробка мобільного AR-додатка для музею

Уявіть: відвідувач наводить камеру на вітрину, але скло бликує, маркер не детектується, AR-об'єкт стрибає. У музеї — нерівномірне освітлення, старі iPhone 8 з обмеженим ARKit, черга відвідувачів, що перевантажують Wi-Fi. Наш підхід — побудувати AR-додаток, який залишається надійним у цих умовах. Інакше відвідувач розчарується, а музей втратить інвестиції.

За 7 років ми реалізували 15+ проєктів для музеїв та виставок. Кожен вимагав індивідуального рішення: від калібрування маркерів під вітринним склом до оптимізації 3D-моделей під слабкі пристрої. Правильно спроєктований музейний AR — це не просто анімація на експонаті. Це інтеграція з експозицією, навігація залами, офлайн-режим та доступність для всіх вікових груп. Ми гарантуємо, що додаток працюватиме на пристроях відвідувачів, включаючи моделі п'ятирічної давності (iPhone 8 і вище), і не втратить стабільність при переповненому Wi-Fi. За статистикою, близько 30% відвідувачів залишають додаток через погану роботу AR — ми прагнемо звести цей відтік до нуля.

Як обрати технологію трекінгу для музею?

Два базові сценарії визначають архітектурний вибір: Image Tracking — наводиш на експонат або табличку, з'являється доповнений контент. ARImageTrackingConfiguration простіший, не потребує plane detection, працює через скло вітрини (якщо немає сильних відбиттів). Обмеження: потрібні фізичні маркери або високотекстурні зображення. Location + Plane Detection — навігація залом з AR-путівником. ARWorldTrackingConfiguration + ARGeoAnchor (для вулиці) або власна indoor positioning через Bluetooth Beacon / UWB. Складніше, але дає свободу переміщення.

На практиці в музеях використовують гібрид: image tracking для активації контенту біля конкретних експонатів, plane detection + beacons для навігації між залами.

Image Tracking: деталі реалізації

Кожен AR-маркер — це ARReferenceImage з параметром physicalSize (реальний розмір зображення в метрах). Неправильний physicalSize → ARKit невірно оцінює відстань → контент з'являється в неправильній позиції.

let referenceImage = ARReferenceImage(cgImage, orientation: .up, physicalWidth: 0.15) // 15 см

ARImageTrackingConfiguration.maximumNumberOfTrackedImages — обмеження на одночасно відстежувані зображення. Максимум: 4–8 (залежить від пристрою). У залі з 50 експонатами не можна завантажити всі 50 одразу. Рішення: proximity detection через Bluetooth Beacons — активуємо трекінг лише для найближчих 5–6 маркерів.

Якість маркерів: ARReferenceImage.validate() перевіряє гістограму контрасту. Таблички з дрібним текстом на білому фоні — погані маркери. Рішення: спеціальний QR-код поруч з табличкою (висока унікальність) або нанесення невидимого UV-маркера на рамку експоната.

Чому офлайн-робота критична для музейного AR?

У музеях часто немає Wi-Fi у залах або він перевантажений. Всі AR-ресурси мають бути доступні офлайн. Стратегія: при першому запуску (або при підключенні до Wi-Fi) — фонове завантаження контенту для поточної експозиції. BackgroundTasks framework для iOS, WorkManager для Android.

Розмір пакету контенту: 20–100 МБ на експозицію — допустимо для одноразового завантаження перед візитом.

Контент: від 3D-моделей до відео

Музейний AR-контент — це не просто 3D-об'єкт. Типовий набір для одного експоната:

• 3D-реконструкція (як виглядав повністю, у кольорі — наприклад, антична статуя)
• Анотації з фактами (hotspots)
• Анімація (рух механізму, процес створення)
• Відеофрагмент (архівна зйомка, інтерв'ю з куратором)

AR-відео поверх експоната — через VideoMaterial в RealityKit:

let videoURL = Bundle.main.url(forResource: "artifact_story", withExtension: "mp4")!
let player = AVPlayer(url: videoURL)
let videoMaterial = VideoMaterial(avPlayer: player)
planeEntity.model?.materials = [videoMaterial]
player.play()

Як ми забезпечуємо доступність для всіх пристроїв?

Музей — публічний заклад. Додаток має працювати для аудиторії від 8 до 80 років, на пристроях відвідувачів (не виданих музеєм), у тому числі старих. Мінімальні вимоги до пристроїв: iOS 14+ (ARKit 4), Android 8.0+ з ARCore. Реальний мінімум — iPhone 8 / iOS 14. Dynamic Type для підписів у AR — через UIFont.preferredFont(forTextStyle:). Користувачі з великим шрифтом системи мають бачити читабельні анотації. Аудіогід як заміна AR — для користувачів без сумісних пристроїв або з обмеженим зором: кнопка «Послухати» на кожному експонаті без необхідності AR.

Покроковий процес розробки AR-додатка

1. Аудит експозиції та вибір типу трекінгу — аналіз освітлення, вітрин, розміру залів, кількості експонатів.
2. Проєктування архітектури AR — створення схеми маркерів, налаштування ARReferenceImage, тестування в умовах музею.
3. Розробка iOS та Android версій — Swift + ARKit для iOS, Kotlin + ARCore для Android. Єдина логіка на C++ для розрахунків.
4. Інтеграція з музейною CMS — REST API до Axiell, MuseumPlus або кастомної CMS. Адмін-панель для оновлення контенту без перевипуску додатка.
5. Налаштування офлайн-завантаження та кешування — BackgroundTasks / WorkManager, асинхронне завантаження 3D-моделей та відео.
6. Тестування на пристроях відвідувачів — оренда iPhone 8, 11, 13 та Android-пристроїв різних виробників.
7. Публікація в App Store та Google Play — підготовка метаданих, скріншотів, проходження рев'ю.
8. Документація та навчання кураторів — інструкції з оновлення контенту та роботи з адмін-панеллю.
9. Гарантійна підтримка 6 місяців — виправлення помилок, оновлення під нові версії ОС.

Інтеграція з музейною системою

CMS музею (зазвичай Axiell, MuseumPlus або кастомна) зберігає дані експонатів: інвентарні номери, тексти, зображення. Інтеграція через REST API: при скануванні маркера — запит за інвентарним номером → отримуємо текст, мультимедіа. Кешуємо локально.

Для редагування AR-контенту без розробників — admin panel: куратор завантажує 3D-модель, відео, текст → вони прив'язуються до інвентарного номера → при наступній синхронізації додатка відвідувачі бачать оновлений контент.

Кейс: історичний музей, 120 експонатів

Історичний музей, 3 тематичні зали, 120 експонатів. Image tracking на QR-кодах поруч з табличками (100 маркерів активних одночасно через lazy loading). Контент: 3D-реконструкції для 30 ключових експонатів, текстові анотації для решти. Інтеграція з MuseumPlus через REST API. Офлайн-кеш при вході в зал через BLE beacons. Головна проблема: вітринне скло з anti-reflective покриттям спотворювало AR-трекінг. Рішення: маркери винесли на зовнішні бокові поверхні вітрин, а не за скло. Основний фреймворк — ARKit від Apple, що забезпечує точний image tracking та plane detection. Apple ARKit Documentation

Що входить в роботу

• Проєктування архітектури AR-трекінгу під конкретну експозицію
• Створення AR-маркерів та тестування в умовах музею
• Розробка iOS (Swift, ARKit) та Android (Kotlin, ARCore) версій
• Інтеграція з музейною CMS (REST API) та адмін-панеллю для контенту
• Налаштування офлайн-завантаження та кешування
• Тестування на пристроях відвідувачів (iPhone 8+, Android 8+)
• Публікація в App Store та Google Play
• Документація та навчання кураторів
• Гарантійна підтримка 6 місяців

Строки орієнтовно

Вартість розробки розраховується індивідуально після аналізу експозиції. Image tracking швидший у реалізації, але потребує фізичних маркерів; location-based навігація довша, але дає більше інтерактиву. Гібридний підхід часто виявляється оптимальним за співвідношенням витрат та ефекту. Зв'яжіться з нами для консультації — ми оцінимо ваш проєкт і запропонуємо рішення. Замовте розробку AR-додатка під ключ, щоб ваші експонати ожили та привабили більше відвідувачів.

Ми розробляємо 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. Входить у нашу стандартну поставку.

Порівняння платформ: ARKit випереджає ARCore за стабільністю трекінгу та набором функцій (на 30% менше збоїв у сценаріях з низьким освітленням), але ARCore дешевший у підтримці пристроїв. 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 — покриває обидва пристрої, дає готові маски та стабільний трекінг навіть на 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-ідею.