3d-графика

Математика верстальщику не нужна 2 Матрицы, базовые трансформации, построение 3D и фильтры для картинок

22.09.2020 12:22:19 |

Автор: admin

В прошлый раз мы говорили о графиках и траекториях для покадровых анимаций, а сегодня речь пойдет про матрицы. Мы разберемся с тем, как строятся базовые трансформации в CSS, SVG и WebGL, построим отображение 3D-мира на экране своими руками, попутно проводя параллель с таким инструментом, как Three.js, а также поэкспериментируем с фильтрами для фотографий и разберемся, что же за магия такая лежит в их основе.

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

Скрипты для генерирования картинок в стиле этого цикла статей находятся на GitHub, так что если если вы хотите себе сообразить такие же вы знаете что делать.

Немного определений

Матрица в математике это такая абстракция, можно сказать, что это тип данных в каком-то смысле, и записываетя она в виде прямоугольной таблицы. Количество столбцов и строк может быть любым, но в вебе мы почти всегда имеем дело с квадратными матрицами 2x2, 3x3, 4x4, и 5x5.

Также нам понадобится такое определение, как вектор. Думаю из школьной геометрии вы можете вспомнить определение, связанное со словами длина и направление, но вообще в математике вектором может называться очень много чего. В частности мы будем говорить о векторе, как об упорядоченном наборе значений. Например координаты вида (x, y) или (x, y, z), или цвет в формате (r, g, b) или (h, s, l, a) и.т.д. В зависимости от того, сколько элементов вошло в такой набор мы будем говорить о векторе той или иной размерности: если два элемента двумерный, три трехмерный и.т.д. Также, в рамках рассматриваемых тем, может быть удобно иногда думать о векторе, как о матрице размера 1x2, 1x3, 1x4 и.т.д. Технически можно было бы ограничиться только термином матрица, но мы все же будем использовать слово вектор, чтобы отделить эти два понятия друг от друга, хотя бы в логическом смысле.

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

function multiplyMatrices(a, b) {    const m = new Array(a.length);    for (let row = 0; row < a.length; row++) {        m[row] = new Array(b[0].length);        for (let column = 0; column < b[0].length; column++) {            m[row][column] = 0;            for (let i = 0; i < a[0].length; i++) {                m[row][column] += a[row][i] * b[i][column];            }        }    }    return m;}

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

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

Мы будем использовать только квадратные матрицы в очень частном наборе задач, так что будет достаточно набора простых правил:

Умножать можно только матрицы одной размерности.
Умножаем матрицу на матрицу получаем матрицу.
Можно умножить матрицу на вектор получим вектор.
Порядок умножения важен.

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

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

И последнее, что нам понадобится, это пример, показанный на картинке выше. Это как бы частный случай умножения матрицы на вектор, когда у матрицы последняя строка представляет собой кусочек единичной матрицы, а у вектора последний элемент тоже равен 1.

В этом примере мы используем буквы (x, y), и как вы уже можете догадаться, дальше речь пойдет о координатах в 2D. Но зачем добавлять третью координату и оставлять ее единицей? спросите вы. Все дело в удобстве, или даже лучше сказать, что в универсальности. Мы очень часто добавляем +1 координату для упрощения расчетов, и работа с 2D идет с матрицами 3x3, работа с 3D с матрицами 4x4, а работа с 4D, например с цветами в формате (r, g, b, a) идет с матрицами 5x5. На первый взгляд это кажется безумной идеей, но дальше мы увидим, насколько это унифицирует все операции. Если вы захотите более подробно разобраться в этой теме, то можете загуглить выражение однородные координаты.

Но довольно теории, перейдем к практике.

I. Базовые трансформации в компьютерной графике

Давайте возьмем выражения из упомянутого примера и посмотрим на них как есть, вне контекста матриц:

newX = a*x + b*y + cnewY = d*x + e*y + f

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

newX = 1*x + 0*y + 0 = xnewY = 0*x + 1*y + 0 = y

Здесь ничего не меняется новые координаты (x, y) идентичны старым. Если подставить эти коэффициенты в матрицу и внимательно присмотреться, то увидим, что получится единичная матрица.

А что получится, если взять другие коэффициенты? Например вот такие:

newX = 1*x + 0*y + A = x + AnewY = 0*x + 1*y + 0 = y

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

Меняя эти 6 коэффициентов a, b, c, d, e, f и наблюдая за изменениями x и y, рано или поздно мы придем к четырем их комбинациям, которые кажутся полезными и удобными для практического применения. Запишем их сразу в форме матриц, возвращаясь к изначальному примеру:

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

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

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

Базовые трансформации в CSS

Но это все слова. Давайте посмотрим, как это выглядит в реальном фронтенде. В CSS у нас (внезапно) есть функция matrix. Выглядит она в контексте кода как-то так:

.example {    transform: matrix(1, 0, 0, 1, 0, 0);}

Многих новичков, которые впервые видят ее, накрывает вопрос почему здесь шесть параметров? Это странно. Было бы 4 или 16 еще куда не шло, но 6? Что они делают?

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

Также в CSS есть функция matrix3d для того, чтобы задавать с помощью матрицы трансформацию в 3D. Там уже есть 16 параметров, ровно чтобы сделать матрицу 4x4 (не забываем, что мы добавляем +1 размерность).

Матрицы для базовых 3D трансформаций строятся так же, как и для 2D, только нужно больше коэффициентов, чтобы расставлять их не по двум координатам, а по трем. Но принципы те же.

Естественно, каждый раз городить матрицу и следить за корректной расстановкой коэффициентов при работе с простыми трансформациями в CSS было бы странно. Мы, программисты, обычно все же стараемся упростить себе жизнь. Так что у нас в CSS появились краткие функции для создания отдельных трансформаций translateX, translateY, scaleX и.т.д. Обычно мы используем именно их, но важно понимать, что внутри они создают эти же самые матрицы, о которых мы говорили, просто скрывая от нас этот процесс за еще одним слоем абстракции.

Эти же самые трансформации translate, rotate, scale и skew, а также универсальная функция matrix для задания трансформаций, присутствуют и в SVG. Синтаксис немного другой, но суть такая же. При работе с трехмерной графикой, например с WebGL, мы тоже будем прибегать к этим же трансформациям. Но об этом чуть позже, сейчас важно понять, что они есть везде, и работают везде по одному и тому же принципу.

Промежуточные итоги

Обобщим вышесказанное:

Матрицы могут быть использованы в качестве трансформаций для векторов, в частности для координат каких-то объектов на странице.
Почти всегда мы оперируем квадратными матрицами и добавляем +1 размерность для упрощения и унификации вычислений.
Есть 4 базовых трансформации translate, rotate, scale и skew. Они используются везде от CSS до WebGL и везде работают схожим образом.

II. Построение 3D сцены своими руками

Логичным развитием темы про трансформации координат будет построение 3D сцены и отображение ее на экране. В той или иной форме эта задача обычно есть во всех курсах по компьютерной графике, но вот в курсах по фронтенду ее обычно нет. Мы посмотрим может быть немного упрощенный, но тем не менее полноценный вариант того, как можно сделать камеру с разными углами обзора, какие операции нужны, чтобы посчитать координаты всех объектов на экране и построить картинку, а также проведем параллели с Three.js самым популярным инструментом для работы с WebGL.

Здесь должен возникнуть резонный вопрос зачееем? Зачем учиться делать все руками, если есть готовый инструмент? Ответ кроется в вопросах производительности. Вероятно вы бывали на сайтах с конкурсами вроде Awwwards, CSS Design Awards, FWA и им подобных. Вспомните, насколько производительные сайты принимают участие в этих конкурсах? Да там почти все тормозят, лагают при загрузке и заставляют ноутбук гудеть как самолет! Да, конечно, основная причина обычно это сложные шейдеры или слишком большое количество манипуляций с DOM, но вторая невероятное количество скриптов. Это катастрофическим образом влияет на загрузку подобных сайтов. Обычно все происходит так: нужно сделать что-то на WebGL берут какой-нибудь 3D движок (+500КБ) и немного плагинов для него (+500КБ); нужно сделать падение объекта или разлетание чего-то берут физический движок (+1МБ, а то и больше); нужно обновить какие-то данные на странице ну так добавляют какой-нибудь SPA-фреймворк с десятком плагинов (+500КБ) и.т.д. И таким образом набирается несколько мегабайтов скриптов, которые мало того, что нужно загрузить клиенту (и это еще вдобавок к большим картинкам), так еще и браузер с ними что-то будет делать после загрузки они же не просто так к нему прилетают. Причем, в 99% случаев, пока скрипты не отработают, пользователь не увидит всей той красоты, которую ему бы нужно с самого начала показывать.

Народная примета гласит, что каждые 666КБ скриптов в продакшене увеличивают время загрузки страницы на время, достаточное, чтобы пользователь отправил разработчика сайта на следующий круг ада. Three.js в минимальной комплектации весит 628КБ...

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

Цепочка преобразований координат

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

Так вот. Допустим дизайнер нарисовал 3D-модель. Пусть это будет куб (в примерах будем использовать максимально простые построения, чтобы не усложнять иллюстрации на ровном месте):

Что эта модель из себя представляет? По сути это набор точек в какой-то системе координат и набор взаимосвязей между ними, чтобы можно было определить, между какими из точек должны находиться плоскости. Вопрос плоскостей в контексте WebGL будет лежать на плечах самого браузера, а для нас важны координаты. Нужно понять, как именно их преобразовать.

У модели, как мы и сказали, есть система координат. Но обычно мы хотим иметь много моделей, хотим сделать сцену с ними. Сцена, наш 3D-мир, будет иметь свою, глобальную систему координат. Если мы просто будем интерпретировать координаты модели как глобальные координаты то наша модель будет находиться как бы в центре мира. Иными словами, ничего не поменяется. Но мы хотим добавить много моделей в разные места нашего мира, примерно так:

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

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

// Центральный кубик в центре мира.// Единичная матрица ничего не меняет и координаты просто интерпретируются как глобальные.const modelMatrix1 = [    [1, 0, 0, 0],    [0, 1, 0, 0],    [0, 0, 1, 0],    [0, 0, 0, 1]];// Кубик, смещенный по глобальной оси X.const modelMatrix2 = [    [1, 0, 0, 1.5],    [0, 1, 0, 0  ],    [0, 0, 1, 0  ],    [0, 0, 0, 1  ]];// Кубик, смещенный по глобальной оси X в другую сторону.const modelMatrix3 = [    [1, 0, 0, -1.5],    [0, 1, 0, 0   ],    [0, 0, 1, 0   ],    [0, 0, 0, 1   ]];

Дальше мы будем действовать примерно следующим образом:

для каждой точки модели {    глобальные координаты точки = [ матрица этой модели ] * локальные кординаты}

Соответственно для каждой модели нужна своя матрица.

Аналогичным образом можно делать цепочку из каких-то объектов. Если птица должна махать крыльями, то будет уместно координаты точек крыла сначала перевести в координаты птицы, а потом уже в глобальные мировые координаты. Это будет куда проще угадывания траектории крыла сразу в глобальных координатах. Но это так, к слову.

Дальше нужно определиться с тем, с какой стороны мы будем смотреть на мир. Нужна камера.

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

для каждой точки в мире {    координаты точки для камеры = [ матрица камеры ] * глобальные кординаты}

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

Давайте посмотрим на сцену с того места, где стоит наша условная камера:

Сейчас, преобразовав все точки в систему координат камеры, мы можем просто выбросить ось Z, а оси X и Y интерпретировать как горизонтальную и вертикальную. Если нарисовать все точки моделей на экране, то получится картинка, как в примере никакой перспективы и сложно понять, какая часть сцены на самом деле попадает в кадр. Камера как бы бесконечного размера во все стороны. Мы можем как-то все подогнать, чтобы то, что нужно, влезло на экран, но было бы неплохо иметь универсальный способ определения того, какая часть сцены попадет в поле зрения камеры, а какая нет.

У физических камер мы можем говорить о такой штуке, как угол обзора. Почему бы и здесь его не добавить?

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

// Пусть угол обзора будет 90 градусовconst s = 1 / (Math.tan(90 * Math.PI / 360));const n = 0.001;const f = 10;const projectionMatrix  = [    [s, 0, 0,          0],    [0, s, 0,          0],    [0, 0, -(f)/(f-n), -f*n/(f-n)],    [0, 0, -1,         0]];

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

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

Теперь, произведя уже знакомые преобразования:

для каждой точки в системе координат камеры {    координаты точки = [ матрица проекции ] * координаты в камере}

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

Но на самом деле нет. Мы забыли про перспективу. Бесперспективная картинка нужна мало где, так что нужно ее как-то добавить. И здесь, внезапно, нам не нужны матрицы. Задача выглядит очень сложной, но решается банальным делением координат X и Y на W для каждой точки:

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

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

Теперь мы имеем полноценную картинку. Можно брать координаты X и Y для каждой точки и рисовать ее на экране любым удобным вам способом.

Вообще этого достаточно, чтобы построить сцену, но в реальных проектах вы также можете столкнуться с дополнительной трансформацией, связанной с масштабированием, в самом конце. Идея в том, что после проекции мы получаем координаты (x, y) в пределах 1, нормализованные координаты, а потом уже умножаем их на размер экрана или канваса, получая координаты для отображения на экране. Этот дополнительный шаг выносит размер канваса из всех вычислений, оставляя его только в самом конце. Иногда это удобно.

Здесь у вас, вероятно заболела голова от количества информации, так что притормозим и повторим еще раз все трансформации в одном месте:

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

Как это выглядит в Three.js?

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

void main() {    gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0);}

или в более полном варианте:

void main() {    gl_Position = projectionMatrix * viewMatrix * modelMatrix * vec4(position, 1.0);}

Ничего он вам не напоминает? Да, это именно этот паровозик. И под ничего не делает мы подразумеваем, что он как раз делает всю работу по пересчету координат, на основе заботливо переданных со стороны Three.js матриц. Но никто не мешает эти матрицы сделать своими руками, не так ли?

Типы камер в компьютерной графике и Three.js

Тема типов камер не касается непосредственно матриц, но все же уделим ей пару минут, раз уж все равно зашла речь про Three.js, а то порой у людей каша в голове по этому поводу.

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

В компьютерной графике мы имеем два вида камер это с перспективой и без перспективы. Это два принципиально разных типа камер в техническом плане, требующих разных действий для получения изображения. И все. Больше ничего нет. Все остальное это их комбинации, какие-то более сложные абстракции. Например в Three.js есть стерео-камера это не какой-то особый тип камеры в техническом плане, а просто абстракция две камеры, немного разнесенные в пространстве и расположенные под углом:

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

Что дальше?

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

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

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

Мы действительно можем строить полноценные 3D-сцены своими руками. Но все же здесь важно соблюдать баланс для простой генеративной графики или каких-то эффектов для картинок это будет хорошей идеей. Для сложных сцен может быть проще все же взять готовый инструмент, потому что свой по объему будет приближаться к тому же Three.js и мы ничего не выиграем при избавлении от него. А если вам нужно естественное освещение, мех, стекло, множественные отражения или еще что-то в этом духе, то из соображений производительности может иметь смысл отказаться от самой идеи рендерить что-то в реальном времени и заранее заготовить картинки с видами на сцену с разных сторон и уже их показывать пользователю. Мыслите шире, не зацикливайтесь на определенном подходе к решению задач.

Промежуточные итоги

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

Итак:

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

III. Фильтры для изображений

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

И применить это для картинки по очевидному принципу:

для каждого пикселя картинки {    новый цвет пикселя = [ фильтр ] * старый цвет пикселя}

Если в качестве матрицы будет выступать единичная матрица ничего не изменится, это мы уже знаем. А что будет, если применить фильтры, схожие с трансформациями translate и scale?

Оу. Получились фильтры яркости и контраста. Занятно.

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

А как сделать черно-белое изображение из цветного? Первое, что может прийти в голову это сложить значения каналов RGB, поделить на 3, и использовать полученное значение для всех трех каналов. В формате матрицы это будет выглядеть как-то так:

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

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

А если мы еще и домножим главную диагональ немного, то получится универсальный фильтр насыщенности:

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

Вообще играться с фильтрами можно долго, получая самые разные результаты:

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

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

Фильтры в CSS

В CSS у нас есть свойство filter. И там, в частности, есть вот такие варианты фильтров, связанных с цветами:

