Пост про вычислительную фотографию закончился на мысли о том, что массовая фотография уже потихоньку пытается «улучшать» реальность, дорисовывания наши мыльные селфи машинным обучением. Маски заменяют угрюмые лица, на серое небо наклеивают красивые облачка, а цветные фильтры делают скучную жизнь как бы чуть лучше, чем у соседа. А это же главное.

Мы называем это Дополненной Реальностью, Augmented Reality или AR — когда окружающий мир вокруг смешивается с виртуальными объектами вплоть до полной его замены.

Сейчас AR прошёл свою долину разочарования. Бегущие за хайпом временно про него забыли, стартапы-пустышки посхлопывались, а умненькие ребята плотно подсели на жирненькие B2B контракты и выращивают там свои волноводы за миллионы денег.

Дальше два пути — либо польза, либо забвение. Никто сейчас не уверен какой из них выберет AR. Потому самое время остановиться и разобраться в технологиях, которые стоят за всем этим, а иногда даже работают (нет).

Чтобы избежать очередных сказок про виртуальные корабли, бороздящие просторы вселенных, которыми полны все статьи про AR, я нашёл и допросил настоящих разработчиков, которые своими руками разрабатывают описанные ниже штуки и решают с их помощью реальные боевые проблемы.

Так что там, где написана правда — это они рассказали, а где наглое враньё — это глупый Вастрик навыдумывал. Ну и это лишь первая версия поста, так что в ней всегда будут неточности.

По ходу рассказа я буду давать ссылки на хорошие 💎 статьи, выделяя их всякими глупыми эмодзи. Обычно это либо первоисточники, либо рекомендованные к ознакомлению тексты для тех, кто хочет закопаться глубже. По понятным причинам я не могу погружаться максимально глубоко в каждую тему.

📔 Скачать pdf, epub, mobi
удобно для офлайн-чтения ❤️ Поддержать автора

Для начала быстренько разберёмся в терминологии. Что есть дополненная реальность и чем она отличается от виртуальной и почему их так часто употребляют вместе?

Я буду использовать классическое определение, согласно которому всё это является лишь разной степенью смешения реального мира и виртуального. Например, мир видеоигры, где вы спасаете принцессу, сидя верхом на тиранозавре — это виртуальная реальность. Мир же, где вы идёте в «Пятёрочку» чтобы взять шесть пивчиков по акции — это объективная реальность.

Дополненная — где-то между.

Потом пришли маркетологи Microsoft и начали называть всё подряд Mixed Reality, потом был Qualcomm со своим Extended Reality, а потом все нахер переругались и вернулись к классической картинке выше.

Техническая разница между дополненной и виртуальной реальностью сегодня не такая большая, как может показаться. Современные VR и AR-шлемы используют похожие методы трекинга положения в пространстве, а некоторые вообще начинают смешивать реальности, как тот же Oculus Quest, который переключает вашу игру на вид с камер, если вы вдруг вышли из игровой зоны и можете неприятно стукнуться мизинчиком о ножку дивана.

Так что в этом посте я буду постоянно смешивать AR, VR, MR, и даже роботы-пылесосы, которые используют те же самые алгоритмы. Потому что технологии.

💎 The Ultimate VR, AR, MR Guide

Сразу отбросим всякую эзотерику типа получения голограммы на искусственном тумане, проецирования изображения на физический объект, быстрого вращения LED'ов и прочих киберпанк-линз.

Об этом всём приятно помечтать, иногда оно даже работает, но прогресс сейчас не там.

Посмотрим на реальные типы экранов, которые применяются в AR/VR-шлемах прямо сейчас. Актуально на 2020 год, но с учетом динамики, года три еще такой расклад продержится.

Итак, сейчас есть два больших фандома — видео и оптические дисплеи. В первом случае вы смотрите на видео с камер, а во втором — видите реальность с хитро наложенной поверх голограммой.

Оба варианта имеют свои плюсы и минусы.

Включите камеру на телефоне и поднесите экран к глазам. Поздравляю, вы в киберпанке.

Чаще всего это VR-шлем с несколькими камерами. Камеры снимают окружающий мир и транслируют обработанное видео вам в глаз. Реальности вы не видите, только экраны перед глазами.

На данном этапе развития технологий, именно у видео-дисплеев самый большой вау-фактор для простого обывателя. Потому их обожают показывать на презентациях и в видеороликах.

Из популярных можно вспомнить:

✅ Проще, понятнее и дешевле. Не нужны дополнительные камеры для трекинга положения плюс у нас давно есть все технологии для работы с видео.

✅ Лучше трекинг и иллюзия реальности. Картинка не разваливается на части когда чихнул или сдвинул очки.

✅ Почти нет проблем с калибровкой. Любой человек может надеть шлем и начать им пользоваться, ничего не настраивая.

💩 Качество видео ниже, чем у реальности. Сегодня у нас нет таких экранов, где бы нас устраивало и разрешение, и FPS.

💩 Лаг в прямом смысле может вас убить. Представьте, что ведёте машину в таком шлеме и тут он на секунду зависает. Или пилите доску циркулярной пилой. Ууух.

💩 Тошнит. В прямом смысле.

💩 Только одна фокальная плоскость. Нужны дополнительные костыли чтобы отличать когда пользователь смотрит прямо перед собой или вдаль на 100 метров.

💩 Требуется дикая пропускная способность. Слать картинки в каждый глаз с разрешением в несколько 4К телевизоров не так-то просто. Вот вам ящик с пятью жифорсами и провод, толщиной с палец.

Трекинг положения глаз уже есть у всех взрослых ребят. Две маленькие камеры смотрят на ваши зрачки и определяют на какую часть виртуального мира вы смотрите чтобы корректировать фокусное расстояние.

Один из перспективных чит-кодов, хитро использующий особенности нашего зрения. Как оказалось, наш мозг достаточно ленив, и воспринимает только небольшую часть «кадра» в высоком разрешении, а всё вокруг может быть хоть в десятикратном размытии — ему насрать. Хоть генерируй фоны нейросетками — он не поймёт.

Сегодня Foveated Rendering в основном показывают на выставках, но скоро он дойдёт и до реальных устройств. Возможно.

🎥 Improving VR with NVIDIA’s Foveated Rendering

Он же True AR в некоторых источниках.

Вы смотрите на реальность как будто через обычные очки, а сверху вам накладывают дополнительную картинку с помощью полупрозрачных зеркал, призм, отражающих плёнок, волноводов или чего там еще потом изобретут.

Владельцы новых автомобилей с проекцией на лобовое стекло примерно представляют как это выглядит. Профессиональные шлемы отличаются разве что качеством графики.

Самые известные представители — это, естественно, HoloLens, Google Glass и Magic Leap.

✅ Пользователь не уходит из реальности. Со всеми вытекающими — безопасность, отсутствие лага, социальная приемлемость, и.т.д. Можно водить и делать другую важную работу.

