Открыть список
Как стать автором
Обновить

Комментарии 34

Эти анимации стали главной причиной, почему статью писалась так долго.

Эта статья стала главной причиной, почему я поздно лёг спать)
Планировал потратить ещё минут 10 на чтение комментариев, но их. по странной причине, мало.
Жду продолжения.
Рад что заинтересовал! Пока не уверен насчёт продолжения, хотя есть идеи. Если не секрет, какой у вас часовой пояс?)
Спасибо что так ненавязчиво указали на опечатку, исправил :)
UTC+10:00
Только сейчас заметил опечатку)

Очень круто! Как-то сам занимался построением меша по данным с камеры глубины. И делал это абсолютно простым и "лобовым" методом.


Облако точек с камеры глубины — это то, что в библиотеке Point Cloud Library называют Organized Point Cloud.


Т.е. фактически двухмерный массив, где каждый элемент — точка, при этом соседние элементы массива представляют (чаще всего) соседние точки в сцене, следовательно, как Вы и сказали, достаточно триангулировать на плоскости.


Для этого достаточно просто соединить соседние элементы массивов, образовав квадратные полигоны. На границе объектов (если выкинуть разрывы) остаются треугольные полигоны нескольких видов.


Невнятная картинка из презентации с внутривузовской конференции


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


Реализация этого алгоритма на Processing. Жуткий говнокод, неправильным образом решающий ненужную задачу. Просто линейный проход по всему облаку. Сложность — O(N), где N — количество точек.


Пример меша

Сканировалась именно ступня, объект маленький, разрешение мало, поэтому жутко ступенчатый.



После сглаживания (точнее, сглаживание z-координат точек применялось до триангуляции)


Интересно, кстати неплохой результат после сглаживания. В самой первой версии у меня был алгоритм вроде такого, но т. Делоне работает получше, по нескольким причинам. Organised Point Cloud от structured light сенсоров не обязательно ложится на регулярную сетку, в статье даже есть пример датасета с Tango где это видно. Т.е. если кадр «сжать» до разрешения проектора, то некоторые точки потеряются, а в некоторых местах будут дырки. Так вот настоящий алгоритм триангуляции оптимальным образом заделывает эти дырки, что позволяет накладывать текстуру без разрывов. Плюс непрофессиональные сенсоры плохо работают например на волосах или блестящих поверхностях, тут тоже помогает возможность «заделывать» большие дырки. Но если depth-камера хорошая, то ваш подход оптимальнее, т.к. такой алгоритм в разы быстрее :)
Если гнаться за скоростью, тут можно много чего придумать, например совсем необязательно «честную» триангуляцию Делоне строить. У меня вроде не было такой цели, и так работает 300FPS почти.
какая depth камера хорошая?
intelsence шумит дико, и избавление от шума сильно понижает fps.
Из «дешёвых» самая лучшая — Occipital Structure Sensor, хотя конечно все они шумят. Знаю по опыту работы с 3D сканированием (itSeez3D.com). Но есть ещё дорогие профессиональные сканеры, например Artec за 13000 евро и более.
А какие ещё удалось попробовать?
Из недорогих почти все — Kinect, Tango, RealSense, Structure Sensor. И ещё несколько про которые я не могу говорить из-за NDA :)
Интересует решение какой-то конкретной задачи?
Нет, тоже хочу взять поиграться.
А можно краткое резюме относительно испробованных камер?
1) Occipital Structure Sensor — самый точный, высокий FPS, меньше всего проблем с солнечным светом, блестящими поверхностями. Главная проблема — vendor lock, работает только с техникой Apple насколько мне известно. Но если вас это не смущает, то отличный выбор. Приложение-сканер над которым я работал лучше всего сканирует именно с этим сенсором.
2) Intel RealSense — высокий FPS, относительно удобно с ним работать как в Windows так и в Linux. Сенсор маленький, так что можно делать всяких роботов. Плохо работает на волосах, темных поверхностях и не такой точный в среднем как Strucure. RGB камера низкого разрешения.
3) Google Tango. Планшет, который был у меня снимает только 5FPS, но точность в принципе неплохая, примерно как RealSense наверное. Из плюсов — куча встроенного в SDK софта для одометрии, сканирования и т.п. Хороший встроенный трекинг (отслеживание положения девайса в пространстве). Нет синхронизации между depth и RGB. Последние девайсы с Tango я не тестил.
4) Kinect это уже старый девайс, про него наверное и так всё известно, в интернете куча инфы. Я довольно мало с ним работал.

Использовали Asus XTion, Kinect — примерно одно и то же, довольно шумит. Возможно Time of flight камеры покажут лучшие варианты. Китайцы предлагают чисто модули камер, дев-борды и прочее, но не озвучивают цены.