brightness (мы его сделали)
contrast (сделали)
invert (то же, что и контраст, только коэффициенты по главной диагонали с другим знаком)
saturate (сделали)
grayscale (как уже отметили, это частный случай saturate)
sepia (очень размытое понятие, разные варианты сепии получаются игрой с коэффициентами, где мы так или иначе уменьшаем присутствие синего цвета)

И эти фильтры принимают на вход коэфициенты, которые потом в том или ином виде подставляются в те матрицы, которые мы сделали ранее. Теперь мы знаем, как эта магия устроена изнутри. И теперь понятно, как эти фильтры комбинируются в недрах интерпретатора CSS, ведь здесь все строится по тому же принципу, что и с координатами: умножаем матрицы складываем эффекты. Правда пользовательской функции matrix в этом свойстве в CSS не предусмотрено. Но зато она есть в SVG!

Фильтры-матрицы в SVG

В рамках SVG у нас есть такая штука, как feColorMatrix, которая применяется при создании фильтров для изображений. И здесь у нас уже есть полная свобода можем сделать матрицу на свой вкус. Синтаксис там примерно такой:

<filter id=my-color-filter>    <feColorMatrix in=SourceGraphics        type=matrix,        matrix=1 0 0 0 0                0 1 0 0 0                0 0 1 0 0                0 0 0 1 0                0 0 0 0 1    /></filter>

А еще SVG фильтры можно применить к обычным DOM-элементам в рамках CSS, там для этого есть специальная функция url Но я вам этого не говорил!

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

А что еще бывает?

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

Kernel matrix

В частности во фронтенде мы встречаем такую штуку, как kernel matrix, и связанными с ней эффектами. Суть проста есть квадратная матрица, обычно 3x3 или 5x5, хотя может быть и больше, а в ней хранятся коэффициенты. В центре матрицы для текущего пикселя, вокруг центра для соседних пикселей. Если матрица 5x5 то появляется еще один слой вокруг центра для пикселей, находящихся через один от текущего. Если 7x7 то еще один слой и.т.д. Иными словами мы рассматриваем матрицу как такое двумерное поле, на котором можно расставить коэффициенты по своему усмотрению, уже без привязки к каким-то уравнениям. А трактоваться они будут следующим образом:

для каждого пикселя картинки {    новый цвет пикселя =        сумма цветов соседних пикселей, умноженных на их коэффициенты из матрицы}

Чистый канвас не очень подходит для таких задач, а вот шейдеры очень даже. Но нетрудно догадаться, что чем больше матрица, тем больше соседних пикселей мы будем использовать. Если матрица 3x3 мы будем складывать 9 цветов, если 5x5 25, если 7x7 49 и.т.д. Больше операций больше нагрузка на процессор или видеокарту. Это неизбежно повлияет на производительность страницы в целом.

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

В рамках SVG у нас есть специальный тег feConvolveMatrix, который сделан как раз для создания подобных эффектов:

<filter id=my-image-filter>    <feConvolveMatrix        kernelMatrix=0 0 0                      0 1 0                      0 0 0    /></filter>

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

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

Если мы начнем расставлять числа по слоям, от большего у меньшему, то получится blur:

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

Теперь, зная как работает blur, мы можем понять, почему активное его использование на странице в рамках CSS или SVG ведет к тормозам для каждого пикселя браузер проделывает кучу расчетов.

Если начать экспериментировать со сменой знаков у коэффициентов и расставлять их в разные паттерны, то получатся эффекты sharpen, edge detection и некоторые другие. Попробуйте поиграть с ними самостоятельно. Это может быть полезно.

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

Промежуточные итоги

Обобщим сказанное в этой части:

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

Заключение

Если немного абстрагироваться от запутанных алгоритмов, то матрицы станут вполне доступным инструментом для решения практических задач. С их помощью можно своими руками рассчитывать геометрические трансформации, в том числе в рамках CSS и SVG, строить 3D сцены, а также делать всевозможные фильтры для фотографий или для постобработки изображений в рамках WebGL. Все эти темы обычно выходят за рамки классического фронтенда и больше связаны с компьютерной графикой в целом, но, даже если вы не будете решать эти задачи непосредственно, знание принципов их решения позволит лучше понимать, как устроены некоторые ваши инструменты. Это лишним никогда не будет.

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

Подробнее..

Категории: Javascript , Разработка веб-сайтов , Математика , 3d-графика , Матрицы , Математика на пальцах , Фильтры изображений

Что нового в SOLIDWORKS 2021

22.01.2021 18:12:57 |

Автор: admin

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

SOLIDWORKS CAD

Проектирование сборок

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

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

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

В SOLIDWORKS всегда поддерживалось гибкое изменение конфигурации отдельных экземпляров компонентов в массивах. Иногда нужно, чтобы все компоненты ссылались на исходный экземпляр. Это может оказаться утомительной процедурой, поскольку выполняется для каждого компонента отдельно. Одна из новинок в SOLIDWORKS 2021 это опция, синхронизирующая конфигурации всех экземпляров компонентов в массиве. Она помогает избежать непреднамеренного изменения любого из этих компонентов через быстрое меню, блокируя изменения в диалоговом окне свойств компонента. Это также гарантирует корректность распространения изменений, вносимых в конфигурацию корневого компонента массива. Кроме того, массивы цепочек теперь могут строиться по траектории с заданием длины кривой (а не только длины хорды).

Метод Силуэт, впервые анонсированный в инструменте Defeature в SOLIDWORKS 2019, позволяет создать упрощенное представление сборки с целью защиты проектных данных от несанкционированного распространения, снижения визуальной загроможденности модели и улучшения производительности. Новинкой в SOLIDWORKS 2021 является возможность сохранять упрощенное представление в виде конфигурации в той же сборке, для которой оно было создано. Это избавляет от необходимости управлять отдельным файлом, содержащим упрощенную модель. Для использования упрощенного вида в сборках более высокого уровня достаточно щелкнуть правой кнопкой мыши на компоненте и выбрать Defeatured.

Конструирование деталей

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

Повышение производительности

Улучшена производительность при выполнении таких операций, как открытие, сохранение и закрытие сборок, обнаружение циклических ссылок и создание отчетов о них, а также добавление файлов в хранилище SOLILDWORKS PDM. Ускорено выполнение операций выбора, панорамирования и зумирования. При удалении скрытых объектов и формировании кромок силуэта в чертежах задействовано больше ресурсов графического процессора.

Пользовательский интерфейс

Инженеры давно ценят интуитивно понятный и настраиваемый пользовательский интерфейс SOLIDWORKS. Однако разработчики не успокаиваются на достигнутом! В SOLIDWORKS 2021 интерфейс стал еще более наглядным и удобным. Улучшена цветовая палитра, которая теперь может ссылаться на другие приложения, такие как веб-браузер. Поиск команд в диалоговом окне настройки позволяет легко компоновать панели инструментов. Диспетчер команд можно сворачивать, чтобы получить на экране больше места для работы, а благодаря полупрозрачным размерам упрощается выбор объектов.

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

Взаимодействие на платформе 3DEXPERIENCE

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

SOLIDWORKS 2021 предоставляет новые функциональные возможности для перехода от проектирования к производству. Конвертер производных форматов позволяет формировать обладающую высокой точностью геометрию для использования на всех стадиях разработки и выпуска продукции. Пользователи могут управлять режимами открытия данных, полученных из платформы 3DEXPERIENCE, и конфигурациями, сохраняемыми в этой платформе.

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

SOLIDWORKS Simulation

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

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

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

В SOLIDWORKS Flow Simulation 2021 расширен круг решаемых задач CFD и продолжает совершенствоваться обработка результатов. Для моделирования вращающихся потоков жидкости служит мощная функция Rotating Region. Теперь в Flow Simulation вращающиеся области можно комбинировать со свободно движущимися поверхностями. Это идеально подходит для задач моделирования смешивания и может быть использовано для анализа поведения изделий в эксплуатации.

SOLIDWORKS Plastics

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

SOLIDWORKS Electrical

Производительность трассировки проводов, кабелей и жгутов в 3D значительно улучшена. Теперь в траекториях наряду с отрезками и дугами также поддерживаются сплайны, что значительно повышает качество трассировки в геометрически сложных изделиях. Добавлены средства расчета массовых свойств системы электрических проводов, кабелей и жгутов внутри 3D-модели разрабатываемого изделия. Несколько проводов/кабелей могут быть закреплены зажимом. Сращивание проводов выполняется с помощью соединительного компонента или без него. В таблицах соединителей и библиотеке аксессуаров поддерживается конечная заделка.

В проектах часто бывает, что несколько кабелей, подключенных к одному и тому же разъему, идут к различным частям электрической системы. Трассировка такой группы кабелей в виде единой сборки не обеспечивает конструкторам достаточной гибкости в принятии решений. В SOLIDWORKS Electrical Schematic 2021 к свойствам кабеля добавлено новое поле, позволяющее отделять один кабель от других. Этот же параметр можно контролировать в команде трассировки кабелей SOLIDWORKS.

SOLIDWORKS PDM

Те, кто работает с SOLIDWORKS PDM, наверняка согласятся, что скорость работы в значительной степени определяется эффективностью базы данных. Благодаря улучшениям производительности в новой версии намного ускоряется выполнение большинства стандартных файловых операций и рабочих процессов. Стали быстрее работать такие функции, как добавление и возврат файлов в PDM-систему, изменение состояния, открытие, сохранение и удаление файлов.

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

Одной из самых полезных функций SOLIDWORKS PDM уже давно является интеграция с Проводником Windows. В 2021 версии расширена поддержка таких интерфейсных элементов Windows 10, как лента.

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

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

Предлагаем вам также ознакомиться с новшествами SOLIDWORKS 2021, посмотрев серию вебинаров:

Все вебинары на русском языке. Предварительная регистрация обязательна.

Подробнее..

Категории: Управление проектами , Работа с 3d-графикой , Анализ и проектирование систем , Cad/cam , 3d-моделирование , Cad , 3d-графика , 3d , Блог компании dassaultsystèmes , 3d моделирование , 3d проектирование , Solidworks , Solidworks 2020 , Solidworks 2021

Море, пираты 3D онлайн игра в браузере

09.07.2020 16:21:19 |

Автор: admin

Приветствую пользователей Хабра и случайных читателей. Это история разработки браузерной многопользовательской онлайн игры с low-poly 3D графикой и простейшей 2D физикой.

Позади немало браузерных 2D мини-игр, но подобный проект для меня в новинку. В gamedev решать задачи, с которыми ещё не сталкивался, может быть довольно увлекательно и интересно. Главное не застрять со шлифовкой деталей и запустить рабочую игру пока есть желание и мотивация, поэтому не будем терять время и приступим к разработке!

Об игре в двух словах

Бой на выживание единственный на данный момент режим игры. Сражения от 2 до 6 кораблей без перерождений, где последний выживший игрок считается победителем и получает х3 очков и золота.

Аркадное управление: кнопки W, A, D или стрелки для движения, пробел для залпа по вражеским кораблям. Прицеливаться не нужно, промахнуться нельзя, урон зависит от рандома и угла выстрела. Больший урон сопровождается медалькой точно в цель.

Зарабатываем золото занимая первые места в рейтингах игроков за 24 часа и за 7 дней (сброс в 00:00 по МСК) и выполняя ежедневные задания (на день выдается одно из трех, по очереди). Золото за сражения тоже есть, но меньше.

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

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

Стек технологий

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

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

Node.js потому что просто, быстро и удобно, хотя опыта непосредственно в Node.js не имел. В качестве альтернативы рассматривал Java, проводил пару локальных экспериментов в том числе с веб-сокетами, но сложно ли запустить джаву на VPS выяснять не решился. Ещё один вариант Go, его синтаксис вгоняет меня в уныние не продвинулся в его изучении ни на йоту.

Для веб-сокетов используется модуль ws в Node.js.

PHP и MySQL менее очевидный выбор, но критерий всё тот же быстро и просто, так как есть опыт в данных технологиях.

Получается вот такая схема:

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

Мне совсем не хотелось связывать игровой сервер с БД, поэтому всё идет через PHP. На мой взгляд тут есть свои плюсы, хотя не уверен значимы ли они. Например, так как в Node.js приходят уже готовые данные в нужном виде, Node.js не тратит время на обработку и дополнительные запросы в БД, а занимается более важными делами переваривает действия игроков и изменяет состояние игрового мира в комнатах.

Сначала модель

Разработка началась с простого и самого главного некой модели игрового мира, описывающей морские сражения с серверной точки зрения. Обычный canvas 2D для схематичного отображения модели на экране подходит идеально.

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

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

Клиентский JavaScript для визуализации модели игрового мира, обрабатывающий движение кораблей и выстрелы, я перенес на Node.js сервер почти без изменений.

Игровой сервер

Node.js WebSocket сервер состоит всего из 3 скриптов:

main.js основной скрипт, который получает WS сообщения от игроков, создаёт комнаты и заставляет шестеренки этой машины крутиться
room.js скрипт, отвечающий за игровой процесс внутри комнаты: обновление игрового мира, рассылка обновлений игрокам комнаты
funcs.js включает класс для работы с векторами, пару вспомогательных функций и класс реализующий двусвязный список

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

Актуальный список классов игрового сервера:

WaitRoom комната, куда попадают игроки ожидающие начала сражения, здесь есть собственный tick метод, рассылающий свои обновления и запускающий создание игровой комнаты когда больше половины игроков готовы к бою
Room игровая комната, где проходят сражения: обновляются состояния игроков/кораблей, затем обрабатываются возможные столкновения, в конце формируется и рассылается всем сообщение с актуальными данными
Player по сути обёртка с некоторыми дополнительными свойствами и методами для следующего класса:
Ship этот класс заставляет корабли плавать: реализует движение и повороты, здесь также хранятся данные о повреждениях, чтобы в конце игры зачислить очки игрокам, принимавшим участие в уничтожении корабля
PhysicsEngine класс, реализующий простейшие столкновения круглых объектов
PhysicsBody всё есть круглые объекты со своими координатами на карте и радиусом

Игровой цикл в классе Room выглядит примерно так

let upd = {p: [], t: this.gamet};let t = Date.now();let dt = t - this.lt;let nalive = 0;for (let i in this.players) {this.players[i].tick(t, dt);}this.physics.run(dt);for (let i in this.players) {upd.p.push(this.players[i].getUpd());}this.chronology.addLast(clone(upd));if (this.chronology.n > 30) this.chronology.remFirst();let updjson = JSON.stringify(upd);for (let i in this.players) {let pl = this.players[i];if (pl.ship.health > 0) nalive++;if (pl.deadLeave) continue;pl.cl.ws.send(updjson);}this.lt = t;this.gamet += dt;if (nalive <= 1) return false;return true;

Кроме классов, есть такие функции, как получить данные пользователя, обновить ежедневное задание, получить награду, купить скин. Эти функции в основном отправляют https запросы в PHP, который выполняет один или несколько MySQL запросов и возвращает результат.

Сетевые задержки

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

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

При решении проблемы лагов очень многое зависит от игры и её темпа. Я жертвую быстрым откликом на действия игрока в пользу плавности анимации и точного соответствия картинки состоянию игрового мира в некий момент времени. Единственное исключение залп из пушек воспроизводится незамедлительно по нажатию кнопки. Остальное можно списать на законы вселенной и излишек рома у команды корабля :)

Фронт-энд

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

3D корабль

Three.js поддерживает использование готовых 3D моделей различных форматов. Я выбрал для себя GLTF / GLB формат, где могут быть вшиты текстуры и анимация, т.е. разработчик не должен задаваться вопросом все ли текстуры загрузились?.

Раньше я ни разу не имел дела с 3D редакторами. Логичным шагом было обратиться к специалисту на фриланс бирже с задачей создания 3D модели парусного корабля с вшитой анимацией залпа из пушек. Но я не удержался от мелких изменений в готовой модели специалиста своими силами, а закончилось это тем, что я создал свою модель с нуля в Blender. Создать low-poly модель почти без текстур просто, сложно без готовой модели от специалиста изучить в 3D редакторе то, что нужно для конкретной задачи (как минимум морально :).

Шейдеры богу шейдеров

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