✅ Не надо заново изобретать зрение. Можно не городить костыли для фокуса или управления яркостью. Не тошнит — тоже плюс.

✅ Энергопотребление и спящий режим. Экраны могут выключаться и просыпаться когда надо, не превращая реальность в чёрный квадрат.

💩 Маленький угол обзора (FOV). Картинка занимает в среднем 35° от привычных глазу ~200° (окей, 130-150° если брать рабочие зоны).

💩 Часто требуют индивидуальной калибровки. Проекция настолько крохотная, что её надо проецировать чётко в зрачок. Поэтому некоторые гаджеты вообще изготавливаются на заводе под межзрачковое расстояние конкретного пользователя. Удачи с продажей на авито.

💩 Очень чувствительны. Даже волос с чёлки, упавший на линзу очков, может сломать всю картинку.

💩 Яркость. Всё еще отвратительна даже у топовых моделей.

💩 Блики. Волноводы и поляризационные решетки очень неприятно бликуют. Взять тот же HoloLens, где всех это прям бесит.

👉 Google Glass и сотни его клонов

Обычный проектор (LCoS) светит на призму, которая отражает всё это дело вам в глаз. Дешево и сердито. Как экран телесуфлёра, с которого диктор читает новости.

Проблема лишь в том, что большую призму в очки не поставишь, потому изображение всегда получается мелким. Или же? 🤔

👉 ODG, Rokid Glass, Nreal Light

Реализация идеи «а давайте всё-таки как-то впиндюрим огромные призмы». Только вместо призмы вставили полупрозрачное зеркало и огромные отражающие полусферы, которые кому-то напомнили ванночки, эээ, для купания птиц, потому их назвали birdbath.

Наверняка британцы придумали, там лорды от скуки не на такое способны.

Большим их плюсом было, что они работали с любым OLED-дисплеем, а не только проекторами. Остальное, к сожалению, было минусами.

Сейчас такие очки почти все вымерли. Только китайцы с Али продают их копии из пластика, где можно вставить телефон и ощутить, что опять просрал тридцать баксов.

💎 How Augmented Reality Headsets Work: Diving into Different Optical Designs

👉 Hololens, Magic Leap, Rokid Vision, Vuzix Blade

Сегодня волноводы считаются самой ходовой технологией.

Волновод делает ровно то, что вы подумали — проводит один луч света от источника по хитрой траектории в нужное место на линзе ваших очков.

Работает он по принципу оптволокна. Свет входит с одного конца и выходит с другого потому что весь отражается от стенок внутри. Если при этом посмотреть на оптволокно сбоку — оно полупрозрачно и света внутри вы не увидите.

То же самое представляет собой и линза AR-очков с волноводами внутри — куча каналов для света и призмочек для их отражения в глаз. Microsoft в презентациях HoloLens гордо заявляет, что «направляет каждый фотон света в нужное место глаза», что звучит громко и круто. Пока не попробуешь в живую.

Самая главная проблема волноводов на данный момент: их очень сложно выращивать. Процент брака на заводах огромный, повторяемость никакая, потому и шлемы стоят так дорого. На один хороший приходится штук пять, которые просто выбросили.

💎 Understanding Waveguide: the Key Technology for AR Near-eye Display

👉 North Focals, Bosch Sensortec, Intel Vaunt ☠️

Если волноводы — наше настоящее, то LBS пророчат роль будущего. В нём быстро бегающий лазер по синусоиде рисует вам картинку прямо в глаз.

Очень похоже на принцип старых ЭЛТ-телевизоров. Там тоже пучок электронов отклонялся магнитным полем и рисовал на экране полосочки. Здесь же тонкий луч света отклоняется миниатюрным MEMS-зеркалом и светит в нужное место специальной плёночки на очках, откуда потом отражается вам в глаз.

Никаких дорогих волноводов. Бери любые очки, клей плёнку, калибруй и используй. Пока такие гаджеты только начинают появляться и у них большие проблемы с картинкой. Intel вообще был монохромный.

Но их простота, универсальность и теоретическая дешевизна технологии как бы намекают, что очки Apple могут быть именно такие.

Их проблема лишь в том, что там нет AR. Пока это всё лишь очки с уведомлениями.

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

Поэтому для B2C чаще всего берут видео-решения. Сейчас вообще на любом телефоне в них можно.

Однако, всегда есть ребятки из Boeing и Lockheed Martin, у которых свои уникальные проблемы. Например, что в каждом их самолёте тысячи проводов и каждое соединение должны проверить минимум пять человек. Экономия даже одной секунды на провод — это минус тысяча человекочасов и миллион вечнозелёных президентов.

Потому HoloLens с Magic Leap быстренько увидели нишу, оцифровали схемы самолётов и дали Боингам очки, которые по голосовой команде «покажи провод AB713H-21» показывают где он должен идти, какие дырки сверлить и в какой коннектор его пихать. У видео-шлемов тут не было бы шансов.

Рыночек. На эту тему даже местная шутка есть: AR-очки всегда начинаются как RayBan, а приходят к HoloLens.

С экранами разобрались, теперь к алгоритмам.

Первая задача, которую надо решать, когда ты VR или AR-шлем: определение положения самого себя в пространстве по шести степеням свободы (три оси вращения и три перемещения). Коротко это называется трекинг.

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

Проблему обычно решали в обход. Сначала были дедовские методы.

Трекинг по специально распечатанным картинкам-маркерам работал еще на моей Нокии на Симбиане. Сегодня им разве что бабушек 1748 года рождения удивлять, хотя в некоторых юзкейсах он всё еще опережает по точности остальные жалкие хипстерские варианты. Например, если вы делаете AR-настолки или AR-инсталляции в музее.

Недалеко от него ушел трекинг по внешним датчикам. Когда надо расставить по комнате несколько камер как у Oculus Rift или пассивных инфракрасных маяков как на HTC Vive, чтобы по ним вычислять положение игрока в комнате.

Знакомый переставлял шкаф в комнате ради золота в Beat Saber. Вот это UX.

Настоящее же решение проблемы пришло когда появился SLAM.

Представьте, что вы оказались на центральной площади незнакомого вам города и вам дали задачу нарисовать его карту. Ваши действия?

Скорее всего вы начнёте бродить по улицам, отмечая для себя запоминающиеся объекты типа домов, памятников и названий улиц. Одновременно вы будете рисовать пройденные улицы карте, а когда вернулись на то место, где уже были — соединять их.

Чтобы совсем не потеряться, можно еще фотографировать на телефон некоторые улицы, чтобы потом точно знать, что уже проходил этот перекрёсток.

Вот SLAM работает точно так же. Он находит по видео контрольные точки, определяет относительно них своё положение, а потом наносит их на свою внутреннюю карту мира, постоянно её корректируя.