Кстати, а вы каким оборудованием сканировали? Вижу, ASUS'ом :)
Я правильно понимаю, что на каждый кадр запускается повторная триангуляция 'с нуля' но ведь соседние кадры не сильно отличаются (особенно на высоких fps), значит можно в качестве стартовой триангуляции использовать предыдущую, сопоставив точки из разных кадров, по минимальному расстоянию.
Да, тут можно много чего придумать :) Это был хобби-проект, и разработка таких игрушек определяется fun factor. Для меня он немного ослабел после всего кода, что уже написан, но может ещё захочется вернуться к этому позже) А так — contributions are welcome!
Вообще здесь есть простор для полёта фантазии. Например в статье есть ссылки на академические работы — вот там они конкретно заморочились: https://www.youtube.com/watch?v=SH3MKjwgI80. Нужно много времени чтобы догнать такие результаты)
И хотя статья выглядит интересно, но заголовок меня разочаровал несмотря на спойлер.
Я думал, что будет хотя бы про интересную проекцию 4д-объектов на экран, например. А не очередной глупый маркетологичный прием с расчетом на слабую аудиторию.
Вы вот про это? https://www.youtube.com/watch?v=5xN4DxdiFrs
Извините, сильную аудиторию мне не потянуть, приходится пока рассчитывать на слабую)
Ну что-то вроде такого — проекция 4-х измерений на 2д-экран. Возможно как вторая часть — даже игра какая-то, где в 4 измерениях перемещаться можно.
Я говорил про совсем слабую аудиторию, которая не понимает что значит буква d в термине «4d».
Очень круто.
А, при соответствующих ресурсах, вполне возможно и коммерческое применение.
Или как раньше шутили — «порноиндустрия застыла в ожидании». :)
Несколько компаний работают над коммерческими реализациями, например есть вот такие ребята: https://8i.com/
Про конкретные примеры из порно-индустрии мне неизвестно, но я уверен, что-нибудь скоро появится. Сейчас уже есть adult контент для VR, а тут ещё более «immersive experience». Можно рассматривать сцену с любого интересного тебе угла. Сам себе режиссёр :D
Мне непонятно. И те примеры, что у вас в статье. И по ссылке — вообще не используется свет. Если уж строите меш — почему бы не кинуть хороший свет да с тенью на ваши текстуры — получится вообще сладкий результат.
На самом деле обычно используют unlit рендеринг, потому что меш шумноват, с освещением это ещё больше заметно. Но если сгладить вершинки и нормали немного, то можно и подсветить.
Ещё одна проблема (как и с любым другим 3D сканированием) — сложно отфильтровать оригинальное освещение в сцене. Т.е. у вас объекты как-то освещены когда вы их снимаете, а потом ещё добавляется свет при рендеринге, и часто это выглядит неестественно. Решается очень хорошим равномерным светом при съемке, но этого сложно добиться без специальной студии.
И всё таки я не вижу здесь четвёртого измерения, проекция четырёхмерного куба например выглядит как-то так:
image
Про это есть спойлер в статье. Формально измерения четыре (три + время). Нигде не уточняется что 4 пространственных измерения. Моя шутка про 4D не удалась короче)
Нет, я не про это, а про это Второе легко описывается математически и я даже как-то делал на C# проекцию на двумерное пространство проекции на трёхмерное пространство четырёхмерного куба

Слово "видео" уже подразумевает наличие времени, поэтому в число измерений оно не включается даже маркетологами...

Come on. Такой контент называют 4D уже много лет, не я это придумал. Вот, люди даже компанию так назвали: https://www.4dviews.com/
Я думаю все поняли друг друга) Предлагаю закрыть эту тему.
Все из нас видели диаграммы Вороного.

Ну конечно же! Вот только одну диаграмму Вороного закрыл — и тут же следующая в новой статье. Уже не знаю, куда от них бежать.
Триангуляция — это круто и интересно, но лично мне ещё интереснее вот что: как сделаны анимации работы алгоритма? :)
Если прям конкретно, то вот по этой ссылке можно найти функцию plotTriangulation, которая делает обход графа и «рисует» текущую триангуляцию в 2D матрицу с помощью OpenCV. Затем я сохранял тысячи этих матриц как картинки в папку и запускал на них ffmpeg с нужными параметрами. Если интересно, могу рассказать подробнее :)

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

Создаем квады или треугольники на основании матрицы глубины
— вот т. Делоне для этого и используется. В статье есть пример карты глубины c сенсора (GIF-ка в красно-синих цветах). По ней видно, что матрица разреженная, информация распределена неравномерно. Это ещё тепличный пример, часто можно встретить также большие прогалы в данных, и хороший алгоритм триангуляции как раз «заделывает» их неким оптимальным образом. Я так понял вы предлагаете создавать треугольники и квады примерно как Alex_ME в комментариях выше. Действительно, это будет работать во многих случаях, и я даже пробовал так делать. Но результаты с триангуляцией выглядят получше, а задачи сделать код ещё быстрее у меня не стояло (и так 200-300FPS).
Текстуру я накладываю точно так, как вы описали. Берётся точка в 3D, домножается на известную матрицу RT (сдвиг между позициями камер), проецируется на фокальную плоскость RGB камеры. Так получаем UV-координаты для этой вершины.
А вообще, есть много способов улучшить этот пайплайн, если оптимизировать по скорости, то действительно нужно думать в направлении более простых алгоритмов и использовать «похожесть» соседних кадров, как предложил rPman.

Спасибо, теперь стало понятней.

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