Механизм или способ, который я использовал при создании системы частиц для анимации повреждения корабля, динамичной водной поверхности или статичного морского дна один и тот же: специальный материал ShaderMaterial предоставляет упрощённый интерфейс использования своего шейдера (своего кода GLSL), BufferGeometry позволяет создавать геометрию из произвольных данных.

Пустая заготовка, структура кода, которую мне было удобно копировать, дополнять и изменять для создания своего 3D объекта подобным образом:

Показать код

let vs = `attribute vec4 color;varying vec4 vColor;void main(){vColor = color;gl_Position = projectionMatrix * modelViewMatrix * vec4( position, 1.0 );// gl_PointSize = 5.0; // for particles}`;let fs = `uniform float opacity;varying vec4 vColor;void main() {gl_FragColor = vec4(vColor.xyz, vColor.w * opacity);}`;let material = new THREE.ShaderMaterial( {uniforms: {opacity: {value: 0.5}},vertexShader: vs,fragmentShader: fs,transparent: true});let geometry = new THREE.BufferGeometry();//let indices = [];let vertices = [];let colors = [];/* ... *///geometry.setIndex( indices );geometry.setAttribute( 'position', new THREE.Float32BufferAttribute( vertices, 3 ) );geometry.setAttribute( 'color', new THREE.Float32BufferAttribute( colors, 4 ) );let mesh = new THREE.Mesh(geometry, material);

Повреждение корабля

Анимация повреждения корабля это движущиеся, изменяющие свой размер и цвет частицы, поведение которых определяется их атрибутами и GLSL кодом шейдера. Генерация частиц (геометрия и материал) происходит заранее, затем для каждого корабля создаётся свой экземпляр (Mesh) частиц урона (геометрия общая для всех, материал клонируется). Атрибутов частиц получилось довольно много, зато созданный шейдер реализует одновременно и большие медленно движущиеся облака пыли, и быстро разлетающиеся обломки, и частицы огня, активность которых зависит от степени повреждения корабля.

Море

Море также реализовано с помощью ShaderMaterial. Каждая вершина движется во всех 3-х направлениях по синусоиде образуя рандомные волны. Атрибуты определяют амплитуды для каждого направления движения и фазу синусоиды.

Чтобы разнообразить цвета на воде и сделать игру интереснее и приятнее глазу было решено добавить дно и острова. Цвет дна зависит от высоты/глубины и просвечивает сквозь водную поверхность создавая темные и светлые области.

Морское дно создаётся из карты высот, которая создавалась в 2 этапа: сначала в графическом редакторе было создано дно без островов (в моём случае инструментами были render -> clouds и Gaussian blur), затем средствами Canvas JS онлайн на jsFiddle в случайном порядке были добавлены острова рисованием окружности и размытием. Некоторые острова низкие, через них можно стрелять в противников, другие имеют определённую высоту, через них выстрелы не проходят. Кроме самой карты высот, на выходе я получаю данные в json формате об островах (их положение и размеры) для физики на сервере.

Что дальше?

Есть много планов по развитию игры. Из крупных новые режимы игры. Более мелкие придумать тени/отражение на воде с учетом ограничений производительности WebGL и JS. Про возможность разбудить Кракена я уже упоминал :) Ещё не реализовано объединение игроков в комнаты на основе их накопленного опыта. Очевидное, но не слишком приоритетное усовершенствование создать несколько карт морского дна и островов и выбирать для нового сражения одну из них случайным образом.

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

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

Пасхалка

Кто не любит вспомнить старые компьютерные игры, которые дарили так много эмоций? Мне нравится перепроходить игру Корсары 2 (она же Sea Dogs 2) снова и снова до сих пор. Не мог не добавить в свою игру секрет и явно и косвенно напоминающий о Корсарах 2. Не стану раскрывать все карты, но дам подсказку: моя пасхалка это некий объект, который вы можете найти исследуя морские просторы (далеко плыть по бескрайнему морю не нужно, объект находится в пределах разумного, но всё же вероятность найти его не высока). Пасхальное яйцо полностью восстанавливает поврежденный корабль.

Что получилось

Минутное видео (тест с 2 устройств):

Ссылка на игру: https://sailfire.pw

Там же есть форма для связи, сообщения летят мне в телеграм: https://sailfire.pw/feedback/

Подробнее..

Категории: Node.js , Разработка игр , Игры , 3d-графика , Three.js , Websocket , Реал-тайм

3D в визуализации стрелкового оружия скромные успехи и большие перспективы

03.05.2021 20:08:12 |

Автор: admin

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

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

Симуляторы

Оружейные симулятор достаточно редкий игровой жанр. Наиболее известным сегодня является World of Guns: Gun Disassembly. Он существует в виде десктопного и мобильного приложения, где можно собрать и разобрать оружие, посмотреть на работу автоматики.
World of Guns является первым из сравнительно точных, унифицированных симуляторов, где можно внимательно рассмотреть каждую деталь оружия и увидеть, как работает автоматика. Сегодня сложно представить себе более детального симулятора, связанного с оружием.

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

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

Игра получила массу лестных отзывов, в частности, фаундер The Firearm Blog Стив Джонсон назвал World of Guns своим любимым оружейным приложением, сказав, что узнал много нового благодаря игре. Он рассказал, что дополнил своё представление о принципах работы некоторых образцов из его коллекции.

В целом, это выглядит вот так и на текущий момент ничего лучше пока не придумали. Существует также Android-приложение с русским названием Разборка оружия, выпущенное Sega SVD, которое не очень сильно отличается от World of Guns: Gun Disassembly.
Выглядит всё это дело вот так:

Неигровая визуализация

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

В первом случае, ни о какой интерактивности речь, в принципе, не идёт. Модели и их демонстрация не очень сильно отличается от World of Guns. С той лишь разницей, что в этих роликах и моделях на каких-то вещах немного акцентировали внимание.

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

Посмотреть как это работает можно здесь:
АК-15 с прицелом Валдай ПК120, камуфляж Арктика
АК-15 с прицелом Валдай ПК120, камуфляж Пустыня
АК-15 без прицела и камуфляжа

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

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

В них будет реализована возможность отображать работу узлов и механизмов стрелкового оружия, его отдельных частей и деталей, будет эмулироваться стрельба с прозрачным корпусом, приблизительно также как это реализовано в World of Guns. При этом разработчики обещают более высокую реалистичность и дополнительный текстовый контент.

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

Свято место не бывает в пустоте

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

Подробнее..

Категории: Визуализация данных , Повышение конверсии , 3d-графика , Оружие , Трехмерная визуализация , Оружие в играх , Визуализация оружия , Визуализация стрелкового оружия , 3d контент , 3d модели оружия

Перевод Разница между фальшивыми и истинными смещениями в 3D-графике

22.06.2020 20:08:04 |

Автор: admin

Bump maps (рельефные текстуры), Normal maps (карты нормалей), Displacement и Vector Displacement вероятно, вы уже сталкивались хотя бы с одним из этих терминов. Несмотря на то, что о них уже есть много информации, похоже, многие путают их различия и последствия использования разных типов карт. В статье я расскажу о том, какие проблемы могут вызывать эти карты.

Все четыре типа текстур имеют одинаковое предназначение они позволяют добавить на поверхность модели дополнительные детали, используя для этого разные способы. Эти способы можно разделить на две категории, которые я буду называть истинными смещениями (True Displacements) и фальшивыми смещениями (Fake Displacements). Истинные смещения перемещают вершины, а фальшивые стремятся достичь того же внешнего вида без изменения геометрии. Пока я сосредоточусь только на различиях между двумя категориями, а не буду анализировать каждую карту по отдельности.

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

Примечание на случай, если вы задаётесь вопросом, почему не упомянуты карты высот. Термин карта высот (Height map) описывает способ хранения информации, а не применения её к мешу. Карты высот могут применяться и как Bump, и как Displacement. В таких пакетах, как Substance используется этот термин, потому что в них карту высот можно использовать и как истинное, и как фальшивое смещение.

Прежде чем двигаться дальше, нужно упомянуть, что я VFX-художник, поэтому буду рассматривать тему с точки зрения VFX с использованием рендеринга с трассировкой пути (path tracing). Если вы используете другой способ рендеринга (например, игровые движки), то результаты будут отличаться. Возможно, в вашем движке даже имеется полная поддержка истинных смещений.

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

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

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

Карты нормалей называются так, потому что позволяют нам попиксельно хранить любые нормали поверхностей. Это означает, что мы можем свободно манипулировать направлением отражения лучей света, не изменяя при этом геометрию. Рельефные текстуры (Bump maps) преобразуют информацию о высотах в нормали поверхности во время рендеринга. Это означает, что для лучей света, которые, по сути, являются глазами движков рендеринга, нормали и Bump maps выглядят одинаково.

Слева направо: низкополигональная модель, истинное смещение, фальшивое смещение

Мы можем имитировать результаты истинного смещения, сопоставив угол нормали поверхности. В таком простом примере это может выглядеть удовлетворительно, но отсутствие деформации геометрии приводит ко всевозможным артефактам. Неважно, какой подтип текстур вы используете Bump или Normal, Displacement или Vector Displacement, а также способ изготовления текстур запекание или создание, артефакты зависят только от категории, потому что все они являются результатом того, что фальшивые смещения не деформируют геометрию, а истинные деформируют.

Воздействие на освещение

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

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

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

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

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

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

Кроме отсутствия отбрасываемых теней и недостатка отражённого света, к воздействию на освещение относится ещё один эффект. Он связан с тем, как геометрия принимает тени.

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

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

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

Кроме того, всё больше тени исчезает за самой геометрией.

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

Глядя на последний рендер, вы могли заметить кое-что ещё. Хоть карта нормалей и воспроизводит те же значения яркости, пирамида всё равно выглядит очень плоской. Это вызвано эффектом, который я опишу ниже.

Параллакс

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

Красными линиями я показал области, находящиеся у всех трёх объектах на одинаковой глубине, чтобы они могли служить отправной точкой. Синие линии сдвинуты вниз смещением. При взгляде сверху вниз истинное и фальшивое смещения выглядят почти одинаковыми, однако под углами падения линии на низкополигональной версии и версии с фальшивым смещением (Lowpoly и Fake Displacement) сохраняют равное расстояние, а на меше с использованием истинного смещения (True Displacement) они визуально движутся. Если мы наклоним камеру чуть дальше, то синяя линия на дальней части плоскости полностью исчезнет за центральной линией. При сдвиге синих линий вверх эффект будет обратным передняя синяя линия почти полностью закроет центральную красную.

Некоторые игровые движки позволяют создавать фальшивый параллакс, называемый Parallax-mapping, при котором 2D-искажение применяется к отрендеренным пикселям, а не к геометрии. Это повышает точность, но влияет на производительность.

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

Углы в 90 градусов

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

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

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

Силуэт

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

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

Подповерхностное рассеяние

Если в создаваемом вами графическом ассете используется Sub Surface Scattering (SSS), то вы сможете наблюдать ещё один недостаток фальшивого смещения.

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

Чёрные области или растянутые отражения

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

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

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

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

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

Хоть я и не сталкивался с рендерерами, в которых применяется третий вариант, мне известен случай, в котором используется тот же принцип. Применение Soft Edges/Smooth Normals (разные названия одного понятия) к мешу интерполирует нормали поверхностей для имитации более плавной поверхности меша.

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

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

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

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

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

Диэлектрические материалы отражают бОльшую часть падающего на них света под совершенно случайным углом, это называется рассеянным отражением (Diffuse Reflection), и только очень малая доля лучей отражается как зеркальное отражение (Specular Reflection). Это означает, что даже если поверхность совершенно глянцевая, проблема едва будет заметной.

Эти изображения отрендерены в Arnold; если изолировать Specular Reflection, мы всё равно можем видеть чёрные области, но они не особо заметны на финальном рендере.

Тесселяция/подразделение

Все описанные выше артефакты касались фальшивого смещения, но этот недостаток проявляется при использовании истинного смещения. Само по себе истинное смещение может создавать/воссоздавать только ту величину детализации, которую поддерживают полигоны. Это значит, что сначала нам нужно тесселировать/подразделить меш. Если не подразделять их достаточно мелко, то у нас всё равно может получиться геометрия, не поддерживающая все мелкие детали, хранящиеся в текстуре. Это означает, что может потребоваться сильное подразделение (subdivision) модели, из-за чего сцена станет очень тяжёлой. К счастью, современные движки рендеринга имеют функцию автоматического добавления детализации, которая не может поддерживаться геометрией как фальшивое смещение. В некоторых рендерерах эта функция по умолчанию отключена, поэтому проверьте её. К сожалению, пока для неё не сложилось стандартного названия. В Arnold, например, она называется Autobump, а в Cycles Displacement + Bump.

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

Увы, но эта функция имеет свои баги, и многие аспекты могут привести к её неправильной работе, например, отсутствие фиксации масштаба/применения масштаба к объекту. Кроме того, может вызывать сложности использование Autobump с Vector Displacement.

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

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

Заключение

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

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

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

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

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

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

https://magazine.substance3d.com/your-smartphone-is-a-material-scanner-vol-ii/

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

Подробнее..

Категории: Работа с 3d-графикой , Cgi (графика) , Нормали , Bump mapping , Рельефное текстурирование , Normal mapping , Карты нормалей , Displacement , Vector displacement , 3d-графика

3D ML. Часть 4 дифференциальный рендеринг

23.09.2020 16:18:12 |

Автор: admin

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

Мы поговорим о том, почему традиционный пайплайн рендеринга не дифференцируем, зачем исследователям в области 3D ML потребовалось сделать его дифференцируемым и как это связано с нейронным рендерингом. Какие существуют подходы к конструированию таких систем, и рассмотрим конкретный пример SoftRasterizer и его реализацию в PyTorch 3D. В конце, с помощью этой технологии, восстановим все пространственные характеристики Моны Лизы Леонардо Да Винчи так, если бы картина была не написана рукой мастера, а отрендерена с помощью компьютерной графики.

Серия 3D ML на Хабре:

Формы представления 3D данных
Функции потерь в 3D ML
Датасеты и фреймворки в 3D ML
Дифференциальный рендеринг

Репозиторий на GitHub для данной серии заметок.

Заметка от партнера IT-центра МАИ и организатора магистерской программы VR/AR & AI компании PHYGITALISM.

Rendering pipeline: forward and inverse

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

Задачи, в которых из 3D сцены мы хотим сгенерировать изображение (такие задачи можно отнести к традиционным задачам компьютерной графике) т.н. forward rendering;
Задачи, где по изображению нам требуется восстанавливать параметры 3D объектов (такие задачи относятся скорее к компьютерному зрению) т.н. inverse rendering.

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

Рис.1 Из презентации TensorFlow Graphics (github page).

В качестве примера такой задачи, можно рассмотреть задачу 3D mesh reconstruction from single image, которую мы уже упоминали в предыдущих заметках. С одной стороны, эту задачу можно решать сравнивая ошибку рассогласования между исходной моделью и предсказанной с помощью функций потерь для 3D объектов (заметка 2 данной серии). С другой стороны, можно генерировать 3D объект сначала, а после его отрендеренную картинку сравнивать с изображением-образцом (пример на рис.2).

Рис.2 Модель деформации меша с помощью модуля дифференциального рендеринга SoftRas (github page).

Далее, при разговоре про рендеринг, мы будем рассматривать несколько основных компонентов 3D сцены:

3D объект, описываемый своим мешем;
камера с набором характеристик (позиция, направление, раствор и т.д.);
источники света и их характеристики;
глобальные характеристики расположения объекта на сцене, описываемые матрицами преобразований.

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

Давайте поговорим сначала о том, из каких этапов состоит традиционный пайплайн прямого рендеринга и почему он не является дифференцируемым.

Why is rendering not differentiable?

Рис.3 Схема традиционного рендеринга и рендеринга методом Soft Rasterizer [1]. Здесь: $inline$ меш объекта на сцене, $inline$ модель камеры, $inline$ модель источника освещения, $inline$ модель текстуры, $inline$ карта нормалей для меша, $inline$ карта глубины получаемого изображения, $inline$ матрица преобразования 3D в 2D для получения плоского изображения, $inline$ растеризованное изображение, $inline$ вероятностные карты метода Soft Rasterizer, $I,\bar I$ изображения полученные традиционным рендерингом и методом SoftRas соответственно. Красные блоки недифференцируемые операции, синии дифференцируемые.