Фотографии перекрёстков здесь тоже есть. Они называются ключевыми кадрами (Key Frame) и используются ровно для того же самого — чтобы когда потерялся быстро понять видел ли ты уже это место или то была другая похожая улица.

Ключевые кадры еще сильно пригодятся нам попозже, когда будем 3D-реконструкцию мира и предсказывать освещение. Такие вот мы наркоманы.

SLAM — это не один алгоритм, а общее название для любых алгоритмов, которые рассчитывают карту и положение на ней, находясь как бы «внутри» наблюдателя. Так-то их дофига.

SLAM используется в AR/VR-шлемах, в самодвижущихся машинках, и даже в вашем роботе-пылесосе

У каждой большой компании есть свой запатентованный, которым она ни с кем не делится, но мы-то все понимаем, что там просто больше датчиков и тщательная калибровка под своё железо. Ничего принципиально нового.

Вот, например, патент гугла где схематично рассказывают нам ту же историю. У Apple есть свой VIO и даже лекция с WWDC, где они рассказывают о нём в картинках.

В опенсорсе есть алгоритм ORB-SLAM2, который хорош и в него бросают новичков чтобы учились.

💎 Basics of AR: SLAM – Simultaneous Localization and Mapping
💎 Past, Present, and Future of SLAM: Towards the Robust-Perception Age (2016)

Результатом работы SLAM может быть как «плотная» (dense), так и «разреженная» (sparse) карта. По аналогии с картой города: разреженная — это когда вы отметили только ключевые объекты на улицах, а плотная — когда вы зарисовали каждый дом вплоть до количества окон.

Или когда вы ночью крадётесь в туалет, вы не видите всех деталей интерьера, но мозг успешно доводит вас по «чекпоинтам». Вот это sparse-карта.

Обе карты на самом деле бывают полезны.

Если абстрагироваться от священных войн фанатов разных алгоритмов: разреженная карта лучше подходит для трекинга и мультиплеера, потому что в ней меньше точек, а плотная лучше для рендеринга, расчёта перекрытия объектов (occlusion) и освещения, о чём мы будем много говорить далее.

Так что не дайте себя одурачить и просто запомните, что полезно и то, и другое, но в разное время.

Вернёмся к алгоритмам.

Для сбора данных об окружающем мире любой уважающий себя SLAM использует любые доступные источники данных.

Среди них:

🧭 Показания сенсоров (IMU). ~1000 fps. Акселерометр, гироскоп, компас — всё сгодится.

Сенсоры нереально быстры, но их главная проблема в накапливающейся со временем погрешности. Они не видят реальности, а лишь «чувствуют» её через ускорения и отклонения, потому предсказание точного местоположения по ним — как если бы я сказал вам, что сделал 20 шагов и попросил бы предсказать сколько метров я прошёл.

Ну и больше шагов — больше погрешность.

🎥 Видео с камер. ~30-60 fps. В современных телефонах камер несколько — это полезно. Широкие объективы вообще очень полезны — они видят больше и по ним получается более стабильный трекинг (одна из причин почему ширики стали так популярны).

Данные с камер вроде как должны быть точнее слепых сенсоров, однако они тоже накапливают погрешность с расстоянием. Хорошая новость в том, что они с сенсорами как бы компенсируют слабые стороны друг друга. Акселерометр деградирует со временем, потому кадр с камеры каждые 0.016 секунды как бы обнуляет его погрешность.

🗜 Датчики глубины. ~30 fps. На Kinect они были давно, на шлемах типа Hololens стоят сейчас, а на смартфонах Time-of-Flight-камеры скоро будут везде. Используются для построения более точной 3D-карты мира и вычисления расстояния до объектов для правильно расчёта их наложений.

GPS, BLE, мох на деревьях и другие системы позиционирования почти не используются из-за их неточности.

Вот примерный порядок шагов, которые вычисляются на каждый кадр.

Картинок-маркеров у нас больше нет, так что придётся находить ориентиры автоматически. Есть три уровня абстракции, как это можно делать:

🛣 Распознавать реальные объекты — дом, дорогу или нос. Такой SLAM называют семантическим и используют только там, где без него никак: для трекинга направления дороги в самоездящей повозке или наложения маски зайчика на лица инфлюенсеров в инстаграме.

В остальных юзкейсах делать распознавание объектов слишком дорого и медленно, хотя многие и верят, что за этим будущее. Топовые AR-фреймворки сегодня умеют распознавать только популярные объекты типа людей, их рук и лиц, но не делают по ним SLAM.

Хотя есть и отчаянные ребята, которые пытаются.

🌇 Выделять особенности окружения. Такой SLAM называется Feature Based и сегодня он самый популярный. Алгоритм ищет характерные куски объектов — края столов, окон, домов, и запоминает их. Обычно берут просто заметные углы с буфером по 30x30 пикселей вокруг — этого хватает. Искать выпуклости вместо углов — тоже популярная затея.

Известные реализации: SIFT, SURF, BRISK, FAST, ORB. Сейчас всё чаще для поиска углов используют простейшие ML-модельки. Они работают даже быстрее.

Ниже я буду рассказывать в основном о Feature Based подходе, так как именно его используют популярные фреймворки.

🎆 Анализировать каждый пиксель. Это называется Direct SLAM и появился он относительно недавно. По сути это Feature Based доведённый до абсурда — мы считаем каждую границу или даже пиксель на изображении его особенностью.

Так мы сразу получаем dense-карту окружения, что плюс, зато теряем возможность быстро сориентироваться в пространстве по ключевым точкам, если вдруг потерялись.

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

Самые известные директ-алгоритмы: DSO и LSD.

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

По сути дескриптор — это хеш или лист дерева, по которому можно быстро найти такой же угол на другом изображении, если рассчитать на нём такие же дескрипторы для всех углов.

Типичная задача индексации и поиска. Как будто телефонный справочник.

Такой матчинг дескрипторов происходит на каждый кадр: алгоритм определяет, ага, вот эти углы мне уже известны, но один сдвинулся на 50 пикселей по экрану вправо, а другой на 100 пикселей влево, потому я щас относительно этого стриангулирую своё новое положение в пространстве.

Обычно на новом кадре 80% дескрипторов нам будет уже известно и особых проблем с вычислениями не возникнет.

Для самых любознательных: один из популярных дескрипторов (SIFT) просто разбивает всё область на клеточки 4x4 пикселя, считает внутри каждой клеточки градиент и строит гистограмму. Такая гистограмма достаточно точно характеризует данную нам область, плюс она устойчива к повороту.

💎 OpenCV: Feature Detection and Description
🎥 SD-SLAM ← тут хорошо видно облако точек, ключевые кадры и sparse-карта

Вычислить наиболее вероятное местоположение, имея приблизительные данные о нём из нескольких источников — стандартная задача оптимизации с поиском локального минимума как на третьем курсе универа.