Процедуру рендеринга можно подразделить на несколько взаимозависимых этапов (этапы традиционного рендеринга приведены на рис.3 врехняя линия в правой части). Какие-то этапы, к примеру вычисления освещения и позиции камеры, являются дифференцируемыми, поскольку в них участвуют непрерывные функциональные зависимости (см. модель Фонга, на Хабре о ней и моделях освещения писали здесь и здесь), но два последних этапа не являются дифференцируемыми. Давайте разберемся почему.

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

Грубо говоря, проблему недифференцируемости растеризации можно описать так: пиксели дискретные структуры, с постоянным цветом, а исходная модель непрерывна, поэтому при проецировании из 3D в 2D часть информации теряется.

Проиллюстрируем две основные проблемы с дифференцируемостью при вычислении цвета и расстояния.

Проблема 1 (недифференцируемость цвета по глубине)

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

Проблема 2 (недифференцируемость цвета при сдвигах)

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

Make it differentiable! Soft Rasterizer

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

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

Loper, M.M. and Black, M.J., 2014, September. OpenDR: An approximate differentiable renderer. In European Conference on Computer Vision (pp. 154-169). Springer, Cham.
Kato, H., Ushiku, Y. and Harada, T., 2018. Neural 3d mesh renderer. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 3907-3916).
Li, T.M., Aittala, M., Durand, F. and Lehtinen, J., 2018. Differentiable monte carlo ray tracing through edge sampling. ACM Transactions on Graphics (TOG), 37(6), pp.1-11.
Liu, S., Li, T., Chen, W. and Li, H., 2019. Soft rasterizer: A differentiable renderer for image-based 3d reasoning. In Proceedings of the IEEE International Conference on Computer Vision (pp. 7708-7717).
Chen, W., Ling, H., Gao, J., Smith, E., Lehtinen, J., Jacobson, A. and Fidler, S., 2019. Learning to predict 3d objects with an interpolation-based differentiable renderer. In Advances in Neural Information Processing Systems (pp. 9609-9619).

Подходы основаны на разных идеях и приемах. Мы подробно остановимся только на одном, Soft Rasterizer, по двум причинам: во-первых, идея данного подхода математически прозрачна и легко реализуема самостоятельно, во-вторых, данный подход реализован и оптимизирован внутри библиотеки PyTorch 3D [6].

Подробно со всеми аспектами реализации дифференциального рендеринга этим методом можно ознакомиться в соответствующей статье [1], мы же отметим основные моменты.

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

Размытие границ предполагает введение некоторой гладкой вероятностной функции $inline$ , которая каждой внутренней или внешней точки пространства $inline$ ставит в соответствие число от 0 до 1 вероятности принадлежности к данному полигону $inline$ (чем-то похоже на подход нечеткой логики). Здесь $\sigma$ параметр размытия (чем больше $\sigma$ , тем больше размытие), $inline$ кратчайшее расстояние в проекционной плоскости от проекции точки $inline$ до границы проекции полигона $inline$ (данное расстояние обычно выбирают Евклидовым, но авторы метода отмечают, что здесь есть простор для экспериментов и, например, использование барицентрического расстояния или $inline$ также подходит для их метода), $\delta_j^i$ функция, которая равна 1 если точка находится внутри полигона и -1 если вне (на границе полигона можно доопределить значение $\delta$ нулем, однако это все равно приводит к тому, что на границе полигона данная функция разрывна, поэтому для точек границ она не применяется), $inline$ сигмоидная функция активации, которая часто применяется в глубоком обучении.

Для решения проблемы 1, авторы метода предлагают использовать смешение цветов k ближайших полигонов (blending).

Коротко этот прием можно описать следующим образом: для вычисления итогового цвета $inline$ -го пикселя $inline$ , производят нормированное суммирование цветовых карт $inline$ для k ближайших полигонов $inline$ , причем цветовые карты получают путем интерполяции барицентрических координат цвета вершин данных полигонов. Индекс $inline$ в формуле отвечает за фоновый цвет (background colour), а оператор $\mathcal{A}_{S}$ оператор агрегирование цвета. $inline$ глубина $inline$ -го пикселя относительно $inline$ -го полигона, а $\gamma$ параметр смешивания (чем он меньше, тем сильнее превалирует цвет ближайшего полигона).

Итоговой подход Soft Rasterizer, заключается в комбинировании этих двух идей, для одновременного плавного размытия границы и цвета.

Рис.4 Схема реализации дифференциального рендеринга в PyTorch 3D (слайд из презентации фреймворка).

Реализация Soft Rasterizer внутри библиотеки PyTorch 3D выполнена так, чтобы максимально эффективно и удобно использовать возможности как базового фреймворка PyTorch, так и возможности технологии CUDA. По сравнению с оригинальной реализацией [github page], разработчикам фреймворка удалось добиться 4-х кратного приращения скорости обработки (особенно для больших моделей), при этом возрастает расход памяти за счет того, что для каждого типа данных (ката глубины, карта нормалей, рендер текстур, карта евклидовых расстояний) нужно просчитать k слоев и хранить их в памяти.

Рис.5 Сравнение характеристик дифференциального рендеринга в PyTorch 3D (слайд из презентации фреймворка).

Поэкспериментировать с настройками дифференциального рендера можно как в PyTorch 3D, так в библиотеке с оригинальной реализацией алгоритма Soft Rasterizer. Давайте рассмотрим пример, демонстрирующий зависимость итоговой картинки отрендеренной модели от параметров дифференциального рендера \sigma, \gamma.

Удобнее всего работать с этой библиотекой в виртуальном окружении anaconda, так как данная библиотека работает уже не с самой актуальной версией pytorch 1.1.0. Также обратите внимание что вам потребуется видеокарта с поддержкой CUDA.

Импорт библиотек и задание путей до обрабатываемых моделей

import matplotlib.pyplot as pltimport osimport tqdmimport numpy as npimport imageioimport soft_renderer as srinput_file = 'path/to/input/file'output_dir = 'path/to/output/dir'

Зададим начальные параметры камеры для рендеринга, загрузим меш объекта с текстурами (есть мод для работы без текстур, в этом случае нужно указать texture_type=vertex), инициализируем дифференциальный рендер и создадим директорию для сохранения результатов.

# camera settingscamera_distance = 2.732elevation = 30azimuth = 0# load from Wavefront .obj filemesh = sr.Mesh.from_obj(                         input_file,                          load_texture=True,                          texture_res=5,                          texture_type='surface')# create renderer with SoftRasrenderer = sr.SoftRenderer(camera_mode='look_at')os.makedirs(args.output_dir, exist_ok=True)

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

# draw object from different viewloop = tqdm.tqdm(list(range(0, 360, 4)))writer = imageio.get_writer(                            os.path.join(output_dir, 'rotation.gif'),                              mode='I')for num, azimuth in enumerate(loop):    # rest mesh to initial state    mesh.reset_()    loop.set_description('Drawing rotation')    renderer.transform.set_eyes_from_angles(                                            camera_distance,                                             elevation,                                             azimuth)    images = renderer.render_mesh(mesh)    image = images.detach().cpu().numpy()[0].transpose((1, 2, 0))    writer.append_data((255*image).astype(np.uint8))writer.close()

Теперь поиграемся со степенью размытия границы и степенью смешения цветов. Для этого будем в цикле увеличивать параметр размытия $\sigma$ и одновременно увеличивать параметр смешения цвета $\gamma$ .

# draw object from different sigma and gammaloop = tqdm.tqdm(list(np.arange(-4, -2, 0.2)))renderer.transform.set_eyes_from_angles(camera_distance, elevation, 45)writer = imageio.get_writer(                            os.path.join(output_dir, 'bluring.gif'),                             mode='I')for num, gamma_pow in enumerate(loop):    # rest mesh to initial state    mesh.reset_()    renderer.set_gamma(10**gamma_pow)    renderer.set_sigma(10**(gamma_pow - 1))    loop.set_description('Drawing blurring')    images = renderer.render_mesh(mesh)    image = images.detach().cpu().numpy()[0].transpose((1, 2, 0))    writer.append_data((255*image).astype(np.uint8))writer.close()# save to textured objmesh.reset_()mesh.save_obj(              os.path.join(args.output_dir, 'saved_spot.obj'),               save_texture=True)

Итоговый результат на примере стандартной модели текстурированной коровы (cow.obj, cow.mtl, cow.png удобно скачивать, например, с помощью wget) выглядит так:

Neural rendering

Дифференциальный рендеринг как базовый инструмент для 3D ML, позволяет создавать очень много интересных архитектур глубокого обучения в области, которая получила названия нейронный рендеринг (neural rendering). Нейронный рендеринг позволяет решать множество задач, связанных с процедурой рендеринга: от добавления новых объектов на фото и в видеопоток до сверхбыстрого текстурирования и рендеринга сложных физических процессов.

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

большая обзорная статья SOTA архитектур в области нейронного рендеринга [7] на основе прошедшей CVPR 2020;
видео с записью утренней и дневной сессией по нейтронному рендерингу с CVPR 2020, на основе которых и была написана статья из предыдущего пункта;
видеолекция MIT DL Neural rendering с кратким обзором основных подходов и введении в тему;
заметка на Medium на тему дифференциального рендеринга и его приложений;
видео с youtube канала two minute papers на данную тему.

Experiment: Mona Liza reconstruction

Разберем пример применения дифференциального рендеринга для восстановления параметров 3D сцены по исходному изображению человеческого лица, представленный в пуле примеров библиотеки redner, которая является реализацией идей, изложенных в статье [ 4 ].

В данном примере, мы будем использовать т.н. 3D morphable model [8] технику текстурированного трехмерного моделирования человеческого лица, ставшую уже классической в области анализа 3D. Техника основана на получение такого крытого представления признаков 3D данных, которое позволяет строить линейные комбинации, сочетающие физиологические особенности человеческих лиц (если так можно выразиться, то это своеобразный Word2Vec от мира 3D моделирования человеческих лиц).

Для работы с примером вам потребуется датасет Basel face model (2017 version). Файл model2017-1_bfm_nomouth.h5 необходимо будет разместить в рабочей директории вместе с кодом.

Для начала загрузим необходимы для работы библиотеки и датасет лиц.

Загрузка библиотек

import torchimport pyrednerimport h5pyimport urllibimport timefrom matplotlib.pyplot import imshow%matplotlib inlineimport matplotlib.pyplot as pltfrom IPython.display import display, clear_outputfrom matplotlib import animationfrom IPython.display import HTML

# Load the Basel face modelwith h5py.File(r'model2017-1_bfm_nomouth.h5', 'r') as hf:    shape_mean = torch.tensor(hf['shape/model/mean'],                               device = pyredner.get_device())    shape_basis = torch.tensor(hf['shape/model/pcaBasis'],                                device = pyredner.get_device())    triangle_list = torch.tensor(hf['shape/representer/cells'],                                  device = pyredner.get_device())    color_mean = torch.tensor(hf['color/model/mean'],                               device = pyredner.get_device())    color_basis = torch.tensor(hf['color/model/pcaBasis'],                                device = pyredner.get_device())

Модель лица в таком подходе разделена отдельно на базисный вектор формы shape_basis (вектор длины 199 полученный методом PCA), базисный вектор цвета color_basis (вектор длины 199 полученный методом PCA), также имеем усредненный вектор формы и цвета shape_mean, color_mean. В triangle_list хранится геометрия усредненного лица в форме полигональной модели.

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

indices = triangle_list.permute(1, 0).contiguous()def model(        cam_pos,         cam_look_at,         shape_coeffs,         color_coeffs,         ambient_color,         dir_light_intensity):    vertices = (shape_mean + shape_basis @ shape_coeffs).view(-1, 3)    normals = pyredner.compute_vertex_normal(vertices, indices)    colors = (color_mean + color_basis @ color_coeffs).view(-1, 3)    m = pyredner.Material(use_vertex_color = True)    obj = pyredner.Object(vertices = vertices,                           indices = indices,                           normals = normals,                           material = m,                           colors = colors)    cam = pyredner.Camera(position = cam_pos,                          # Center of the vertices                                                    look_at = cam_look_at,                          up = torch.tensor([0.0, 1.0, 0.0]),                          fov = torch.tensor([45.0]),                          resolution = (256, 256))    scene = pyredner.Scene(camera = cam, objects = [obj])    ambient_light = pyredner.AmbientLight(ambient_color)    dir_light = pyredner.DirectionalLight(torch.tensor([0.0, 0.0, -1.0]),                                           dir_light_intensity)    img = pyredner.render_deferred(scene = scene,                                    lights = [ambient_light, dir_light])    return img

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

cam_pos = torch.tensor([-0.2697, -5.7891, 373.9277])cam_look_at = torch.tensor([-0.2697, -5.7891, 54.7918])img = model(cam_pos,             cam_look_at,             torch.zeros(199, device = pyredner.get_device()),            torch.zeros(199, device = pyredner.get_device()),            torch.ones(3),             torch.zeros(3))imshow(torch.pow(img, 1.0/2.2).cpu())face_url = 'https://raw.githubusercontent.com/BachiLi/redner/master/tutorials/mona-lisa-cropped-256.png'urllib.request.urlretrieve(face_url, 'target.png')target = pyredner.imread('target.png').to(pyredner.get_device())imshow(torch.pow(target, 1.0/2.2).cpu())

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

# Set requires_grad=True since we want to optimize them latercam_pos = torch.tensor([-0.2697, -5.7891, 373.9277],                        requires_grad=True)cam_look_at = torch.tensor([-0.2697, -5.7891, 54.7918],                            requires_grad=True)shape_coeffs = torch.zeros(199, device = pyredner.get_device(),                            requires_grad=True)color_coeffs = torch.zeros(199, device = pyredner.get_device(),                            requires_grad=True)ambient_color = torch.ones(3, device = pyredner.get_device(),                            requires_grad=True)dir_light_intensity = torch.zeros(3, device = pyredner.get_device(),                                   requires_grad=True)# Use two different optimizers for different learning ratesoptimizer = torch.optim.Adam(                             [                              shape_coeffs,                               color_coeffs,                               ambient_color,                               dir_light_intensity],                              lr=0.1)cam_optimizer = torch.optim.Adam([cam_pos, cam_look_at], lr=0.5)

Остается организовать, оптимизационный цикл и логировать происходящее с функцией ошибки (в нашем случае это попиксельный MSE + квадратичные регуляризаторы параметров) и с самой 3D моделью.

plt.figure()imgs, losses = [], []# Run 500 Adam iterationsnum_iters = 500for t in range(num_iters):    optimizer.zero_grad()    cam_optimizer.zero_grad()    img = model(cam_pos, cam_look_at, shape_coeffs,                 color_coeffs, ambient_color, dir_light_intensity)    # Compute the loss function. Here it is L2 plus a regularization     # term to avoid coefficients to be too far from zero.    # Both img and target are in linear color space,     # so no gamma correction is needed.    loss = (img - target).pow(2).mean()    loss = loss          + 0.0001 * shape_coeffs.pow(2).mean()          + 0.001 * color_coeffs.pow(2).mean()    loss.backward()    optimizer.step()    cam_optimizer.step()    ambient_color.data.clamp_(0.0)    dir_light_intensity.data.clamp_(0.0)    # Plot the loss    f, (ax_loss, ax_diff_img, ax_img) = plt.subplots(1, 3)    losses.append(loss.data.item())    # Only store images every 10th iterations    if t % 10 == 0:        # Record the Gamma corrected image        imgs.append(torch.pow(img.data, 1.0/2.2).cpu())     clear_output(wait=True)    ax_loss.plot(range(len(losses)), losses, label='loss')    ax_loss.legend()    ax_diff_img.imshow((img -target).pow(2).sum(dim=2).data.cpu())    ax_img.imshow(torch.pow(img.data.cpu(), 1.0/2.2))    plt.show()

Чтобы лучше понимать что происходило со сценой в процессе обучения можем сгенерировать анимацию из наших логов:

fig = plt.figure()# Clamp to avoid complainsim = plt.imshow(imgs[0].clamp(0.0, 1.0), animated=True)def update_fig(i):    im.set_array(imgs[i].clamp(0.0, 1.0))    return im,anim = animation.FuncAnimation(fig, update_fig,                                frames=len(imgs), interval=50, blit=True)HTML(anim.to_jshtml())

Conclusions

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

Существуют несколько популярных библиотек глубокого вычисления (например Kaolin, PyTorch 3D, TensorFlow Graphics), которые содержат дифференциальный рендеринг как составную часть. Также существуют отдельные библиотеки, реализующие функционал дифференциального рендеринга (Soft Rasterizer, redner). С их помощью можно реализовывать множество интересных проектов, вроде проекта с восстановлением параметров лица и текстуры портрета человека.

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

References

Liu, S., Li, T., Chen, W. and Li, H., 2019. Soft rasterizer: A differentiable renderer for image-based 3d reasoning. In Proceedings of the IEEE International Conference on Computer Vision (pp. 7708-7717). [ paper ]
Loper, M.M. and Black, M.J., 2014, September. OpenDR: An approximate differentiable renderer. In European Conference on Computer Vision (pp. 154-169). Springer, Cham. [ paper ]
Kato, H., Ushiku, Y. and Harada, T., 2018. Neural 3d mesh renderer. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 3907-3916). [ paper ]
Li, T.M., Aittala, M., Durand, F. and Lehtinen, J., 2018. Differentiable monte carlo ray tracing through edge sampling. ACM Transactions on Graphics (TOG), 37(6), pp.1-11. [ paper ]
Chen, W., Ling, H., Gao, J., Smith, E., Lehtinen, J., Jacobson, A. and Fidler, S., 2019. Learning to predict 3d objects with an interpolation-based differentiable renderer. In Advances in Neural Information Processing Systems (pp. 9609-9619). [ paper ]
Ravi, N., Reizenstein, J., Novotny, D., Gordon, T., Lo, W.Y., Johnson, J. and Gkioxari, G., 2020. Accelerating 3D Deep Learning with PyTorch3D. arXiv preprint arXiv:2007.08501. [ paper ] [ github ]
Tewari, A., Fried, O., Thies, J., Sitzmann, V., Lombardi, S., Sunkavalli, K., Martin-Brualla, R., Simon, T., Saragih, J., Niener, M. and Pandey, R., 2020. State of the Art on Neural Rendering. arXiv preprint arXiv:2004.03805. [ paper ]
Blanz, V. and Vetter, T., 1999, July. A morphable model for the synthesis of 3D faces. In Proceedings of the 26th annual conference on Computer graphics and interactive techniques (pp. 187-194). [ paper ][ project page ]