У нас есть показания с датчиков (акселерометр, гироскоп), в которых есть своя накопленная ошибка, плюс посчитанные с камеры визуальные ориентиры с примерным расстоянием до них. Погнали.

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

Решением всех этих уравнений становится самое вероятное положение головы пользователя в пространстве (Ground Truth). Естественно, погрешность тоже считается.

💎 Why is ARKit better than the alternatives?
💎 How is ARCore better than ARKit?

Узнав своё местоположение, можно начать уточнять координаты тех самых контрольных точек в нашем 3D-пространстве, чтобы в следующем кадре позиционироваться относительно них еще точнее.

Как если бы мы сидели посреди комнаты и прикинули: до одной стены примерно три метра, а до другой пять. Потом бы померили эти расстояния, не знаю, локтями, и выяснили, что до одной из стен локтей получается больше в два раза.

Ага, сказали бы мы, значит до этой стены скорее всего шесть метров, а не пять.

Примерно так же прикидывает и SLAM, у которого тоже нет линейки. Такой вот цирк происходит 30-60 раз в секунду.

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

Loop Detection. Определять циклы полезно, ведь когда мы ходим по комнате, то можем снова оказаться на месте, где уже были. Тогда нам нет смысла вычислять карту заново и наслаивать карты миров друг на друга, лучше как-то это понять и продолжать использовать ранее обнаруженные ключевые точки.

Это помогает сделать трекинг стабильнее, карту точнее, а заодно сильно сэкономить память и другие ресурсы. Взамен раз в несколько кадров придётся запускать такую вот дополнительную проверку.

Plane Detection. Когда мы видим, что сразу несколько точек находятся на одной плоскости, да еще и параллельно или перпендикулярно земле (по показаниям датчиков) — мы называем это плоскостью и начинаем считать всё от неё.

Зачем? Потому что это будет полезным костылём для следующего шага — расстановки объектов по сцене.

Выше рассказан весьма оптимистичный случай, но наша жизнь — это в основном боль, так что и наш SLAM однажды может внезапно понять, что не знает где он находится.

В таком случае запускается алгоритм «я потерялся» и начинается релокализация. Откуда-то из буфера выгружаются ключевые кадры и все оставшиеся в памяти контрольные точки. Начинается долгий мучительный процесс поиска знакомых углов на карте чтобы хоть как-то заново локализоваться относительно них.

Мы подробнее поговорим об этом в разделе про мультиплеер, потому что присоединение нового игрока к игре и есть по сути релокализация через контрольные точки другого.

Окей, у нас есть карта окружения, понимание где находится камера, а иногда даже плоскость земли, на которую можно ставить объекты. Всё это — составляющие типичной 3D-сцены, так что мы можем использовать любой популярный движок чтобы рендерить на ней модельки.

Взять тот же Unity. Быстро и просто. Как доширак.

Однако, скорее всего с первого раза получится такое говно:

Как бы ни были круты ваши экраны и алгоритмы трекинга, пользователи такое точно засмеют. Кроме фанатов Pokemon Go, конечно. Те будут в восторге.

Так мы приходим к третьей важнейшей составляющей любого AR — бесшовном рендеринге с предсказанием освещения.

Любой рендер работает со светом и материалами. Материалы задаёт художник при создании 3D-модели, так что с ними проблем нет. С освещением же сложнее.

У нас тут не 3D-игра, где источники света заранее расставлены. Освещение сцены каждый раз зависит от того, где пользователь открыл приложение. Плюс, мы видим окружающий мир лишь с одной точки — из объектива камеры, а объект может стоять где-то за диваном или вообще на другой стороне улицы. Там могут быть абсолютно другие условия освещения. Как быть?

Всем этим и занимается Light Estimation.

Одна из первых идей, которая пришла в голову нашим древним предкам: брать время и геолокацию пользователя и с помощью простейших формул просить показать где солнце. Так будет понятно куда падает тень, а по общей контрастности кадра — насколько она будет мягкой.

Подход, кстати, даже используют до сих пор чисто про запас. Именно поэтому некоторые AR-приложения на вашем телефоне хотят доступ к геолокации.

На улице такое читерство работает отлично, а вот в помещении начинается жопа. Там свет отражается, рассеивается, окрашивается в цвета других объектов, плюс у него бывает сразу несколько источников.

Всё это намного сложнее считать.

Отчаянные доктора наук бросились решать и эту задачу, вычисляя положение ламп по бликам, забрасывая на сцену зеркальные шары или предсказывая длину теней нейросетями. Но всё это было интересно разве что как тема диплома, реальной же пользы никакой.

Хотя, чтобы чувакам не было обидно, их методы назвали «аналитическими» решениями. Чтобы просто потом в каждой статье писать, что «аналитические решения нам здесь как обычно не подходят». Классика.

💎 Realistic Real-Time Outdoor Rendering in Augmented Reality

В любой непонятной ситуации обучай нейронку. Тут всё понятно: тренируем свёрточную сеть выдавать нам карту освещения в точке на посчитанных в 3D примерах или сфотографированных заранее пробах.

Любой школьник с жифорсом сегодня расскажет вам как это делать.

Даже у меня был пост про ML.

💎 Fast Spatially-Varying Indoor Lighting Estimation (2019)

Метод вычисления глобального освещения без дополнительных устройств и гадания на длине теней появился благодаря первому Kinect с его камерами глубины, по которым мы научились быстро вычислять примерные 3D-карты окружения (хоть и в разрешении 640px).

В современном AR здесь нам сильно пригодится dense-карта нашего мира, если на ней достаточно точек чтобы собрать из них модель окружения.

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

Когда у нас есть уравнение, мы всегда можем посчитать его наоборот. Объявив источники света неизвестной величиной, например. В нашем случае это будет означать, что по яркости каждого пикселя нам надо рассчитать откуда и в каком количестве на него пришёл свет. Звучит как то, что нужно.

Правда, как водится в математике, долбанутые обратные уравнения не хотят решаться аналитически. Но мы тут уже не мальчики и в ответ можем подогнать тяжелую артиллерию в виде численных решений систем уравнений и методов Монте Карло.

Грубо говоря, стреляем из пушки десять раз и куда чаще всего попадаем — там скорее всего и находилась цель. Мы, инженеры, обожаем такую фигню.

Собрав таким образом наиболее вероятные решения, мы можем примерно определить где находятся главные источники света и насколько они яркие. Больше проб — точнее, меньше — быстрее. Профит.

Чтобы не запоминать каждый лучик света, а как-то все их красиво упаковать и представить, мы используем такую штуку, как сферические функции (Spherical Harmonics). Ничего страшного в них нет, это просто как гистограмма, которую свернули в пупырчатый шар и записали в виде уравнения.

Думаю, по картинке будет понятно. Направления пупырок как раз и показывают откуда пришёл свет. Сложнее форма — точнее карта освещения, проще — мягче.