Подробнее..

Категории: Работа с 3d-графикой , Python , Искусственный интеллект , Machine learning , Pytorch , Deep learning , 3d-графика , Блог компании it-центр маи

Перевод Рендеринг кадра Cyberpunk 2077

18.12.2020 14:16:13 |

Автор: admin

Введение

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

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

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

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

Эта статья ни в коем случае не является серьёзной попыткой реверс-инжиниринга.

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

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

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

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

Захваты выполнялись при высоких настройках графики, без RTX и DLSS, поскольку RenderDoc их не поддерживает (возможно, пока?). Я отключил Motion blur и другие неинтересные постэффекты и сделал так, чтобы игрок перемещался на всех захватах. Это даёт чуть больше понимания о передаче доступа к данным предыдущих кадров.

Кроме того, не использовалась никакая инсайдерская информация, так проще и веселее.

Основы

На первый взгляд, описать ядро рендеринга Cyberpunk 2077 можно очень кратко. Это классический отложенный рендерер (deferred renderer) с довольно ванильной схемой g-буфера. Мы не видим здесь безумного количества буферов, как, например, в Spiderman компании Suckerpunch, выпущенной на PS4. Нет здесь и сложной упаковки битов и реинтерпретации каналов.

Нормали формата 10.10.10.2 с 2-битным альфа-каналом, зарезервированным для того, чтобы помечать волосы.
Albedo в формате 10.10.10.2. Непонятно, что здесь делает альфа-канал, похоже для всего отрисовываемого он равен единице, но, возможно, так только в тех захватах, которые у меня есть.
Metalness, Roughness, Translucency и Emissive в формате 8.8.8.8 (в порядке RGBA)
Z-буфер и стенсил-буфер. Последний, похоже, используется для изоляции типов объектов/материалов. Движущиеся объекты помечены. Кожа, автомобили, растительность, волосы, дороги. Сложно понять значение каждой части, но общий смысл вам ясен...

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

Этот предварительный проход глубин частичен (не отрисовывает всю сцену) и используется только для снижения объёма перерисовки в последующем проходе g-буфера.

По сути, во всех отрисовках геометрии используется инстансинг и некая разновидность bindless-текстур. Могу предположить, что это была большая часть обновления движка из The Witcher 3 для адаптации под современное оборудование.

К сожалению, из-за bindless смотреть на захват renderDoc довольно напрягающе при выборочной проверке я не могу найти особо много разных шейдеров в проходе g-буфера. Вероятно, это признак того, что художникам не разрешили создавать шейдеры при помощи визуальных графов?

Другие предположения: я не вижу в g-буфере никакой сортировки спереди назад, а предварительный проход глубин рендерит все типы геометрии, не только стены. Похоже, для этого нет никакой обработки (кистей, образующих BSP), а художники не размечали вручную объекты для предварительного прохода, поскольку в рендер попадают довольно плохие перекрывающие объекты. Предполагаю, что после усечения список объектов сортируется по шейдеру, а далее инстансы отрисовки динамически формируются в CPU.

Титры в начале игры не упоминают технологию Umbra (которая использовалась The Witcher 3), поэтому предположу, что CDPr реализовала собственную систему видимости. Её эффективность очень сложно оценить, поскольку видимость это проблема балансировки GPU и CPU, однако, похоже, в захвате присутствует довольно много отрисовок, не вносящих вклад в изображение, хотя за это я не ручаюсь. Кроме того, похоже на то, что иногда рендеринг может отображать скрытые комнаты, поэтому, движок, кажется, не использует систему ячеек и порталов. Думаю, что для таких больших миров художникам непрактично выполнять большой объём ручной работы для вычисления видимости.

Наконец, я не вижу никакого усечения, выполняемого на стороне GPU, с использованием пирамид глубин и тому подобного; нет усечения на уровне треугольников или кластеров, как и нет прогнозируемых отрисовок (predicated draws), поэтому предполагаю, что всё усечение по пирамиде видимости и перекрытию выполняется на стороне CPU.

Двинемся дальше После основного прохода g-буфера (который, похоже, всегда разделён на две части не знаю, есть ли на то причина, или это два буфера команд, выполняемых в разных потоках) есть другие проходы для движущихся объектов (которые записывают векторы движения буфер векторов движения сначала инициализируется со значениями движения камеры).

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

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

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

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

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

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

Обратите также внимание на пятна в буфере нормалей. Вероятно, это артефакт упаковки нормалей, поскольку они, похоже, не соотносятся с пятнами на готовом изображении.

Освещение, часть 1: аналитические источники освещения

Очевидно, что анализ отложенного рендеринга не может закончиться на g-буфере; мы разделили затенение на две части, поэтому теперь нужно посмотреть, как реализовано освещение.

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

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

Сначала он упаковывает нормали и roughness в RGBA8 при помощи кодирования нормалей на основе таблиц поиска по принципу best-fit (эта техника создана компанией Crytek), затем создаёт mip-пирамиду min-max значений глубин.

Затем пирамида используется для создания чего-то, напоминающего объёмную (volumetric) текстуру для кластерного освещения.

То есть, исходя из увиденного, это похоже на кластерную систему отложенного освещения.

Кажется, кластеры это фрагменты 32x32 пикселя в экранном пространстве (фрокселы, froxels) с 64 z-срезами. Однако похоже, что освещение выполняется с разрешением в 16x16 тайлов, и целиком реализовано при помощи косвенного выполнения вычислительных шейдеров.

Рискну предположить, что так получилось из-за того, что вычислительные шейдеры специализируются на материалах и свете, присутствующих в тайле, а затем выполняются в соответствующем порядке такая схема часто используется в современных системах отложенного рендеринга (см., например, презентации Call of Duty Black Ops 3 и Uncharted 4 на эту тему).

На выходе прохода аналитического освещения получаются два буфера RGBA16; похоже, это вычисления diffuse и specular. Учитывая выбранные мной опции освещения сцены, не удивлюсь, что в ней присутствуют только прожекторные/точечные/сферические источники света и линейные/капсульные источники. Большинство источников освещения в Cyberpunk неоновые, поэтому поддержка линейных источников просто обязательна.

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

Освещение, часть 2: тени

Но увиденное нами выше не означает, что в Cyberpunk 2077 используются простые тени, всё совсем наоборот определённо использовалось множество трюков, и большинство из них не так просто подвергнуть реверс-инжинирингу!

Во-первых, перед предварительным проходом глубин происходит серия отрисовок в нечто, напоминающее карту теней (shadowmap). Подозреваю, что это CSM (каскадные карты теней), но в изученном мной захвате они нигде не используются, в них только выполняется рендеринг. Это указывает на то, что система обновляет карты теней на протяжении нескольких кадров (вероятно, с учётом только статичных объектов?).

Эти эффекты, растянутые на несколько кадров, сложно передать в захвате, поэтому нельзя понять, существуют ли другие системы кэширования (например, см. тени Black Ops 3, сжатые в деревья квадрантов).

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

Тени от солнца вычисляются заранее и записываются в буфер экранного пространства перед проходом вычисления освещения; думаю, это нужно для упрощения вычислительных шейдеров и более оптимальной нагрузки на GPU. Этот буфер генерируется в проходе, задействующем довольно много текстур, две из которых выглядят похожими на CSM. Одна из них это точно CSM, в моём случае с пятью элементами в массиве текстур, где срезы с 0 по 3 являются разными каскадами, а последний срез выглядит таким же, как и срез 0, но немного с другой точки зрения.

Если кто-то возьмётся за эту работу, то ему хорошенько придётся потрудиться над реверс-инжинирингом!

Все остальные тени в сцене представлены в некой форме VSM (variance shadow maps), многократно вычисляемых инкрементно в течение времени. Я видел, что используются карты размером 512x512 и 256x256, а в моих захватах на кадр рендерились пять карт теней, но предполагаю, что это зависит от настроек. Большинство из них, похоже, используются только как render target, поэтому, опять же, может оказаться так, что для завершения их рендеринга требуется несколько кадров. Одна из них размывается (VSM) в срез массива текстур я видел некоторые такие массивы с 10 срезами и с 20 срезами.

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

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

Освещение, часть 3: всё остальное...

С самого первого запуска игры у меня сложилось чёткое ощущение, что бОльшая часть освещения на самом деле реализована не в виде аналического освещения. После изучения захватов оказалось, что мои подозрения были небезосновательными. В то же время, в игре нет карт освещения (lightmap) и я сомневаюсь, что в ней вообще есть предварительное запекание чего-либо. Наверно, это один из самых восхитительных аспектов рендеринга.

Во-первых, есть очень хороший проход SSAO половинного разрешения. Он вычисляется сразу после описанного выше общего прохода суммирования и использует упакованные в RGBA8 нормали и roughness, а не из g-буфера.

Похоже, что он вычисляет наклонные нормали и конусы апертур. Конкретную технику вычисления определить невозможно, но это определённо что-то типа HBAO-GTAO. Сначала глубина, нормали/roughness и векторы движения подвергаются даунсэмплингу до половинного разрешения. Затем проход вычисляет Ambient Occlusion текущего кадра, а последующие выполняют двунаправленную фильтрацию временное репроецирование. Паттерн дизеринга тоже довольно равномерный, предположу, что это градиентный шум Жорже.

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

Во-вторых, нужно рассмотреть косвенное освещение. После прохода кластеризации освещения есть серия отрисовок, обновляющих массив текстур, похожих на развёрнутые сферически (или двойным параболоидом?) зонды. Всё это снова распределяется на несколько кадров, не все срезы этого массива обновляются в каждом кадре. В захватах легко заметить, что некоторые части массива зондов обновляются данными новых зондов, генерируя на лету mip-карты, предположительно, с предварительной фильтрацией GGX.

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

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

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

Здесь всё снова становится очень интересным. Сначала используется потрясающий проход отражений в экранном пространстве (Screen-Space Reflection), на котором опять используется буфер упакованных нормалей/roughness, а значит, поддерживаются размытые отражения; всё это выполняется в полном разрешении (по крайней мере, при моих настройках графики).

В нём применяются данные цвета предыдущего кадра до композитинга UI (для репроецирования используются векторы движения). И получается довольно много шума, даже если для дизеринга применяется текстура синего шума!

Далее идёт косвенное diffuse/ambient GI (Global Illumination). Используется g-буфер и серия объёмных текстур 64x64x64, которые сложно расшифровать. Исходя из входных и выходных данных, можно предположить, что объём центрирован относительно камеры и содержит индексы какого-то вычисленного свечения, возможно, сферических гармоник или чего-то подобного.

Освещение очень мягкое/низкочастотное и косвенные тени в этом проходе не особо заметны. Возможно, это даже динамическое GI!

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

Наконец, выполняется общий композитинг всего: зондов specular, SSR, SSAO, diffuse GI, аналитического освещения. Этот проход снова создаёт два буфера, один из которых походит на окончательное освещение, а второй содержит только то, что похоже на части specular.

И здесь мы видим то, о чём я говорил в начале. Основная часть освещения берётся не из аналитических источников освещения! Здесь мы не видим привычных трюков со множеством заполняющих источников, добавленных художниками (хотя дизайн освещения определённо выполнен очень тщательно) бОльшую часть сцены создаёт косвенное освещение. Это косвенное освещение не такое точное, как в движках, более активно использующих запекания GI и сложное кодирование, но оно очень однородное и позволяет сохранить высокочастотные эффекты при помощи двух очень высококачественных проходов экранного пространства, проходов AO и отражений.

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

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

Всё остальное

В движке есть множество других эффектов, которые мы не будем рассматривать ради краткости статьи и чтобы я не сошёл с ума. Очень интересны волосы, похоже, что рендерится несколько срезов глубин и они частично вставляются в g-буфер с предварительно вычисленным освещением и странным эффектом нормалей (фальшивая анизотропия?). Ещё один важный эффект, который я не буду рассматривать это затенение просвечивания/кожи.

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

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

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

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

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

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

Разумеется, там есть эффект глубины поля зрения, тональная коррекция и автоматическая выдержка Также присутствуют все эффекты деградации изображения, которые можно ожидать от игр и которые вы скорее всего захотите отключить: зерно плёнки, lens flares, motion blur, хроматическая аберрация Даже композитинг UI выполняется нетривиально, всё реализовано на вычислительных шейдерах, но у меня нет времени на анализ Теперь, сняв этот груз с души, я могу, наконец, попробовать насладиться игрой! Пока!

Подробнее..

Категории: Работа с 3d-графикой , Игровые движки , 3d-графика , Конвейер рендеринга , Рендеринг , Cyberpunk 2077 , First person shooter

3D ML. Часть 6 Обзор алгоритмов семантической сегментации облака точек

29.12.2020 18:11:47 |

Автор: admin

Мы уже успели поговорить про сверточные операторы на графах, а теперь посмотрим на реальные архитектуры.

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

Серия 3D ML на Хабре:

Формы представления 3D данных
Функции потерь в 3D ML
Датасеты и фреймворки в 3D ML
Дифференциальный рендеринг
Сверточные операторы на графах
Обзор алгоритмов семантической сегментации облака точек

Репозиторий на GitHub для данной серии заметок.

Заметка от партнера IT-центра МАИ и организатора магистерской программы VR/AR & AI компании PHYGITALISM.

Введение

Если рассматривать обработку трехмерных данных классическими методами машинного обучения, то можно обнаружить, что в этом направлении проделана значительная работа, и для всех, кто хочет ознакомиться с примерами таких алгоритмов, мы рекомендуем обзорную статью [5]. В частности, в статье рассматриваются различные этапы препроцессинга и способы извлечения информативных признаков из ковариационной матрицы разброса ближайших соседей для каждой точки.

Рис. 1. Этапы извлечение признаков и классификации для облака точек [5].

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

Исследователями в области 3D machine learning было предложено достаточно много идей (см. обзоры [3,4]), основанных на разных базовых принципах и формах представлений объектов, для решения задачи классификации объектов в форме облака точек. Так, например, это были методы, использующие последовательность 2D изображений (снимки сцены с разных ракурсов / multi view methods), к которым применялись сверточные нейронные сети (CNN), после чего результат разметки обратно проецировался в трехмерное пространство (поэтому эти методы также называют проекционными методами анализа облков точек).