Позднее мы даже научились учитывать их цвет. Так, если объект стоит около красной стены — он будет с одной стороны немного окрашиваться в красный из-за отраженного света.

Но это уже совсем хардкор. Не знаю кто сейчас реально так заморачивается. Но мы можем.

Метод активно используется потому что быстр в вычислениях, оптически корректен и позволяет самому выбирать баланс между точностью и скоростью работы. Google в своём ARCore, например, называет это просто и ясно — Environmental HDR Ambient Spherical Harmonics. Кек.

Теперь, когда вы увидите как 3D-объект на AR-сцене плавно меняет яркость при перемещения из света в тень, можете смело заявлять — это делается с помощью сферических гармоник. Очень круто звучит.

💎 Real-Time Photometric Registration from Arbitrary Geometry (2012)
💎 Spherical Harmonic Lighting: The Gritty Details (2013)

Чем больше мы пытаемся в реалистичный рендеринг, тем больше понимаем, что без настоящих кубических карт окружения нам никуда.

Кубическая карта — это как будто мы сфотографировали окружающий нас мир в шести направлениях, из которых потом собрали куб. Такие карты давно используют для моделирования реалистичных отражений, однако в современном AR они ещё очень помогают с предсказанием освещения.

Так что одна из важных фоновых задач для AR-устройства — фиксировать и постоянно уточнять кубическую карту окружения. Здесь подойдут любые лайфхаки: роботам дают фишай-объективы, на шлемы ставят камеры заднего вида, а телефоны по-тихому используют фронтальную камеру чтобы подглядеть вам за спину.

Когда даже этих данных мало — мы опять подключаем нейронки. Примерно как мы делали с картой освещения, только теперь мы дорисовываем ими недостающие части мира вокруг.

Так делает iPhone с ARKit'ом, например. Он просто дорисовывает как выглядит остальная ваша комната вокруг, видя лишь то, что попадает ему в камеру. Всё равно в размытом отражении никто не заметит.

Дальнейшие шаги понятны: если объект хоть немного глянцевый — мы помещаем его в центр кубической карты и рассчитываем как она отражается на модельке.

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

Потому есть сильное подозрение, что все новые фреймворки будут считать освещение только по ним, а расчёт освещения останется в прошлом.

💎 Dynamic Environment Mapping for AR Applications on Mobile Devices (2018)

Рендеринг — процесс получения изображения по 3D-модели с учётом всех условий сцены. В дополненной реальности он мало чем отличается от любой компьютерной игры, так что возможности движков хорошо представляет себе каждый школьник.

Разве что теперь у нас есть прозрачные части сцены, которые не попадают на итоговое изображение. Та же карта мира. Она отражает свет на объекты, а те в свою очередь могут отбрасывать на неё тени, но на итоговом изображении она не видна. На её месте мы ожидаем увидеть объекты реального мира и тогда случится магия.

Быстро вспомним хотя бы базовые составляющие любого рендера и посмотрим как с учётом всех знаний выше проходит их расчёт.

Надо понимать, что в мире AR сегодня делают рендеринг примерно на уровне игр начала 2000-х. Не хватает производительности, да и чаще всего нет смысла. С реалистичным врендюриванием объектов на сцену заморачиваются разве что для получения статичных фото. Вот там можно разгуляться с шейдингом в сто слоёв по полной.

📝 Using ARCore to light models in a scene

Общая освещённость кадра. В популярных фреймворках представляется как два числа: интенсивность света (темно ↔︎ светло) и цветовая температура в кельвинах (сине ↔︎ желто).

Вычисляются оба простым усреднением пикселей последних увиденных кадров, даже особо думать не надо. Они глобальны для всех объектов и по сути задают некую точку отсчёта для дальнейшего рендеринга.

Источники света по сцене вычисляются с помощью обратного рендеринга, как мы выяснили ранее. Можно вычислять освещение для каждого объекта на сцене, что тяжело, либо один раз глобально, а потом просто рендерить один свет на все объекты. Это называется Global Light Estimation и многие сегодня делают только его.

Хотя тот же Microsoft умеет вычислять освещение для каждой вершины объекта. Наркоманы.

В любом случае мы получаем как бы невидимый фонарик, который светит на объект с правильной стороны. Дальше уже дело рендера.

Тени мы получаем как бы в подарок к вычисленным на прошлом шаге источникам света. Дальше берём самые простые и быстрые методы их расчёта, потому что нет смысла заморачиваться с правильными тенями, когда у тебя весь мир и так посчитан с погрешностями.

Тот же Shadow Mapping отлично справляется. Мы как бы ставим себя на место каждого источника света: какие части объектов нам видны с их ракурса — там будет свет, а какие не видны — там тень. Всё просто. Потом наносим всё на одну глобальную карту и вуаля.

Даже в современных AR-движках объекты чаще всего отбрасывают тени только на плоскость под ними, но, думаю, это вопрос времени когда у разработчиков дойдут руки заняться их реалистичностью.

Пока хватает.

Блики и затемнения — две стороны одной медали. Блик получается там, где луч света отражается от объекта прямо нам в камеру. Затемнение — где свет наоборот, отражается куда угодно, но не в камеру.

Оба параметра зависят от свойств объекта и меняются от положения наблюдателя.

На каждый объект накладываются отражения кубической карты мира. На глянцевых он отражается как в зеркале, а матовые просто немного окрашиваются в характерные цвета окружения.

В ARKit такую фичу называют Environment Texturing, у остальных она тоже есть под другими названиями.

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

Вид отражений, когда свет, отразившись от одного объекта, немного окрашивает другой объект в цвет первого.

Реализуется тоже с помощью сферических гармоник, если алгоритм их вычисления умеет в цвета.

Как? Ну, выпускаем из центра объекта случайные лучи во всех направлениях и смотрим с каким первым объектом мира они пересекутся, какого он цвета и на каком расстоянии находится.

Что нас бесит больше всего в AR-приложениях? Вот это:

Абсолютно отвратительно.

Хотя и не отменяет того факта, что IKEA Place — одно из немногих действительно полезных AR-приложений.

Мы-то с вами понимаем, что объекты виртуального мира всегда рисуются поверх реального, но было бы круто если бы они тоже как-то понимали, что между ними и камерой может оказаться что угодно.

Это называется occlusion, что с большим трудом переводимо на русский как «перекрытие».

Выход тут один: нужно искусственно вырезать те куски объектов, которые оказались перекрыты реальными. Так будет создаваться видимость как будто виртуальный кот «ушел» за диван, а не отрендерился поверх.

Еще год-два назад задачу оклюжена не умел решать никто. Сегодня уже появляются первые доступные решения в том же ARCore, работающие в реальном времени. Плюс понимание куда дальше копать и какие сенсоры закупать.

Через пару лет всё станет совсем хорошо.