Другим же подходом, является использование вокселей (voxel based methods) и применение операторов свёрток к ним. Однако, самым лучшим подходом видимо является использование в качестве входа для нейронной сети самого облака точек (т. н. прямой подход).

Посмотреть про актуальные задачи в области 3D ML можно на соответствующих страницах сайта paperswithcode: про задачи 3D в машинном зрении в общем, и про семантическую сегментацию облака точек в частности.

Мы собрали таблицу с разными методами и подходами, упомянутыми в обзорной работе [4], вместе со значениями метрик на разных наборах данных для оценки текущего состояния прогресса в решении задачи семантической сегментации облака точек. Ниже мы дадим краткий анализ основных подходов и их особенностей (там где нам удалось найти реализацию модели в коде, мы приложили ссылку на GitHub страницу проекта).

Кстати, на хабре на подобную тему удалось разыскать только такую заметку.

Примечание

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

Рис. 1.1 Краткая хронология развития алгоритмов семантической сегментации облака точек из обзора [4].

Обзор моделей глубокого обучения

Архитектуры глубокого обучения, предназначенные для обработки облаков точек, можно разделить, аналогично тому как это сделано в обзоре [4], на две большие группы: прямые (direct) и непрямые (indirect). Прямые методы в качестве входных данных для нейронной сети непосредственно используют облако точек, а для использования непрямых методов, необходимо предварительно перевести облако точек в иную форму представления данных.

Рис. 2. Таксономия моделей глубокого обучения, предназначенных для семантической сегментации облака точек [4].

Непрямые методы

Для начала, рассмотрим непрямые методы двух видов: multi view methods и voxel based methods.

Multi-view based methods

Первая группа таких методов, основана на получении множества снимков (двумерных срезов) исходного облака точек с разных ракурсов (multi view methods). Такой подход, позволяет использовать всю мощь методов обработки изображений, которой обладает современное компьютерное зрение в целом, и использующиеся там модели глубокого обучения в частности.

1. MVCNN [6] (2015)

Рис. 3. Схема работы сети MVCNN [6].

Входные данные: Одно или несколько изображений (RGB) 3D объекта.

Выходные данные: Класс формы объекта.

Особенности:

Одна из первых работ, посвященная multi-view подходу. Базируется на использовании 2D дескрипторов изображений для определения 3D характеристик.
Сеть предназначена для классификации единичных моделей и не приспособлена под сцены или облака точек.
В статье можно найти алгоритм настройки камер на сцене для получения двумерных срезов.
В заметки упоминается SOTA дескрипторы для изображений векторы Фишера.
Есть возможность приспособить сеть под другие задачи, такие как распознавание двумерных скетчей трехмерных объектов (3D visual search на основе скетч запроса).

2. SnapNet [7] (2017)

Рис.4 Схема работы сети SnapNet [7].

Входные данные: Облако точек.

Выходные данные: Семантическая разметка облака точек.

Особенности:

В статье предложен подход, использующий генерацию ряда пар RGB и Depth изображений проекций с различных ракурсов для исходного облака точек. Предварительно строится полигональная модель участков. Семантическая разметка происходит для плоских изображений (рис.4).
Предложена техника быстрого проецирования из 2D в 3D после семантической сегментации изображений.
В работе исследованы различные подходы к 2D семантической сегментации, в частности, был рассмотрен вопрос совмещение RGB-D данных в одной или нескольких сетях (fusion networks).

3. SnapNet-R [8] (2017)

Рис. 5. Схема работы сети SnapNet-R [8].

Входные данные: Облако точек.

Выходные данные: Семантическая разметка облака точек.

Особенности:

Сеть использует в качестве базового подхода архитектуру SnapNet, но имеет улучшенный алгоритм расстановки камер на сцене и генерации изображений (рис.5) за счет чего, превосходит свою предшественницу по показателям качества.
В работе, авторы исходили из предположения, что в реальной жизни камеры не могут быть расставлены на сцене случайным образом, а скорее всего подчинены определенной логике (например это может быть стереопара на беспилотном транспорте). В этих предположениях сконструирован фреймворк для разметки облаков точек на основе RGB-D снимков и реконструированного из этих снимков облака точек.

Volumetric methods

Вторая группа непрямых методов использует воксельное представление 3D моделей (voxel based methods). Поскольку воксельные сетки имеют регулярную структуру (аналогично пиксельным изображениям), то для них несложно обобщаются понятия сверток и многие другие приемы, применимые для анализа изображений.

4. VoxNet [9] (2015)

Рис.6 Схема работы сети VoxNet [9].

Входные данные: Вокселизированная модель исходного облака точек.

Выходные данные: Семантически сегментированное облако и воксельная маска распознанного объекта.

Особенности:

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

5. SEGCloud [10] (2017)

Рис. 7. Схема работы сети SEGCloud [10].

Github page (код отсутсвует)
Paper

Входные данные: Вокселизированная модель исходного облака точек.

Выходные данные: Семантически сегментированное облако и воксельная маска распознанного объекта.

Особенности:

Комбинированный подход методов классического машинного обучения и глубоких архитектур.
Для оптимизации использования памяти и оптимизации по скорости воксельную разреженную сеть сегментируют трехмерными матричными свертками (3D-FCNN), после чего, результат подается на вход трилинейному интерполятору (схема работы сети на рис. 7) для того, чтобы заполнить свободное пространство на основе полученной маски.
Дополнительно используется conditional random field (CRF), для комбинирования информативных признаков из исходного облака точек и интерполированной воксельной сетки.

6. PointGrid [11] (2018)

Рис. 8. Схема работы сети PointGrid [11].

Входные данные: Вокселизированная модель исходного облака точек.

Выходные данные: Семантически сегментированное облако и воксельная маска распознанного объекта.

Особенности:

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

Прямые методы

Если говорить о прямых методах, то авторы обзора [4] разделили их на несколько групп в зависимости от особенности использованной глубокой архитектуры или в зависимости от того, какую из основных проблем работы с неструктурированными данными решает архитектура.

Methods of point ordering

Первая группа методов направлена на то, чтобы справиться с неупорядоченностью трехмерных данных (methods of point ordering).

7. PointCNN [12] (2018)

Рис. 9. Иерархические свертки (а) и архитектура (b) для сети PointCNN [12].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Основным нововведением является использование $\mathcal{X}$ -transformed operator оператора, преобразующего исходное облако точек в информативные признаки (взвешенное облако точек) и представляющего из себя многослойный персептрон (рис. 9).
Признаками, на основе которых производится разметка, являются выходы $\mathcal{X}$ -персептронов, так как они инвариантны к перестановкам точек.

8. RSNet [13] (2018)

Рис. 10 Схема работы сети RSNet [13].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Предложен специальный слой, который позволяет упорядочивать точки (Slice pooling layer).
Объект делится на слои по трем координатным направлениям (все точки проецируются на координатные оси из пространства меньшей размерности). Из каждого слоя извлекаются признаки путем применения рекурентной архитектуры (RNN), после чего применяется оператор обратного проецирования (Slice Unpooling) (рис. 10).
Добавление цвета помогает улучшить результаты.

9. SO-Net [14] (2018)

Рис.11 Архитектура сети SO-Net [14].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Главная особенность: предварительно из облака точек извлекаются признаки с помощью метода Карт Кохонена.
Сеть предназначена для решения широко спектра задач: классификация, кластеризация, дополнение формы и многие другие. Разнообразие задач является следствием использования архитектуры автокодировщика (AE) (рис. 11).
Из минусов можно отметить сложность модели, плохое качество работы с мелкими деталями и невозможность обрабатывать сцены состоящие из нескольких объектов.

Methods based on multi-scale

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

10. PointNet++ [15] (2017)

Рис. 12 Архитектура сети PointNet++ [15].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Используется повторное применение PointNet [27] к уменьшающемуся подмножеству точек (рис. 12).
Используется farthest point sampling (FPS) algorithm для изначального разбиения.
Рассматриваются случаи, когда специальная структура метрического пространства помогает намного улучшить результат, по сравнению с Евклидовым пространством.

11. 3DMAX-Net [16] (2018)

Рис. 13 Схема работы сети 3DMAX-Net [16].

Github page (код отсутствует)
Paper

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Архитектура состоит из двух подархитектур: multi-scale feature learning block (MS-FLB) и Local and Global feature Aggregation Block (LGAB) (рис. 13).
Первая подархитеткура извлекает информативные признаки инвариантные к трансформации, а вторая агрегирует локальные и глобальные признаки.

12. 3P-RNN [17] (2018)

Рис. 14 Схема работы сети 3P-RNN [17].

Github page (код отсутствует)
Paper

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Применяются двунаправленные рекуррентные нейронные сети в пространстве признаков (рис. 14).
Предложен поточечный пирамидальный pooling (3P) для выделение скрытых признаков.
Нужно знать плоскость (условно пол) т. к.происходит деление облака точек на блоки определенного размера вдоль оси x и y.
В отличие от предыдущих методов, эта архитектура показывает приемлемый результат как на облаках точек внутренних помещений, так и на облаках точек открытого пространства.

Methods of feature fusion

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

13. PointSIFT [18] (2018)

Рис. 15 Архитектура сети PointSIFT [18].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Модификация PointNet [27] с предварительным выделением трехмерных SIFT признаков.
Тестировалась на сценах с большим количеством объектов (рис. 15).

14. A-CNN [19] (2019)

Рис. 16 Архитектура сети A-CNN [19].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

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

15. SpiderCNN [20] (2018)

Рис. 17 Архитектура сети SpiderCNN [20].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Предложен новый сверточный оператор SpiderConv (архитектура сети на рис. 17).
Новый оператор конструируется как произведение двух операторов: кусочно-постоянного и полиномиального, полученных из разложения в ряд Тейлора сверточного фильтра общего вида.
Порядок разложения следует из некоторых результатов трилинейной интерполяции на регулярной сетке в 3D.

Methods of fusing GCNN

Если есть возможность восстановить информацию о поверхности объекта (например в случаи, когда мы работаем с полигональной моделью), то можно попытаться применить специфические свойства пространственных графов для решения задачи классификации и сегментации. Следующая группа методов основана на использовании операций сверток на графах, и все модели, так или иначе, базируются на архитектуре Graph Convolutional Neural Networks (GCNN) [28].

16. DGCNN [2] (2018)

Рис. 18 Схема сети DGCNN [2].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

В отличие от базового GCNN, в данной архитектуре, граф динамически перестраивается в процессе применения после прохождения информации через каждый последующий слой сети (рис. 18).
В качестве операторов в скрытых слоях используются графовые свертки, которые позволяют находить для каждой точки ближайших соседей не только в исходном Евклидовом пространстве, но и в пространстве скрытых признаков.
Архитектура почти аналогична PointNet [27], но вместо полносвязных перцептронов, в ней используются графовые свертки.

17. LDGCNN [21] (2019)

Рис. 19 Архитектура сети LDGCNN [21].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Модификация архитектуры DGCNN [2]: отказались от сети для преобразования координат и адаптировали идеи из работы DenseNet [29].
Обучение делится на два этапа: обучение модели, которая извлекает признаки, и обучение классификатора при фиксированной модели для извлечения признаков (рис. 19).
Модель лучше сходится в процессе обучения и имеет меньшее число параметров по сравнению с DGCNN.

18. RGCNN [22] (2018)

Рис. 20 Архитектура сети RGCNN [22].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Сеть строится из блоков, в каждом из которых используются три оператора: построение графа, свертка на графе, отбор признаков (рис. 20).
Для лучшего распознавания структуры динамически изменяющегося от слоя к слою графа, авторы используют матрицу Лапласа заданного графа (graph Laplacian matrix), которая описывает взаимосвязь признаков полученных в разных скрытых слоях.
Модель устойчива к выбросам в данных.

19. GAPNet [23] (2018)

Рис. 21 Архитектура сети GAPNet [23].

Входные данные: Облако точек.

Выходные данные: Семантически сегментированное облако.

Особенности:

Основная особенностьиспользование механизма внимания, состоящего из двух частей: самовнимание (self attention) для текущей точки и механизма внимания для поиска региона интереса в данных (рис. 21).
Архитектура похожа на PointNet [27].

Анализ качества работы глубоких архитектур

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

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

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

Рис. 22 Время прямого распространения сигнала через нейронную сеть в миллисекундах (ms) [4].

Рис. 23 Количество параметров нейронной сети в миллионах (М) [4].

Ниже приведены сравнения работы описанных алгоритмов с помощью метрик качества классификации и семантической сегментации для различных наборов данных (большее количество информации и конкретные данные для сравнения вы можете найти в обзорной статье [4] или в этом github репозитории).

В качестве метрик используются следующие три:

Overall accuracy (OA)доля правильных ответов на всех классах / для всех точек.
Mean accuracy (MA)среднее значение Overall Accuracy по классам / для всех точек.
Mean intersection over union (mIoU)среднее значение метрики IoU [4] на всех классах / для всех точек.

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

The Stanford Large-scale 3D Indoor Spaces Dataset (S3DIS) [24]

Рис. 24 Пример помещений, отсканированных в формате цветного облака точек и семантической разметки из датасета S3DIS [24].

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

ShapeNet Part [25]

Рис. 25 Пример объектов и их разбиения на составные части из датасета ShapeNet part [25].

Состоит из 16 категорий, 12137 объектов в обучающей выборке, 2874 объектов для валидации. Датасет состоит из одиночных 3D моделей нарисованных художниками и разбитыми на составные части.

ModelNet40 [1]

Рис. 26 Пример объектов класса стул их разбиений на составные части в формате облака точек из датасета ModelNet40 [1].

Состоит из 40 классов, 12311 3D СAD моделей в обучающей и валидационной выборке. Датасет состоит из одиночных 3D параметрических моделей (CAD форматы), для 10-и классов, есть информация об ориентации моделей. Нет разбиения на части, этот датасет используется только для задачи классификации отдельных объектов.

ScanNet [26]

Рис. 27 Пример семантического разбиения отсканированного помещения из датасета ScanNet [26].

Состоит из 21 класса, 1201 сцены в обучающей выборке и 312 сцен в валидационной выборке. Датасет состоит из сцен помещений в виде набора RGB-D ракурсов + семантические размеченные облака точек без цвета.

Сравнения метрик

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

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

Overall Accuracy на наборе данных ModelNet40.

Mean Accuracy на наборе данных ModelNet40.

Overall Accuracy на наборе данных S3DIS.

Mean intersection over union на наборе данных S3DIS.

Overall Accuracy на наборе данных ScanNet.

Mean intersection over union на наборе данных ShapeNet Part.

Выводы

Исходя из проведенного анализа, можно сделать вывод:

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

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

Источники:

Wu, Z., Song, S., Khosla, A., Yu, F., Zhang, L., Tang, X. and Xiao, J., 2015. 3d shapenets: A deep representation for volumetric shapes. In Proceedings of the IEEE conference on computer vision and pattern recognition (pp. 19121920). [paper]
Wang, Y., Sun, Y., Liu, Z., Sarma, S.E., Bronstein, M.M. and Solomon, J.M., 2019. Dynamic graph cnn for learning on point clouds. ACM Transactions on Graphics (TOG), 38(5), pp.112. [paper]
Xie Y., Tian J., Zhu X. X. A review of point cloud semantic segmentation //arXiv preprint arXiv:1908.08854.2019. [paper]
Zhang J. et al. A Review of Deep Learning-based Semantic Segmentation for Point Cloud (November 2019) //IEEE Access.2019. [paper]
Weinmann M. et al. Semantic point cloud interpretation based on optimal neighborhoods, relevant features and efficient classifiers //ISPRS Journal of Photogrammetry and Remote Sensing.2015.Т. 105.С. 286304. [paper]
H. Su, S. Maji, E. Kalogerakis, and E. Learned-Miller, Multi-view convolutional neural networks for 3D shape recognition, in Proc. IEEE Int. Conf. Comput. Vis. (ICCV), Dec. 2015, pp. 945953 [paper]
A. Boulch, B. Le Saux, and N. Audebert, Unstructured point cloud semantic labeling using deep segmentation networks, in Proc. Eurograph. Workshop 3D Object Retr., vol. 2, 2017, pp. 1724. [paper]
J. Guerry, A. Boulch, B. Le Saux, J. Moras, A. Plyer, and D. Filliat, SnapNet-R: Consistent 3D multi-view semantic labeling for robotics, in Proc. IEEE Int. Conf. Comput. Vis. (ICCV), Oct. 2017, pp. 669678. [paper]
D. Maturana and S. Scherer, VoxNet: A 3D convolutional neural network for real-time object recognition, in Proc. IEEE/RSJ Int. Conf. Intell. Robots Syst. (IROS), Dec. 2015, pp. 922928. [paper]
L. Tchapmi, C. Choy, I. Armeni, J. Gwak, and S. Savarese, SEGCloud: Semantic segmentation of 3D point clouds, in Proc. Int. Conf. 3D Vis. (3DV), Oct. 2017, pp. 537547, doi: 10.1109/3DV.2017.00067. [paper]
T. Le and Y. Duan, PointGrid: A deep network for 3D shape understanding, in Proc. IEEE Conf. Comput. Vis. Pattern Recognit. (CVPR), Jun. 2018, pp. 92049214 [paper]
Y. Li, R. Bu, M. Sun, W. Wu, X. Di and B. Chen, PointCNN: Convolution On X-transformed points, in Proc. Adv. Neural Inf. Process. Syst. (NIPS). Dec. 2018, pp. 828838. [paper]
Q. Huang, W. Wang, and U. Neumann, Recurrent slice networks for 3D segmentation of point clouds, in Proc. IEEE Conf. Comput. Vis. Pattern Recognit. (CVPR), Jun. 2018, pp. 26262635. [paper]
J. Li, B. M. Chen, and G. H. Lee, SO-net: Self-organizing network for point cloud analysis, in Proc. IEEE Conf. Comput. Vis. Pattern Recognit. (CVPR), Jun. 2018, pp. 93979406 [paper]
C. R. Qi, L. Yi, H. Su, and L. J. Guibas, PointNet++: Deep hierarchical feature learning on point sets in a metric space, in Proc. Adv. Neural Inf. Process. Syst. 30 (NIPS), 2017, pp. 51055114. [paper]
Y. Ma, Y. Guo, Y. Lei, M. Lu, and J. Zhang, 3DMAX-net: A multi-scale spatial contextual network for 3D point cloud semantic segmentation, in Proc. 24th Int. Conf. Pattern Recognit. (ICPR), Aug. 2018, pp. 15601566, doi: 10.1109/ICPR.2018.8546281. [paper]
X. Ye, J. Li, H. Huang, L. Du, and X. Zhang, 3D recurrent neural networks with context fusion for point cloud semantic segmentation, in Proc. Eur. Conf. Comput. Vis. (ECCV), 2018, pp. 403417 [paper]
M. Jiang, Y. Wu, T. Zhao, Z. Zhao, and C. Lu, PointSIFT: A SIFTlike network module for 3D point cloud semantic segmentation, 2018, arXiv:1807.00652. [paper]
A. Komarichev, Z. Zhong, and J. Hua, A-CNN: Annularly convolutional neural networks on point clouds, in Proc. IEEE Conf. Comput. Vis. Pattern Recognit. (CVPR), Jun. 2019, pp. 74217430 [paper]
Y. Xu, T. Fan, M. Xu, L. Zeng, and Y. Qiao, SpiderCNN: Deep learning on point sets with parameterized convolutional filters, in Proc. Eur. Conf. Comput. Vis. (ECCV), 2018, pp. 87102. [paper]
K Zhang, M. Hao, J. Wang, C. W. de Silva, and C. Fu, Linked dynamic graph CNN: Learning on point cloud via linking hierarchical features, 2019, arXiv:1904.10014. [paper]
G. Te, W. Hu, A. Zheng, and Z. Guo, RGCNN: Regularized graph CNN for point cloud segmentation, in Proc. 26th ACM Int. Conf. Multimedia, Oct. 2018, pp. 746754. [paper]
C. Chen, L. Z. Fragonara, and A. Tsourdos, GAPNet: Graph attention based point neural network for exploiting local feature of point cloud, 2019, arXiv:1905.08705. [paper]
I. Armeni, O. Sener, A. R. Zamir, H. Jiang, I. Brilakis, M. Fischer, and S. Savarese, 3D semantic parsing of large-scale indoor spaces, in Proc. IEEE Conf. Comput. Vis. Pattern Recognit. (CVPR), Jun. 2016, pp. 15341543. [paper]
L. Yi et al., Large-scale 3D shape reconstruction and segmentation from ShapeNet core55, 2017, arXiv:1710.06104. [paper]
A. Dai, A. X. Chang, M. Savva, M. Halber, T. Funkhouser, and M. Niener, ScanNet: Richly-annotated 3D reconstructions of indoor scenes, in Proc. IEEE Conf. Comput. Vis. Pattern Recognit. (CVPR), Jul. 2017, pp. 58285839. [paper]
Qi, C.R., Su, H., Mo, K. and Guibas, L.J., 2017. Pointnet: Deep learning on point sets for 3d classification and segmentation. In Proceedings of the IEEE conference on computer vision and pattern recognition (pp. 652-660). [paper]
Zhang, Y. and Rabbat, M., 2018, April. A graph-cnn for 3d point cloud classification. In 2018 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP) (pp. 6279-6283). IEEE. [paper]
Huang, G., Liu, Z., Van Der Maaten, L. and Weinberger, K.Q., 2017. Densely connected convolutional networks. In Proceedings of the IEEE conference on computer vision and pattern recognition (pp. 4700-4708). [paper]

Подробнее..

Категории: Работа с 3d-графикой , Искусственный интеллект , Machine learning , Обзор , Deep learning , 3d-графика , Блог компании it-центр маи , Point clouds

Третий день 3DEXPIRIENCE World 2021 как это было

01.03.2021 14:22:08 |

Автор: admin

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

Пленарное заседание под названием От связей к отношениям открыл Сучит Джайн, вице-президент отдела стратегического планирования и коммуникаций бизнеса SOLIDWORKS. Он подтвердил то, что многим уже известно: SOLIDWORKS по-прежнему присутствует везде.

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

Своими историями поделились два наших клиента: Мэтт Карни и Тедж Матель. Карни, используя платформу 3DEXPERIENCE Works, подключил сотни инженеров к разработке проектов медицинских масок, вносить вклад в которые может каждый участник. В рассказе Мателя было подчеркнуто, как важно разработчику иметь доступ к информации о тестах, проводимых для диагностики COVID-19.

Тему продолжила Мари Планшар, директор по образовательным программам и раннему взаимодействию. Она побеседовала с двумя известными инженерами, работающими с SOLIDWORKS. Их инженерная карьера складывается по-разному, но оба едины в стремлении передать свой накопленный за многие годы опыт новому поколению специалистов. Эрик Битти, лидер сети групп пользователей SWUGN, рассказал о том, как делится своими знаниями на ежегодных встречах SLUGME. Пол Вентимилья напомнил, что в свободное от основной работы время он участвует в телешоу BattleBots и является наставником одной из соперничающих команд робототехников.

Основным событием дня стала экспертная дискуссия, в которой приняли участие Брент Бушнелл, основатель и председатель Two Bit Circus, Нолан Бушнелл, основатель и генеральный директор Atari и Chuck E. Cheese, а также Грант Дельгатти, заведующий кафедрой инноваций в академии USC Iovine and Young. Нолан Бушнелл познакомил аудиторию с историей создания Atari, а Брент рассказал, как он создавал Two Bit Circus. Все эксперты были единодушны в одном: не нужно бояться неудач, они тоже неотъемлемая часть инновационного процесса.

Если вы пропустили какие-либо пленарные заседания или встречи, то можете наверстать упущенное, разыскав их записи на вкладке Agenda платформы виртуального мероприятия. Не забудьте посмотреть встречу с Джимом Капобьянко сценаристом хита Pixar Рататуй и лауреатом премии Оскар в номинации Лучший сценарий. На конференции этого года Капобьянко рассказал о новом мультфильме Изобретатель. В своих анимационных работах он часто обращается к проектам Леонардо да Винчи, моделируя движение механизмов компьютерными средствами.

Технических секций на конференции было более 130, и мы уверены, что вы все сможете найти среди них полезные для себя и поднять свою квалификацию на новый уровень. Хотите хорошую новость? Записи технических секций будут доступны примерно месяц на платформе виртуального мероприятия 3DEXPERIENCE, так что время для ознакомления с ними у вас еще есть!

Что-то пропустили? Не беспокойтесь. Посмотрите видео ниже, чтобы узнать о происходившем в этот день, и не забывайте о записях, выложенных на виртуальном портале. Благодарим вас за то, что присоединились к нам на виртуальной конференции 3DEXPERIENCE World 2021. Будем надеяться, что встретимся лично через год на 3DEXPERIENCE World 2022 в Атланте!

Хотите узнать больше? Скачайте бесплатно электронную книгу о ключевых обновлениях и технических преимуществах SOLIDWORKS 2021

Подробнее..

Категории: Работа с 3d-графикой , Анализ и проектирование систем , It-компании , Cad/cam , Cad , 3d-графика , 3d , Блог компании dassaultsystèmes , 3dexpirience , 3d моделирование , 3d проектирование , Cad/cam/cae/plm , Solidworks , Solidworks 2021 , Cad/cae системы

Элемент внезапности ( или нет?) при разработке продукции

15.03.2021 20:13:27 |

Автор: admin

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

Непростые отраслевые проблемы

SOLIDWORKS Simulation ограждает наших клиентов, где бы они ни находились, от неожиданностей при проектировании и производстве. Компьютерное моделирование методом конечных элементов (МКЭ) помогает спрогнозировать поведение ваших деталей и сборок под воздействием реальных физических сил.

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

Моделирование поведения изделий в реальной эксплуатации поможет вам ответить на самые злободневные вопросы:

Можно ли применить в моей конструкции более легкие материалы без ущерба для прочности?
Какие физические факторы будут влиять на ее работу (вибрация, усталость, температура)?
Какие части изделия можно безболезненно сделать прочнее и легче, оптимизировав топологию конструкции?

Из первых рук

Представляем вам четыре беседы с клиентами, использующими SOLIDWORKS Simulation: Electric Power Systems, GE Healthcare, Omax Corporation и Tenaris Group. Узнайте, как эти компании повышают качество проектирования, быстрее доводят проекты до готовности, сокращают потребность в физических опытных образцах и реализуют производственные инновации.

Хотите, чтобы ваши инженеры узнали, как решать проблемы на ранних стадиях проектирования с помощью SOLIDWORKS Simulation и анализа МКЭ? Авторизованный партнер в вашем регионе обязательно расскажет об этом.

Подробно ознакомиться с функционалом и новшествами SOLIDWORKS 2021 предлагаем вам, посмотрев видео на официальном канале Dassault Systemes в России:

1.SOLIDWORKS 2021 | Повышение производительности и новый подход к проектированию

2.Что нового в SOLIDWORKS SIMULATION 2021

3.SOLIDWORKS CAM 2021 | Нововведения в моделировании механической обработки

4.SOLIDWORKS PLASTICS 2021 | Новый взгляд на процессы литья полимеров под давлением

5.SOLIDWORKS PDM 2021 | Обмен данными с внешними системами

Подробнее..

Категории: Работа с 3d-графикой , Проектирование и рефакторинг , Cad/cam , 3d-графика , 3d , Блог компании dassaultsystèmes , 3d моделирование , 3d проектирование , Моделирование систем , Solidworks , Simulation , Solidworks 2021 , 3d моделинг , Solidworks simulia

Рейтинг лучших бесплатных программ для 3D-моделирования (для начинающих) на весну 2021 года

19.04.2021 18:14:05 |

Автор: admin

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

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

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

Список лучших бесплатных программ для 3D-моделирования в 2021 году:

1. TinkerCAD лучшая программа для начинающих

2. 3D Slash простая программа для начинающих

3. FreeCAD бесплатная программа с открытым исходным кодом

4. SketchUp

5. Blender расширенная бесплатная программа

6. MeshMixer

7. Fusion 360

8. Vectary

9. SelfCAD

10. BlocksCAD

11. OpenSCAD

12. Wings 3D

Критерии, которые использовались для оценки:

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

1. TinkerCAD лучшая бесплатная программа для начинающих

Страна разработчика - США. Доступна к работе в браузере.

Это одна из многих программ 3D CAD-гиганта Autodesk, TinkerCAD. Инструмент обманчиво выглядит примитивным, прост в использовании, но снова и снова попадает в топ лучших бесплатных программ.

TinkerCAD позволяет создавать детализированные 3D-модели, используя базовые формы, соединяя их вместе. Процесс обучения намного проще, чем в других программах. Она идеально подходит для новичков и детей, для обучения детей 3D-печати. Ее чаще других используют в школах и классах по всему миру. Можете начать работу за считанные минуты в браузере без загрузки. Более того, можно скачать приложение TinkerCAD и поиграть с моделями на смартфоне или планшете!

Autodesk производит множество программ для различных отраслей. TinkerCAD идеально подходит для начинающих в 3D-дизайне, позволяет сделать что-то классное. Вы можете экспортировать модель в STL и любом другом формате и отправить на печать на 3D-принтере. Как только вы приобретете необходимый опыт, вам может понадобиться более сложная программа, например AutoCAD. Но при этом TinkerCAD остается отличной программой для начала вашей карьеры 3D-дизайнера.

2. 3D Slash простая бесплатная программа для начинающих

Основная версия бесплатная, премиум версия требует оплату $2 в месяц.

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

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

3. FreeCAD бесплатная программа с открытым исходным кодом

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

Очень полезная функция - возможность начать со статического 2D-эскиза, из которого затем можно построить конечную 3D-модель. FreeCAD хорошо работает в Windows и Mac, можно легко экспортировать модель в виде файлов STL, OBJ или даже DXF, например, для ЧПУ.

Хотя FreeCAD была разработана в основном для станков, ее можно использовать и для 3D-печати. Более того, FreeCAD - программа с открытым исходным кодом, поэтому можно работать с Python.

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

4. SketchUp

Основная версия бесплатная, версия Pro стоит $299 в год. Страна разработчика США.

Программа - ветеран индустрии программного обеспечения для 3D-моделирования, была создана в 2000 году компанией Lastsoftware. В 2006 году ее выкупил Google, чтобы внедрить этот универсальный и мощный инструмент в свои сервисы. С тех пор она была продана Trimble Inc., которая и предложила бесплатную версию. SketchUp - отличный выбор для начинающих дизайнеров. Ее, как и TinkerCAD, освоить легче, чем большинство других 3D-программ. Содержит практически все инструменты, которые могут понадобиться.

Несмотря на то, что SketchUp пользуются в основном архитекторы, она приобретает все большую популярность в 3D-печати. Инструменты удивительно хорошо подходят создателям 3D-CAD-файлов. Вы можете загрузить расширение SketchUp STL, чтобы создавать файлы в STL.

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

5. Blender расширенная бесплатная программа

Страна разработчика Нидерланды.

Возможно, это самое популярное программное обеспечение для 3D-дизайна. Blender имеет огромное активное сообщество, которое делится своими STL-файлами и 3D-моделями, а также информацией в интернете. Быстрый поиск Google и YouTube выдаст тысячи ссылок, где пользователи демонстрируют свои 3D-проекты и обмениваются опытом работы в Blender 3D. Такая популярность обусловлена прежде всего тем, что программа на 100% бесплатная и с открытым исходным кодом. В ней можно создать практически все, что угодно. Выбор инструментов огромен.

Процесс обучения более сложный, чем у предыдущих программ. Однако благодаря своему набору инструментов Blender универсальная программа для 3D-моделирования. Она используется в различных областях, начиная от создания VFX для фильмов, видеоигр, дизайна 3D-моделей, заканчивая 3D-печатью. Кроме того, Blender поставляется с интегрированным игровым движком, а также детализированными инструментами для моделирования и возможностью редактирования видео. Это невероятное бесплатное программное обеспечение идеально подходит для разработчиков игр и опытных 3D-моделистов.

6. MeshMixer

Страна разработчика США.

Meshmixer уникальная программа, не вписывающаяся ни в одну конкретную категорию. Еще одна разработка Autodesk, Meshmixer выгодно отличается от конкурентов тем, что позволяет редактировать существующие модели с помощью различных инструментов, включая анимацию, выгибание/заполнение, восстановление. Meshmixer хорошо подходит для модификации конструкций и обеспечения качества. Полезна как для начинающих, так и для экспертов. Позволяет улучшать и готовить свои модели к 3D-печати.

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

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