Она же карта глубины или z-буфер в компьютерной графике. Может быть вычислена по виду с нескольких камер или сразу снята камерой глубины, когда она есть.

Полученная на современном смартфоне с Time-of-Flight или стерео-камерой карта глубины будет выглядеть как-то вот так:

Когда мы рассчитаем по ней все расстояния, аккуратно наложим их на нашу 3D-сцену и вычислим какие объекты оказались перекрыты, результат будет примерно такой:

Мде. Так нас в киберпанк не пустят.

У нас куча проблем. Мобильные камеры глубины, во-первых, имеют очень небольшое разрешение, во-вторых, работают хорошо только на расстояниях от 50 см до 4 метров, а в-третьих начинают дико лажать на улице потому что ИК-излучение солнца забивает их собственное. Как светить фонариком в солнечный день.

С вычислением глубины по нескольким камерам дела обстоят лишь немногим лучше. Там выше разрешение, но посторонних шумов как на сельской дискотеке.

Можно пойти дальше в альтернативные методы. Тот же Face ID использовал связку Dot Projector с обычной ИК-камерой чтобы по сути делать то же самое. Там была важна и скорость, и точность, так что изобретение хитрого велосипеда было вполне оправдано.

Карты глубины всё равно часто нужны нам как база для более сложных методов. Так что без них никуда и прогресс камер идёт сейчас в них.

Мы уже использовали 3D карты окружения чтобы предсказывать по ним освещение рельного мира. Настало время поговорить о них поподробнее.

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

Хорошая новость: нам не надо делать её на каждый кадр. Здесь можно сэкономить. Достаточно пару раз в секунду выгружать ключевые кадры из SLAM'а в отдельный поток обработки, где вычислять по ним 3D-карту мира, никому не мешая.

Исторически для реконструкции окружения использовали те самые карты глубины, которые мы получили на прошлом шаге. Здесь нам не так важно их разрешение, но нужно иметь кадры с нескольких точек зрения.

Чем больше — тем лучше.

Положение камеры в каждом кадре мы уже знаем благодаря SLAM'у, а глубину кадого пикселя можем просто взять с Depth Map'ов. Значит, в теории, у нас есть все нужные данные по трём измерениям чтобы построить 3D-карту мира.

На практике для этого используют смешной метод, который напоминает заворачивание подарков. Берём простой объект с кучей вершин, тот же лист 5000х5000 точек, и как бы «притягиваем» его вершины к тем местам, которые показаны на картах глубины.

Как в примере с кроликом на гифке выше, который скукоживается из куба.

«Постойте!» — скажут те три человека, которые дочитали до этой части поста, — «но ведь если нам всё равно нужно делать перед этим SLAM, чтобы определить с какой точки была снята карта глубины, почему бы просто не взять такой алгоритм, который сразу выдаёт dense-карту мира и по ней же локализуется? Даже камера глубины тогда не нужна!»

Я вижу силу в словах ваших, поцаны (или как там говорил Заратустра).

State-of-the-Art сегодня такой: заставляем SLAM отдавать нам как можно больше точек, покрываем их треугольниками и сглаживаем полученную модель всякими фильтрами. Готова 3D-модель!

Сам же SLAM может использовать эти дополнительные точки для трекинга, так что здесь и до Direct SLAM недалеко (нужно теперь лишь выкинуть нахер дескрипторы и готово). Такой подход позволяет убить сразу двух зайцев, потому у него появилась куча фанатов.

💎 DTAM: Dense Tracking and Mapping in Real-Time (2011)

Совокупность же всех этих методов называется фотограмметрия

И это не какое-то там модное слово из фильмов про будущее, это банальное скучное настоящее. С её помощью уже лет десять как клепают 3D-модельки для игр. Моделлеры отрисовывают только самое важное — персонажей, технику, животных, а всякие бананы и мусор на улицах просто сразу сканируют в 3D вместе с текстурами (либо покупают на стоках).

В Google Maps с её помощью делают 3D-карты городов, а дроноводы летают вокруг всяких соборов, снимая их виртуальные бекапы. Теоретически мы можем вообще любое видео со статическими объектами превратить в 3D-сцену.

Наконец-то сбылась мечта всех школьников — смоделировать свой район и погонять по нему в GTA.

Только теперь им насрать, им всем по сорок лет.

Возвращаясь к проблеме оклюжена, с точной картой местности её решение становится чисто геометрическим. Когда рендер видит, что какая-то часть объекта оказалась закрыта куском карты — он объявляет красный код и начинает вычислять где её резать.

Конечно, придётся всю дорогу бороться с шумами и погрешностями, но мы, Настоящие Мужчины (и Мужчинэссы), и не с таким справлялись.

Главная же проблема у всей этой радости: на выходе реконструкции получается очень шумная модель, плюс всё это смешно ломается на динамических объектах. Пробежавший мимо кот смешно врастает в ламинат и превращается в предмет интерьера.

Приходится всё сильно шлифовать, сглаживать и опять городить исключения.

Со сложными движущимися объектами у нас начинается настоящий праздник. Особенно с людьми, которых развелось слишком много и они постоянно лезут в кадр.

Даже ваша собственная рука — источник проблем. Вот вы захотели помахать перед камерой или взять какой-то 3D-объект. Ваши пальцы должны как бы лечь сверху, но остальная кисть должна остаться позади. Ужасающе.

Здесь одними картами глубины уже не обойтись, а 3D-реконструкция просто сойдёт с ума.

Приходится делать честное распознавание объектов. Для людей есть PoseNet, для объектов ShapeNet или Detectron, но просто взять и использовать их не получится — они не потянут 30 fps.

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

Большие ребята собирают свои пайплайны из всего вышеперечисленного. Сначала рассчитывают 3D-карту, потом наблюдают за движущимися объектами через камеру глубины, потом распознают людей и их конечности всякими ML-распознавалками.

Фигуры людей потом дополнительно уточняют через карту глубины, но уже более целенаправленно.

Когда даже этих методов недостаточно (почти всегда), начинаются хаки в виде детекторов границ или Guided Filter из OpenCV. Они вычисляют очертания объектов по картинке как «волшебная палочка» в фотошопе, а мы потом можем их как-то усреднить с данными с камер и сделать края отреза менее рваными.

Главная проблема таких хаков в том, что они зачастую работают прям неприлично медленно. Бывает по 3-4 fps. Какой-то вялый у вас пайплайн, мужчина.

Ждём когда у всех появятся камеры глубины высокого разрешения. Они прекратят все эти страдания (и принесут новые).

💎 Fast Depth Densification for Occlusion-aware Augmented Reality (2019)
🎥 Видео-тизер к статье выше

На данном этапе мы знаем как трекать положение, собрали самый реалистичный рендер и идеально перекрываем объекты. Всё прекрасно, но мы всё ещё одиноки. Как в жизни.

Реальная польза дополненной реальности приходит от взаимодействия с другими людьми. Нам нужен мультиплеер.

Технически, главная задача мультиплеера в AR — это создать единую карту мира и понять где на ней находятся каждый из игроков. Дальше их собственные SLAM'ы уже справятся с отслеживанием изменений. Онлайн-игры уже так делали, знаем.

Проблема в одном — как всех собрать вместе в самом начале.

Начнём по порядку.

💎 Multiplayer AR — why it’s quite hard

В самом начале каждый игрок знает только свою карту мира. Это точки, которые увидел и распознал его SLAM. Он мог делать это как угодно — расстояние измерять в локтях, а углы в округлостях Ким Кардашьян, лишь бы он сам потом в них разобрался.

Когда игроков несколько, тут уже придётся калиброваться и договариваться. Нужно собрать все контрольные точки их sparse-карт в едином одном формате и передать на другое устройство или в облако.

Технически звучит не очень сложно — просто запакуй и отдай файлик, но боль начинается в мелочах. Для начала хорошо бы вообще убедиться, что игроки физически находятся рядом. Либо, если это сохранённая сессия, надо заново привязать её к координатам мира, а GPS на разных устройствах может запросто врать метров на двести.

Дополнительно дело осложняется тем, что у нас нет отработанных или стандартных способов сериализации и отправки таких карт. Каждый фреймворк изобретает свой велосипед, типа ARWorldMap в ARKit, и дружить их между платформами сейчас не умеет никто.

Даже если нам удастся привести все форматы и системы координат к общему знаменателю, 3D-карта, созданная на одном устройстве, на другом может просто физически быть больше или меньше другого, в зависимости от калибровки датчиков, угла камеры и производителя его акселерометра.

Одно и то же пройденое расстояние на одном телефоне может быть оценено в 50 сантиметров, а на другом в 52, причём эта ошибка плавающая в зависимости от кривизны объектива. Каждому из девайсов по отдельности насрать на такую погрешность, ведь она постоянна, но когда они оба оказываются в одной системе координат, ух, Press F to Pay Respects.

Но это еще цветочки.

🎥 WWDC19: Introducing ARKit 3 ← там хорошо показано как работает мультиплеер и распознавание людей

Когда игроки обменялись картами, начинается лотерея: сможет ли присоединившийся игрок найти себя на общей карте. Для этого ему надо сначала вычислить свою карту, найти на ней контрольные точки, рассчитать своё местоположение, а потом попытаться совместить всё это дело с контрольными точками на общей карте, тем самым «наложив» миры друг на друга.

По сути тем же самым занимается и один игрок, если вдруг его устройство потеряло своё точное местоположение, а объекты уже расставлены по сцене и терять их нельзя. Называется это релокализация.

Представьте, что вас с соседом заперли в тёмной комнате, каждому дали по пачке фотографий улиц вокруг и по ним сказали рассчитать где вы находитесь с точностью до сантиметра.

Причём желательно сделать это секунд за пять, иначе пользователь плюнет и оставит вам плохой отзыв в аппсторе.

Самая «любимая» разработчиками ситуация начинается когда игроки стоят ровно друг напротив друга. То есть они по сути не видят ничего из того, что видит камера оппонента. Ни одной контрольной точки.

Теперь вы понимаете зачем некоторые AR-игры заставляют вас встать рядом друг с другом чтобы начать.

Копирование SLAM-карты с последующей релокализацией — лишь один из методов, причём не самый популярный. Чаще всего дорогой и долгой релокализации вообще пытаются избегать, потому еще популярны варианты:

• Тупо забить. Локализоваться заново или разместить объекты в случайном порядке. Спроектировать приложение так, что потеря мира и создание его с нуля не будет никому заметна. Потерявшийся робот, например, может не пытаться истерично искать знакомые ему углы, а просто заново просканировать всё вокруг.

• Использовать-таки маркеры. Да, олдскул, но если вы делаете, например, AR-настолку, ваши игроки всё равно смотрят на поле, так что оно и может служить удобной системой координат для всех. Даже не надо ничего передавать и синхронизировать.

• GPS или компас. Вспомните Pokemon Go. Там один и тот же покемон для разных игроков появлялся с погрешностью метров в триста. Разработчики просто забили на любые попытки синхронизации и решили, что такого UX будет достаточно. Тоже вариант.

Тридцать раз в секунду каждое устройство вычисляет своё новое местоположение и должно как-то рассказать об этом другим. Кроме того, если игроки могут стрелять в друг друга или ещё как-то взаимодействовать — это всё надо как-то синхронизировать.

Есть два варианта: гонять всё через интернет как в MMORPG, либо слать напрямую между девайсами как музыку по блютусу. В реальности делают и так, и так. Google для ARCore предпочитает свои облака, а Apple с ARKit использует старый добрый Multipeer Connectivity как в AirDrop.

Оба варианта, как обычно, имеют свои недостатки.

✅ Больше скорость
✅ Можно хранить огромные карты мира
✅ Можно вычислять сложные штуки в облаке
✅ В теории бесконечное число игроков

⛔️ Всегда нужен интернет
⛔️ Проблема с прайваси

✅ Работают без интернета
✅ Меньше лаг
✅ Дешевле

⛔️ Нестабильны когда игроки отходят друг от друга
⛔️ Сложнее решать конфликты типа кто кого первый убил (обычно первого игрока просто делают хостом)
⛔️ Карты приходится делать маленькими чтобы удобнее хранить и передавать
⛔️ Не более 6 девайсов

Дальше всё стандартно для любой онлайн игры: открываем сокет и фигачим туда байты, сообщая о любых изменениях.

💎 ShareAR: Communication-Efficient Multi-User Mobile Augmented Reality (2019)

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

Честно говоря, в этом мире пока что творится дикий запад. Опенсорса нет, повсюду вендорлок, мета-фреймворки только появляются, и даже платные движки от частных компаний решают лишь базовые потребности.

Но это всё фигня, потому что скорее всего вы будете полностью завязаны под конкретную платформу, а там всегда свой язык и фреймворк. Рынок устроен так, что каждый девайс подходит под сильно ограниченный круг задач, поэтому сначала ищут железку, а уже потом под неё пишут на чём придётся.

Но у VR же получилось пробиться в кроссплатформу, так что и AR подтянется.

Сравним базовую расстановку сил на 2020 год. Всё очень быстро меняется, так что можете писать в комментариях когда выходят обновления.

Apple умеет красиво завернуть и подать, поэтому что они сначала прикупили пару десятков AR-компаний, а потом начали с самых видимых и полезных для пользователя вещей — стабильного трекинга, красивеньких отражений и мультиплеера.

Их попросту легче всего продавать, пока разработчики допилят всё остальное.

За три года жизни у ARKit вышло аж три версии:

1.0. Базовая функциональность типа трекинга, базовый Light Estimation и плагины для Unity.

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