7. Fusion 360

Программа бесплатна для личного пользования в течение года, Pro версия стоит около $500 в год.

Страна разработчика США.

Очередная разработка Autodesk для школ и академических институтов. Это, несомненно, инструмент для экспертов, однако достаточно удобный в использовании для образованного новичка. Fusion 360 - программа для совместного использования, позволяет обмениваться файлами STL через облако для совместного редактирования и оптимизации моделей.

Обладает мощными инструментами для работы практически над любым промышленным 3D-дизайном. Имеет встроенные функции для оценки нагрузки, с которой столкнутся компоненты 3D-модели. Это позволяет дизайнерам находить потенциально слабые места перед печатью. После создания можно легко экспортировать модель в STL-файл или любой другой формат. Программа недавно стала бесплатной для студентов, стартапов и многих других. Если у вас есть некоторый опыт, или вы хотите повысить свои навыки в 3D-дизайне, это 3D-программное обеспечение идеально подойдет.

8. Vectary

Бесплатная программа с премиальными функциями за $12 в месяц.

Vectary появилась в 2014 году и называет себя самой доступной платформой 3D- и AR-дизайна. Это бесплатная веб-программа для 3D-моделирования. Vectary предлагает шаблоны с предварительно отрисованными и освещенными экранами, перед которыми вы можете разместить свои 3D-модели для съемки продукта и других художественных целей. Простой рабочий интерфейс с необходимым набором инструментов делает работу с освещением и моделированием легкой. Вы можете легко экспортировать готовый дизайн или сцену в виде AR-модели.

Бесплатный пакет включает в себя доступ к Vectary Studio для создания и проектирования моделей, а также возможность экспортировать ваши творения в форматы OBJ или STL. Для других форматов вам потребуется обновление. Бесплатно можно создать до 25 проектов, а также получить доступ к библиотеке 3D-активов, материалов и иконок Vectary. Платное обновление дает доступ к инструментам предварительного просмотра AR, а также к функциям совместного использования проектов и командам для лучшей и быстрой обратной связи между несколькими людьми.

9. SelfCAD

Бесплатная программа для сферы образования. Для остальных стоит $4,99 в месяц.

Страна разработчика США.

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

SelfCAD - простая программа для 3D-дизайна с очень понятным интерфейсом, подходит новичкам.

10. BlocksCAD

Программа предоставляется бесплатно. Есть платные учебные версии для школ.

Страна разработчика США.

BlocksCAD ориентирована на обучение и была создана для учащихся по модели STEM с 3-го по 8-й классы. Это облачное бесплатное программное обеспечение для 3D-моделирования, которое способствует изучению математики, вычислительного мышления, концепций кодирования и проектирования моделей для 3D-печати.

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

11. OpenSCAD

OpenSCAD бесплатная загружаемая программа. Выглядит устрашающе, поскольку окутывает кодами и скриптами. Это мощный инструмент. Но имейте в виду, что он для тех, кто привык к кодированию. Программа была создана еще в 2010 году Мариусом Кинтелем и Клиффордом Вольфом. Регулярно выходят новые обновления и патчи. OpenSCAD любят 3D-дизайнеры, которые предпочитают скриптовый, а не художественный метод проектирования. Стоит также отметить, что 3D-деталь в OpenSCAD можно создать использую лишь мышь, но это не единственная фишка программы.

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

12. Wings 3D

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

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

Перевод с сайта 3DSourced https://www.3dsourced.com/rankings/best-free-3d-software/

Подробнее..

Категории: Работа с 3d-графикой , 3d-принтеры , 3d-печать , 3d-моделирование , 3д-принтер , 3д-печать , 3d-принтер , 3d-графика , 3d моделирование , 3д-моделирование , 3d модель , 3d принтер

Эволюция методов mesh denoising от простых фильтров до 3D глубокого обучения

14.05.2021 20:06:19 |

Автор: admin

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

Зачем нужен mesh denoising?

С помощью технологии трехмерного сканирования можно получить 3D-модель реального объекта. Но знаете ли вы, что почти всегда такие объекты содержат шумы и неточности? В Twin3d мы сканируем людей (и не только) и с помощью фотограмметрии получаем 3D-модели, которые дальше необходимо обрабатывать в зависимости от конечной цели их использования. Естественно, от шумов надо избавляться, чтобы применять виртуальную модель человека в кино/играх/рекламе. Нужно много чего еще делать, но об этом мы поговорим потом.

Сканирование объектов и получение их 3D-моделей используется не только для создания виртуальных людей. Это популярно в reverse engineering для получения CAD-деталей без чертежей, где нужна большая точность реконструкции и шумы недопустимы. Также как людей и CAD-детали, можно сканировать реальные объекты одежду, обувь, аксессуары, что сейчас очень распространено в связи с созданием виртуальных примерочных. В таких случаях тоже хочется сделать вещь визуально идеальной, поэтому отсканированный объект необходимо обрабатывать.

Процесс устранения шума с 3D-моделей, полученных после сканирования, получил название mesh denoising. Иногда можно встретить слово smoothing, что означает просто сглаживание. 3D-моделлеры пользуются профессиональным ПО для решения данной задачи, но при этом они тратят достаточно много времени, чтобы убрать все неровности и шероховатости поверхности вручную. А как это делается без вмешательства 3D-моделлера? С помощью методов, которые мы рассмотрим далее.

С чего все начиналось

Когда-то были фильтры Просто сглаживающие фильтры, которые берут координаты вершин меша и усредняют по соседним вершинам (Laplacian smoothing, Taubin smoothing).

Laplacian smoothing

В 2003 году появляется Bilateral mesh denoising расширение билатерального фильтра (который использовался для сглаживания шума на 2D картинках) на трехмерные полигональные сетки. Суть остается та же усредняются координаты вершин, но уже немного умнее: используются при этом как координаты вершин, так и нормали вершин. Еще через 7 лет придумали применять такой билатеральный фильтр не к вершинам, а к нормалям граней (Bilateral normal filtering for mesh denoising), что значительно увеличило качество сглаживания.

Итеративный процесс вычисления новой нормали с помощью Bilateral Normal Filtering заключается в следующем:

$n_i^k=\Lambda(\sum_{f_j\in N_i}A_jW_s(||c_i-c_j||)W_r(||n_i-n_j||)n_j),$

где N_i набор соседних граней для грани f_i , n_j нормаль грани f_j , A_j площадь грани f_j , c_j центроид грани f_j (точка пересечения медиан треугольника), $W(x)=exp(-x^2/(2\sigma^2))$ гауссиана, $\Lambda$ оператор нормализации.

Билатеральный фильтр является средним взвешенным с весом, состоящим из нескольких частей. W_s(x) для грани f_i определяет значимость грани f_j в терминах удаленности друг от друга чем больше расстояние, тем меньше вес. Аналогично с W_r(x) , только на вес влияет не расстояние между гранями, а разница между векторами нормалей грани. Также учитывается значение площади грани A_j

В 2015 году улучшают подход с билатеральными фильтрами с появлением Guided Mesh Normal Filtering, где используется направляющая нормаль для сглаживания.

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

Наряду с фильтрами развивались подходы mesh denoising, основанные на оптимизации. Так, например, в работе Mesh Denoising via L0 minimization авторы максимизируют плоские поверхности меша и постепенно устраняют шум, не сглаживая при этом углы. Данный подход хорош в случаях, когда все отсканированные объекты CAD-модели с правильными геометрическими формами.

Первые попытки обучения алгоритмов для mesh denoising

Настоящим прорывом в 2016 году стала работа Mesh Denoising via Cascaded Normal Regression, в которой впервые использовались данные для обучения алгоритма. Прежде всего, авторы создали соответствующий датасет из noisy и ground truth (GT) 3D-моделей с разным шумом (доступен по ссылке проекта).

Датасет состоит из синтетических данных (Synthetic) и полученных с помощью различных сканеров (Kinect v1, Kinect v2, Kinect Fusion). В Synthetic в качестве noisy моделей используются модели с искусственно сгенерированным шумом (используется небольшое случайное смещение координат). Отсканированные данные уже содержат шум, зависящий от параметров сканеров и используемых в них технологий. Для получения GT моделей для реальных сканов использовался сканер Artec Spider c порядком точности, превышающим Microsoft Kinect.

Примеры из датасета

Основная идея работы для каждой пары граней noisy и ground truth мешей создать пару дескриптор и GT нормаль. Дескриптор одной грани это нормаль грани после применения билатеральных фильтров с разными параметрами. Далее такие дескрипторы необходимо разделить на отдельные кластеры, которые определяют принадлежность к той или иной геометрической форме. Для отдельного кластера обучается отдельная регрессия, после которой на выходе получается обновленная нормаль грани. Весь описанный процесс повторяется несколько раз, каскадами.

Cascaded Normal Regression Pipeline

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

После этого появилась работа NormalNet: Learning based Guided Normal Filtering for Mesh Denoising. Основная идея обучать сверточную нейронную сеть для определения направляющей нормали, после применять Guided Mesh Normal Filtering. Для определения направляющей нормали происходит вокселизация локальной структуры каждой грани меша (voxel объемный пиксель), чтобы привести его к упорядоченному представлению и иметь возможность использовать CNN. Общий пайплайн работы представлен на картинке ниже.

NormalNet pipeline

Следующий рисунок иллюстрирует архитектуру сетки в NormalNet. На вход каждой CNN подаются 4-мерные массивы, полученные после вокселизации, содержащие информацию о координатах вершин набора граней и усредненной нормали этого набора. Наборы граней (патчи) в терминах данной работы это некоторое количество соседних граней для одной грани. При создании нейронной сети авторы вдохновлялись архитектурой ResNet, которая позволяет учитывать информацию, полученную с предыдущих слоев сетки. Для составления карты признаков для каждого патча входные данные обрабатываются тремя блоками с конволюциями. Выходные полносвязные слои преобразовывают карту признаков к трехмерному вектору, который является направляющей нормалью для одного патча.

Архитектура CNN в NormalNet

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

Наконец, от использования билатеральных фильтров решили отказаться в работе DNF-Net: a Deep Normal Filtering Network for Mesh Denoising и предоставили полное управление процессом фильтрации шума нейронным сетям. Это первая работа, которая делает end-to-end процесс фильтрации без ручного составления признаков. С помощью отдельных логических частей нейронной сетки на основе ResNet авторы формируют карты признаков для всего меша с шумом и отдельно для шума, а после их обработки получают обновленные нормали граней.

Архитектура DNF-Net

На вход DNF-Net принимает патчи граней: нормали и индексы соседних граней. С помощью блока multi-scale feature embedding unit составляется карта признаков для каждого патча. В этом блоке анализируется локальная геометрическая структура меша на разных масштабах. На трех уровнях (см. картинку ниже) составляются три разные локальные карты признаков , которые учитывают разное количество соседних граней (по возрастанию). После их конкатенации и прогона через полносвязные слои нейронной сети получается глобальная карта признаков F для каждой грани меша.

Multi-scale Feature Embedding Unit

Впоследствии с помощью residual learning unit аналогичным образом извлекается карта признаков для шума. С помощью KNN (K-Nearest Neighbors) происходит поиск k похожих граней в представлении созданных признаков. Из продублированной k раз исходной карты признаков вычитаются карты признаков похожих граней. Аналогично используются полносвязные слои нейронной сетки формирования шумной карты признаков.

Residual learning unit

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

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

Deep learning и свертки на графах

Чтобы избавиться от ограничений в виде числа параметров и соседей, необходимо работать с целым мешем, а не отдельно составленными патчами. А для построения сложных архитектур нейронных сетей с хорошей обобщающей способностью, надо как-то привести нерегулярное представление меша к регулярному. Во всей области 3D DL существует несколько популярных подходов для этого: вокселизация меша и представление меша как графа.

Так, в работе Mesh Denoising with Facet Graph Convolutions был предложен еще один end-to-end pipeline для устранения шума с помощью представления мешей как графов, только вместо натурального представления графа полигональной сетки (вершины, связанные с вершинами) используется другое грани, связанные с гранями. Основная идея сгенерировать граф и запустить на нем сверточную нейронную сеть.

Facet Graph Convolution pipeline

В основе этого метода лежит архитектура U-Net, которой на вход подаются координаты граней и соответствующих нормалей созданного графа, а на выходе получаются скорректированные нормали граней.

Архитектура Graph Convolution Network

Свертка графа

Графовое представление и U-Net позволяют учитывать геометрические особенности меша как в локальной структуре (как в предыдущих методах), так и в глобальной.

Заключение

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

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

В Twin3d мы занимаемся разными задачами, и mesh denoising входит в их число. В будущих статьях будем рассказывать уже о своих разработках, не пропустите ;)

Подробнее..

Категории: Работа с 3d-графикой , Алгоритмы , Математика , Машинное обучение , 3d-моделирование , Deep learning , Нейронные сети , 3d-графика , Блог компании twin3d , Полигональная сетка

Советы и трюки SOLIDWORKS

02.06.2021 10:16:01 |

Автор: admin

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

В этой заметке мы ответим на некоторые наиболее актуальные вопросы. Минимум воды, максимум пользы. Итак, начинаем наш краткий ликбез.

1. Как установить существующую библиотеку материалов

Файлы с расширением .sldmat содержат сведения о механических и физических свойствах материалов. Если вы скачали библиотеку с сайта i-tools.info, следующие 5 шагов помогут вам ее установить. Для добавления библиотеки необходимо открыть любую деталь в SOLIDWORKS:

1. В дереве конструирования FeatureManager нажимаем правой кнопкой мыши на Материал.

2. Выбираем пункт Редактировать материал.

3. В левом поле открывшегося окна кликаем в любом месте правой кнопкой мыши и выбираем Открыть библиотеку.

4. Выбираем директорию, в которой находится файл .sldmat, либо копируем его в папку с пользовательскими материалами SOLIDWORKS. Уточнить папку, выбранную по умолчанию, можно в разделе Настройки пользователя Месторасположение файлов Отобразить папки для Базы данных материалов.

5. Выбираем файл с расширением .sldmat и нажимаем кнопку Открыть.

Библиотека установлена! Если она не отображается в окне, необходимо закрыть и вновь открыть окно редактирования материала.

2. Можно ли работать на любом компьютере с установленным SOLIDWORKS, используя лишь свою лицензию?

ДА! Это называется онлайн-лицензирование SOLIDWORKS Online Licensing. Вам потребуются лишь компьютер с доступом в интернет и SOLIDWORKS выше версии 2018 года.

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

Можно сказать, это лицензия SOLIDWORKS, которая находится в облаке.

3. В чем отличие SOLIDWORKS Simulation Standard и пакета Simulation Standard, входящего в SOLIDWORKS CAD Premium?

a) В SOLIDWORKS CAD Premium нельзя строить диаграмму усталости, усталостные напряжения и получать количество циклов до разрушений.

b) В SOLIDWORKS Simulation Standard доступен анализ тенденций, то есть построение зависимостей в результатах различных повторов статического исследования. Например, меняя нагрузку, можно отслеживать напряжение, перемещение и т.д.

4. Как показать основные плоскости компонентов в сборке?

Для этого нужно включить Просмотр плоскостей:

А затем выбрать значок Скрыть / Показать основные плоскости:

5. Как выбирать спрятанные грани, не применяя функцию Скрыть деталь?

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

6. Как посмотреть на деталь из сборки, не открывая деталь отдельно?

Нажимаем правой кнопкой мыши на интересующую нас деталь и выбираем функцию Окно предварительного просмотра компонента.

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

Хотите узнать больше? Подписывайтесь на наш YouTube-канал и изучайте SOLIDWORKS самостоятельно. Нужно обучение с профессионалами? Переходите по ссылке и выбирайте курс.

Автор: Максим Салимов, технический специалист ГК CSoft, solidworks@csoft.ru

Подробнее..

Категории: Работа с 3d-графикой , Анализ и проектирование систем , Графический дизайн , Cad/cam , 3d-моделирование , Cad , 3d-графика , 3d , Блог компании dassaultsystèmes , Dassault systemes , 3d моделирование , 3d graphics , Solidworks , Solidworks 2021

	Русский
	English