3.0. Нормальный мультиплеер, People Occlusion, RealityKit. Под шумок выкинули из поддержки старые айфоны потому что менеджер сказал увеличить продажи.

Главная фишка, за которую хвалят ARKit — самый стабильный на рынке трекинг. Прыгающие объекты встречаются в ARKit на порядки реже, чем у остальных. Даже одноцветные плоскости типа столов или стен распознаются нормально, что раньше считалось сложнейшей задачей.

ARKit использует упрощённый SLAM, названный Visual-Intertial Odometry, где от аббревиатуры SLAM почти не осталось M (маппинга), зато очень круто сделана L (локализация). Что у многих вызывает дикие срачи из-за определений, но я не буду их щас разводить.

От «настоящего» плотного маппинга в Apple отказались потому что хотят по-максимуму делать всё на устройстве, а память как бы не резиновая. Потому с освещением и оклюженом, как вы теперь понимаете, всё не очень. Будут решать костылями.

Зато трекинг получился на славу. Всё дело в тонкой калибровке датчиков и камер, который может себе позволить только Apple.

Для стабильного AR очень важна аппаратная калибровка сенсоров, вплоть до того, что инженеры-схемотехники замыкают перемычкой часы в разных сенсорах чтобы данные с них приходили синхронно по времени. Так заморачиваться можно только когда ты сам делаешь железо.

В остальном всё обычно. Коротко, ARKit:

✅ Очень стабильный трекинг. Спасибо калибровке.

✅ Распознавание объектов и People Occlusion.

✅ Peer-to-peer мультиплеер. Работает без интернета.

💩 Даже не старается в освещение. Предсказывает лишь тени и яркость, да и то фигово.

💩 Не умеет в перекрытие объектов. Только людей.

💩 Только одна платформа.

Кодовая база осталась еще со времён Project Tango, который в недрах Google разрабатывали до 2014 года и пытались продавать через планшеты Lenovo.

В 2017-м появляется ARKit, после чего код Tango быстро форкают, выкидывают половину «ненужных» фич типа сенсоров глубины и называют это ARCore, который релизят в марте 2018.

Сейчас там, конечно, ушли гораздо дальше, натырив много кусков из гугловского же Daydream VR. Так что партия смело заявляет, что все совпадения случайны. Но мы-то знаем.

В отличии от ARKit, который пытается делать всё на девайсе, Google не парится и фигачит через свои облака. Потому ARCore лучшее умеет в «настоящий» плотный маппинг, распознавание объектов, релокализацию и даже мультиплеер, ведь делает это на серверах с жирными жифорсами.

Google даже научились маппить и сохранять огромные сцены на серверах целиком. Всю вашу комнату, торговый центр или даже целый аэропорт, делая потом по ним SLAM-навигацию вместо прыгающего неточного GPS. Топ тема.

Кроме этого, плюсом ARCore принято считать более крутой рендер с Lighting API, который умеет вообще во все state-of-art алгоритмы, описанные в этой статье. Теоретически, благодаря ему, объекты ARCore должны вписываться в реальность намного лучше, чем у остальных.

Проблема, как всегда на андроидах — сегментация. Когда у тебя зоопарк кшьяоми-самсунгов, мало кого волнует насколько у тебя крутые алгоритмы.

Итого по ARCore:

✅ Имеет всё, что есть в ARKit

✅ Намного лучше работает с освещением объектов

✅ Быстрее релокализуется когда потерялся. Потому что хранит полные карты в облаке, а не экономит память как ARKit.

✅ Старается в честный оклюжен объектов

💩 Дикая сегментация. Надо иметь «правильный» смартфон, чтобы ARCore работал действительно хорошо.

В Microsoft опять происходит что-то странное. Их MRTK на голову обгоняет всех по фичам, плюс интегрируется со всеми (ARKit + ARCore + Unity), плюс его код полностью открыт.

При этом о нём никто не говорит, рекламы не снимает, ну и хипстеры-аналитики с The Verge в каждой статье о «будущем» его не упоминают. Не модно.

Mixed Reality ToolKit умеет всё, что умеют ARKit и ARCore, плюс:

✅ Работает на куче платформ.

✅ Умеет трекать руки и зрачки глаз.

✅ Даёт UI-библиотеку для создания виртуальных формочек и ползунков, которые можно двигать голыми руками.

✅ 3D-маппинг окружения и оклюжен из коробки.

✅ Интегрируется со всеми популярными движками от Unity до Unreal Engine.

✅ Можно писать обычные 2D-приложения на стандартных виндовых фреймворках.

Но это майки, а мы-то помним, что они обладают уникальным свойством просирать все полимеры даже находясь на самых выигрышных позициях.

Всё это умеет работать в том числе на HoloLens, которые по всем сравнениям уделывают по трекингу остальные ваши аркиты-аркоры благодаря своему железу. Microsoft напихала в HoloLens ASIC'ов — специальных чипов, которые реализуют описанные в статье алгоритмы аппаратно (!), что и даёт такой заметный прирост.

И вот всё это технологическое буйство пилится исключительно под бизнес-клиентов и прочие интерпрайзы, а мы с вами кушаем что отдали в опенсорс. Даже рекламировать это лень. Один контракт с Боингом приносит больше, чем гикам игрушки продавать. Приоритеты.

Хотя вы тоже можете прикупить Developer Kit за три тысячи баксов, но зачем. Лучше посмотрите демо-видосик ниже.

💎 Localization Limitations of ARCore, ARKit, and Hololens in Dynamic Large-Scale Industry Environments

Кроссплатформенных фреймворков под коммерческой лицензией на рынке есть десятки, я здесь устану перечислять их все. Вот три самых популярных в порядке убывания приложений на них в App Store и Google Play.

Vuforia пока всех делает как стоячих. Даже ARKit и ARCore в их собственных сторах на втором месте. Однако, сейчас её разрабы понимают, что нативные решения откусят от них жирный кусок, потому в новые версии активно впиливают поддержку разных платформ и пытаются стать мета-фреймворком.

Посмотрим. По идее путь правильный.

По набору фич они, можно сказать, не уступают ребятам выше. У каждого есть свой SLAM, какой-никакой Light Estimation, рендеры на OpenGL и плагины для Unity.

Но тут всегда нужно быть осторожным. У скейтборда тоже четыре колеса, но едет он всё-таки похуже автомобиля. Лучше сначала проехаться чтоб понять.

Так что пока это путь храбрых. Или экономных.

Долой злые корпорации, мы и сами всё сможем!!!11

Иии... нет, не смогли. Даже самые популярные решения дают максимум распознавание маркеров да, прости господи, баркодов. SLAM и рендеринг приносите с собой.

Для научных статей частенько берут ARToolKit, потому его упоминания на каждом углу.

Кровь, кишки и опенсорс.

P.S.: Плазма не падает