Как сделать воксельную игру

Воксельная графика своими руками — первые шаги

В процессе поиска алгоритмов расчета коллизий на сайте GameDev, я наткнулся на маленькую статью про движок idTech 6 и заинтересовался воксельной графикой, которую противопоставляют полигональной графике, на которой сейчас основана почти вся компьютерная графика.
Вообще, воксел расшифровывается как «объемный пиксель», однако сейчас под вокселом в основном понимается некий примитив, чаще всего куб или прямоугольный параллелепипед, который имеет определенный размер и цвет. В idTech 6 и в движке Кена Сильвермана Voxlap они хранятся в разреженном октодереве (SVO — sparse voxel octree), что позволяет экономить память и делает возможным простую реализацию «уровня детализации».

Снеговик из вокселей

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

Разрушения в тестовой игре на движке Voxlap

Первые попытки

Штурмовать сразу трехмерное пространство я не решился — слишком пугающе выглядел весь тот список формул, которые бы пришлось освоить (о них речь пойдет чуть ниже), и решил просто переписать код, чтобы платформер использовал «боксы» — квадраты, и соответственно хранились не в разреженном октодереве, а в разреженном квадродереве.
Первый код был ужасен — все функции работы с деревом, такие как удаление, обход дерева, создание узлов, были итеративными отдельными от класса QuadTree функциями. В прочем, даже добавление их в пределы класса особо не сыграло роли, так как в последствии выяснилось, что рекурсивные функции сильно выигрывают в данном случае. Единственное, что принесли полезного эти первые попытки — это четкая формулировка, какие функции мне нужны, а также основы реализации деревьев на С++, что в дальнейшем очень помогало и, я надеюсь, еще будет помогать. И, конечно же, именно те первые попытки подтолкнули изучать OpenGL (правда до этого прельстился Direct2D, но очень быстро разочаровался в нем).

Скриншоты

Переход в объем

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

Оптимизация памяти

В октодереве очень часто приходится использовать операторы new/delete, которые выделяют для указателя место в динамической памяти (куче). Динамическая память медленнее, чем статическая (стек), а также сами функции new/delete выполнялись для меня слишком медленно. Из-за чего был написан собственный класс MemoryPool и шаблон mem_pool_tree.
mem_pool_tree был написан под впечатлением от BST-дерева, с которым я познакомился из книги Т. Кормана «Алгоритмы. Построение и анализ», и не работает напрямую с памятью, а только оперирует цифрами, которые в последствии используются для смещение указателя с начала массива в статической области памяти. Предугадать удаления не представлялось возможным, а вот выделять «правильные» куски памяти было реально, из-за чего я взял у BST дерева идею и повороты, и добавил «блочность» — mem_pool_tree хранит узлы, в котором две переменные хранят начало и конец блока, и еще две переменные — начало и конец занятого пространства. Если происходит попытка удалить кусок в середине занятого пространства, то узел делится, если вызывается функция выделения куска, то алгоритм ищет такой блок, где выделение пространства позволит ему объединится с соседним блоком. И периодически вызывается функция балансировки.

Многопоточность

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

class Octree < class Node < Node * son; void Optimize(); >; void Optimize() < #pragma omp parallel < #pragma omp for for(int n = 0; n> > >;

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

Загрузка и сохранение вокселей

Долго пришлось искать оптимальный метод хранения вокселей в файле — ведь в условиях, когда оперативная память ценна, хранить лишние вокселы в оперативке является непозволительной роскошью. После долгих исканий, выбор остановился на SQLite3, в котором есть кэширование, а также возможность загрузить только те вокселы, которые требуются исходя из значений «уровня детализации». Самая быстрая работа с SQLite3 базами оказалось при встраивании в проект исходного кода sqlite3 и самостоятельной компиляции (точных цифр не помню, но что то вроде полмиллиона переменных за 200-250 ms, причем на нетбуке с Intel Atom). Естественно, в SQLite3 использовались для ускорения «Begin transaction;», «Commit transaction;», «PRAGMA journal_mode = MEMORY;», «PRAGMA synchronous = OFF;» и т.д.

Скриншоты

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

Скриншоты

Текущие задачи и заключение

Полиморфизм

Сейчас октодерево в очередной раз переписывается с применением полиморфизма. Основная задача — чтобы дерево было не чистым октодеревом, а скрещением с kd-tree (дерево, в котором идет не разбиение воксела на 8 маленьких вокселей, а разбиение на два воксела с определенной пропорцией и по определенной оси), и еще другими модификациями.

RayCasting

Октодерево позволяет Ray Casting, алгоритм «бросания лучей», с помощью которого сейчас пишу растеризатор. Также реализации алгоритма используется OpenGL (генерация текстуры из массива и отображение его на полигоне), «групповая трассировка» и C++ AMP. В целом, эта тема хорошо раскрыта на ray-tracing.ru.

Заключение

В целом, тема интересная, и можно много интересного найти по ней. Например: статья на хабре про движок Atomontage и презентация технологии SVO с SIGGRAPH 2012.

UPD

Написанный мною класс распределения памяти с использованием массива в статической памяти, после замеров, выдал следующие данные:

удаление 20 млн. объектов по 100 байт каждый (в общей сложности все это занимало более 220 Мб) заняло 2-3 секунды (естественно, объекты удалялись в случайном порядке)
замеры выделения памяти проводил давно, но последние результаты вроде были 50 млн. объектов по 8 байт за 4-5 секунд
чтение быстрее, ибо память стека быстрее памяти кучи, но пока тестирую на разном железе, чтобы выяснить среднюю разницу скорости
при попытке выделить память обычным оператором new из динамической памяти на 50 млн. объектов, программа закидала меня исключениями std::bad_alloc, а когда я написал try-catch, чтобы их обработать, программа нагрузила память настолько, что почти все работающие приложения на компьютере вылетели.

Будущая замена полигонам. Или что такое воксели?

Привет, друзья! Давно не виделись. Не будем затягивать приветствия, а сразу перейдём к теме нашего блога! Все знают, что такое пиксели, ведь так? Это элемент изображения в растровой графике. А что такое воксели? Речь сегодня пойдёт именно о них, ну что, поболтаем немножко о наших кубиках.

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

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

Начнем с начала, что такое воксели?

Как гласит википедия, это элемент объёмного изображения, содержащий значение элемента растра в трёхмерном пространстве. Грубо говоря, это тот же пиксель, но только в 3D с координатой «Z».

Само понятие voxel (воксел) образовано от слияния двух слов volumetric и pixel, что означает (объёмный и пиксель).

Воксельная графика является одним из способов отображения 3D графики, и она является альтернативой полигонам. В сегодняшние дни в 3D моделировании объектов используют в основном только два способа:

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

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

Моделирование с помощью полигонов и вокселей

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

Применение воксельной графики

Теперь давайте поговорим о применении вокселей в деле. И для начала нам нужно разобраться, от куда ноги растут, и рассказать о том, как появились воксели. Появились они прямиком из медицины, с появлением первых компьютерных томографов, или в простонародье КТ. Вообще, первые математические алгоритмы для КТ были разработаны еще в 1917 году австрийским математиком Иоганном Радоном. А уже в 1963 году американский физик Аллан Кормак повторно (но отличным от Радона способом) решил задачу томографического восстановления, а в 1969 году английский инженер-физик Годфри Хаунсфилд сконструировал «ЭМИ-сканер» — первый компьютерный рентгеновский томограф.

Иоганн Радон, Аллан Кормак и Годфри Хаунсфилд

Клинические испытания которого прошли в 1971 году. Разработан он был только для сканирования головы. В 1979 году «за разработку компьютерной томографии» Кормак и Хаунсфилд были удостоены Нобелевской премии.

«ЭМИ-сканер» (КТ)

Теперь то мы можем сделать вывод, что наиболее широкое применение воксели нашли в медицине. Ряд медицинских устройств, например, КТ, УЗИ, МРТ, выдают изображения с большого количества рентгеновских или ультразвуковых снимков под разными углами. После они сканируются и создаётся трёхмерный массив плотностей различных участков тканей исследуемого органа. Этот массив представляет собой «объёмную картину» элементом которой является воксель.

Примеры медицинских воксельных моделей

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

Воксели стали применятся в играх с 1992 года, и первой из них стала игра Comanche: Maximum Overkill . Представляла она собой аркадный вертолётный авиасимулятор.

В игре использовался собственный движок компании, «Voxel Space», полностью написанный на ассемблере. Где воксельная графика позволяла отображать более детализированные и реалистичные ландшафты по сравнению с векторной графикой того времени. Можем сравнить её с Aces Of The Pacific WWII, Birds of Prey и Dawn Patrol. Эти игры тоже были разработаны в пределе 1992 — 1994 года. И на картинках мы с вами можем увидеть большую разницу в проработке ландшафта.

Примеры других игр сделанных в 92-94х годах, но только из полигонов

Кстати, кто назовёт культовую отечественную игру, с использованием вокселей? Ответ будет в конце блога!

Главный недостаток воксельной графики

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

Карта высот в своей красе

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

Как строиться ландшафт благодаря карте высот

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

Наглядный пример как это происходит

Так же воксель может представлять различные свойства. И как мы ранее говорили, «это истинный 3D кирпичик». А это значит, что достать его из объекта очень легко, так как это частичка, из которого строятся различные объекты, как и в реальной жизни, только у нас частицы очень маленькие. Поэтому в играх с частичной разрушаемостью или полной используются воксельные движки. Яркими примерами можно сделать 7 Days to Die, No Man’s Sky, Space Engineers, Trove.

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

Перспективное будущее воксельной графики

Теперь давайте перейдём к перспективам воксельной графики. И они колоссальны! Вы даже представить себе не можете, как. Да я и сам не могу. Как мы уже понимаем, воксели требуют много аппаратно-вычислительных мощностей. И чем реалистичнее мы строим объект, тем больше ресурсов мы потребляем, но в нынешнее время все железяки оптимизированы под полигоны. Если бы мы только смогли воспроизвести гигантское количество вокселей. Мы могли бы делать фотореалистичные игры, а также реальными в плане физики, могли бы делать более правдоподобное поведение света, газа и воды. Например, у нас есть море, и его нужно анимировать, чтобы отображались волны и морская пена, но посредствам полигонов, которые представляют собой «панель» это сделать сложно, а вот воксели как раз подошли под это. Можете взглянуть на модель снизу. Здесь используется очень много частиц, что и позволяет добиться фотореализма.

Ну или представьте себе батон из «S.T.A.L.K.E.R.», и он полностью сделан из вокселей. Из очень, очень большого количества вокселей, тогда вы сможете разрезать его где хотите, как и под любым углом, и увидеть точное пересечение.

Мой пример с хлебом

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

Потуги воссоздать человеческий мозг

Также мы сможем сделать реалистичное разрушение всего и вся, например, в шутере реалистичные повреждения, попадание от пуль, взрывов и так далее. Как можем увидеть на кадрах демке Voxel Plugin для Unreal Engine.

Лучше их глянуть в видеоролике!

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

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

Это реально сделано из вокселей и еще может рендериться в реальном времени!

Вот представьте, когда мы сможем делать модели из микроскопических вокселей, практически не заметных глазу, и наше железо начнёт рендерить это, и мы подкрутим туда еще освещение в реальном времени, это будет нечто. Я даже боюсь представить, вдруг настанет тот момент, когда мы уже не сможем отличить реальность от игры и будет как в 4-й серии 1-го сезона Рика и Морти.

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

Нынешние реалии

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

Вернёмся визуальному стилю. Все началось 18 ноября 2011 г. А что у нас было 18.11.11? Да, все верно, выход легендарной игры Minecraft.

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

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

Вот чем по-вашему отличаются 2 этих изображения?

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

Когда говорят о вокселях, какие первые игры приходят вам на ум? Может быть эти?

Приходят на ум только кубики?

А как вам эти игры?

Вот уже лучше, нет кубов

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

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

В мобильном гейминге вообще все просто. После выхода Crossy Road,которая задала тенденцию на воксели, на мобилках появилось колоссальное количество подражателей. Но воксели пошли на столько далеко, что все начали переводить и пиксельные игры в воксел, та же Flappy Bird, Chrome Dino (гугл динозаврик) и т.д. С каждым днём таких игр все больше. Если есть простенькая популярная 2D пиксельная игра, то ждите адаптацию на вокселях.

Ну а на ПК дела обстоят поинтересней. Можно найти добротные игры полностью из вокселей. Например, Cube World, Unrailed, Cloudpunk и ещё многое другое.

Ну и не могу не поставить в пример недавно вышедшую игру Teardown. Представляет она из себя песочницу, где у вас есть миссии и полная разрушаемость. Она действительно показывает, на что способны воксели. Эта игра нам дарит богатый игровой опыт, который мы мало где видели. А теперь представьте такую же игру, но где воксели в 100 раз меньше и остаётся такая разрушаемость.

Все бегом играть!

Хочу стать воксель-артером!

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

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

А вот вам подборка крутых работ из интернета.

Красотища же!

Ну а если мы хотим сделать простенькую игру? То можно ещё подключить Mixamo. Тоже бесплатно. Просто загружаем нашего персонажа и вуаля!

У нас есть готовые анимации для персонажа раннер сделать уже сможем. И благодаря этому мы, считай, получаем LVL UP. Лично я раньше рисовал 2D модельки для своих проектов, а теперь могу позволить себе какое никакое 3D. Это, кстати, ответ на то, что говорилось ранее. Мобильный рынок захлестнули такие игры и это только начало. Скоро все, кому не лень будут делать игры на вокселях, так как чтобы сделать 3D модель, много знаний не надо, а анимацию можно легко прикрутить.

Заключение

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

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

И да, про культовую отечественную игру с использованием вокселей. Это Вангеры!

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

Всем удачи и до скорых встреч!

Как мы сделали игру для Highload++ с воксельной графикой и VR

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

О спикере: Александр Хаёров (@allexx) руководит отделом разработки в компании Ingram Micro Cloud. Ребята в команде Александра считают себя не просто отличными инженерами, а называют себя великой командой voxel джедаями, мастерами оптимизации, гуру 3D и повелителями больших данных! [примечание: по аналогии с названиями должностей в LinkedIn и Medium]

Эта классная команда, готовясь к выступлению на Highload++ 2017, решила развлечь аудиторию и сделать что-то новое и интересное для стенда. Поэтому они запилили игру, о создании которой и пойдет дальше речь.

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

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

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

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

В этой статье я узнал несколько забавных фактов:

97% мифических инди-разработчиков — это мужчины;
60% из них — нет, не одиночки, но делают игры в одиночку;
В среднем, чтобы сделать инди-игру, требуется от 1 до 3 месяцев.

Так получилось, что мы тоже начали делать игру.

Почему мы начали делать игру

Мне всегда нравились игры от сервиса Reddit. Думаю, и вы не один месяц своей жизни провели на этом ресурсе.

A social experiment by Reddit

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

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

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

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

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

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

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

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

The Game

Features

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

Однозначно хотелось сделать мультиплеер.

Мы выбрали 3D-графику.

Решили взять хайповую технологию — пусть это будет Виртуальная Реальность.

Так у нас образовался Features set, но без определенного геймплея.

Concessions

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

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

Справка: Воксель (Voxel) — это практически пиксель, но в 3-мерном мире. Например, в игре Minecraft мир представлен вокселями.

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

Gameplay и правила

Кажется, что геймплей — это очень простая вещь! Мы прекрасно знаем, как играть в StarCraft, Doom или Quack. Но когда вы создаете свою игру, у вас возникает огромное количество идей. Эти мысли разлетаются в разные стороны и очень сложно (особенно в команде) договориться о том, как игра будет выглядеть и что в ней будет происходить.

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

Нужно найти спот — некое здание — именно поэтому игра называется Urban (Город).
На споте есть флаг, который нужно захватить, за это начисляются баллы.
Участник, набравший больше всех баллов, получает приз.
Игроки могут свободно перемещаться по общему миру и перезахватывать флаги (вариация «capture the flag»).

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

Архитектура

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

Игроки.
Специальный стенд для того, чтобы поиграть в шлеме виртуальной реальности.
Браузер, поскольку мы решили, что это будет браузерная игра. Люди будут туда приходить и получать оттуда данные.
Какая-нибудь «хранилка» — ведь у нас многопользовательская игра по сети, нам нужно где-то хранить данные о разных игроках.

Проблема репликаций в распределенных системах

Как «хранилка» должна общаться с браузером, где работает игра? Тут начинаются интересные моменты, и я бы хотел вас отвести в более знакомую область.

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

Выделяются два вида репликаций:

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

Плюсы и минусы активной репликации:

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

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

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

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

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

Плюсы и минусы пассивной репликации:

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

+ Вторым моментом, и зачастую очень недооцененным и важным, является безопасность игр. Недавно появилась игра VKpixel Battle — прямой аналог игры Place от Reddit, в которой тоже можно было разрисовывать доску. Эту игру взломали в течение нескольких часов ( источник ). В пассивной модели безопасность игры заметно легче обеспечить по той причине, что опять-таки есть сервер, где можно много всего контролировать.

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

Мы недолго думали, и, как и разработчики всех современных игр, выбрали пассивный способ репликации. На самом деле сейчас подавляющее большинство игр (порядка 99%) используют пассивную репликацию. Поэтому на нашей мощной enterprise-архитектуре появился еще один компонент — game-бэкенд, который берет на себя задачу синхронизации.

Data Structure

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

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

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

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

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

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

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

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

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

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

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

Протокол взаимодействия между фронтендом и бэкендом

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

Как мы уже знаем, наш мир представлен в виде параллелепипеда с основанием 1000×1000 и высотой 200. Можно проигнорировать высоту и всегда использовать максимальную высоту в выгрузке. Это сильно упрощает создание игры.

В свою очередь каждый квадрат в соответствии с нашим стандартом мы разбили на чанки 32×32 вокселя внутри.

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

служебное поле id,
координаты,
название цвета игрока,
некое служебное название,
дата, когда этот блок появился.

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

Определяем ближайшие чанки, которые игрок может видеть, и формируем радиус. На самом деле это не совсем корректное название. Мы формируем понимание расстояния и смотрим, какое количество чанков это затрагивает. Далее делаем запрос get к базе данных, в котором говорим текущую координату игрока и этот радиус.
Создаем set — блок или кубик на карте. Здесь достаточно просто отправить координаты кубика, который хотим установить.

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

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

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

Так у нас сформировался протокол взаимодействия.

У нас был небольшой выбор того, как мы можем общаться между бэкендом и фронтендом: HTTP, WebSocket, HTTP2. Мы решили остановиться на WebSocket по понятным причинам — для того, чтобы интуитивно уменьшить потенциальные задержки, которые были возможны.

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

Так у нас сформировался определенный стек в архитектуре. Ключевой точкой взаимодействия в нем стал WebSocket.

Game-backend

Бэкенд, как минимум, можно назвать сердцем нашей системы.

Так как мы имеем определенный опыт в web-разработке, мы решили не использовать новых, для нас неизвестных технологий. Мы остановились на Python 3.6 и aiohttp. То есть у нас получился полностью асинхронный сервер.
К нему мы добавили измененный loop — это uvloop, который позволяет еще быстрее работать.
Так как мы используем MongoDB, нам нужен был какой-то асинхронный клиент. Для этого мы использовали motor, который прекрасно позволяет общаться с MongoDB в асинхронном режиме.
Наконец, для того, чтобы выставить наш сервер наружу, мы использовали gunicorn, который разрабатывает на Python.

Game-frontend

Это изюминка нашей игры — то, как игра начинает жить и существовать.

В первую очередь у нас встал вопрос — каким образом мы можем написать игровой движок, как вообще делать игры и как это все работает. После недолгого изучения материала мы поняли, что существует библиотека WebGL, которая позволяет очень многое. Она работает с библиотекой OpenGL, которая уже в свою очередь работает с оборудованием, с драйверами, с видеокартой и т.п.

Поэтому первая мысль была — использовать обычный нативный JavaScript, посмотреть, какой API предоставляет WebGL и начать делать игру. Эту идею мы достаточно быстро отмели, потому что по опыту в web-разработке понимали, что разрабатывать самому web-сервер — очень странная и долгая затея. Тем более у нас не было так много времени.

После недолгих поисков мы нашли JS-библиотеку, которая называется Voxel.js. На самом деле она стала для нас Граалем, потому что представляет очень много инструментов.

Библиотека существует уже более 3 лет, и, как заявляет автор, фактически является tool-kit для создания современных браузерных игр, причем воксельных. В ней присутствует все, что необходимо.

Понятие мира, в котором есть оси и координаты;
Работа с блоками (вокселями), которые понимают концепцию чанков;

Инструменты для создания видеоигр:

ограничивающие многогранники для того, чтобы понимать столкновения, нахождение рядом, работу с объектами и т.п.;
ray casting — метод, который позволяет из 3D-объектов создавать на мониторах вид 2D;
текстуры.

Как выглядит весь стек

Мы пишем свой код, используя библиотеку Voxel.js — это наша специальная логика.
В свою очередь Voxel.js общается с библиотекой, которая называется three.js. На ней я немножко остановлюсь, потому что она является краеугольным и важным камнем во всей этой схеме.
Далее three.js уже общается с WebGL, которая фактически встроена в браузер (использует его API).
WebGL работает уже с настоящим оборудованием — с OpenGL драйвером, который рисует картинку на мониторе.

На самом деле сцену с использованием three.js, и в частности с Voxel.js, который это использует, произвести на свет не так уж и просто. Хотя кажется, здесь нет ничего сложного ровным счетом.

Посмотрим на код, но не будем заранее пугаться.

Чтобы создать классную 3D-картинку в браузере, нужны на самом деле всего 3-4 вещи:

В первую очередь нужна сцена, как и в обычном мире.
На этой сцене должна быть камера — мы создаем объект camera, в котором обозначаем размеры и максимальное/минимальное расстояние, которое мы видим.
После этого нам нужно устройство, которое будет рендерить — создавать для камеры на сцене то, что мы хотим видеть. Для этого мы создаем render. В данном случае как раз используется WebGL технологии, и наша видеокарта будет трудиться для того, чтобы создать мир.

4. Для того, чтобы создать объект, нам нужны:

Геометрия (geometry) — это то, как объект будет выглядеть в пространстве. Например, если это куб, то у него должны быть вершины и грани.
Материал (material) — для того, чтобы раскрасить объект. Самый простой вариант — использовать цветную заливку.

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

Виртуальная реальность

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

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

Oculus Rift

Мы решили использовать не статическую картинку, а все-таки создать графику с видео. Поэтому наш выбор пал на Oculus Rift.

Опять-таки выбор был достаточно интуитивный и спонтанный. В нем нет ничего особенного, Oculus Rift представлен, как минимум, 3 базовыми устройствами:

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

+ Это действительно VR-картинка — она вполне настоящая и позволяет обманывать наш мозг и представлять, что мы находимся в 3D-мире.

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

+ Это действительно очень удобное устройство, хорошо сделанное, которое прекрасно лежит в руке и отлично носится на голове. Можно сказать, что это действительно потребительское устройство.

— Я представлял себе VR так, что можно просто надеть шлем, девайсы и будет классно! На самом деле это огромное количество проводов. Фактически к каждому устройству необходим кабель, а то и два.

— Второй важный для меня момент и легкое разочарование — я ожидал, что я возьму свой обычный лэптоп и смогу программировать, сидя на диване. Оказалось, что есть серьезные ограничения: можно использовать только Windows, Oculus и SDK не доступен для macOS/Linux. Возможно, это стратегия компании или особенность операционной системы — мне сказать достаточно сложно.

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

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

Как делать игры для VR

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

A-Frame

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

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

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

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

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

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

Так мы начали делать версию для VR.

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

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

Возвращаясь к нашей enterprise-архитектуре, мы пришли к тому, что у нас будет два клиента:

Один для обычной игры с использованием Voxel.js.
Другой — с использованием библиотеки A-Frame.

Оптимизация

Напоследок хотел бы рассказать немного об оптимизации.

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

1. Pre-process voxel models

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

Когда этот мир загружался, наша картинка требовала много данных и достаточно медленно работала, поскольку содержала очень много вокселей. Первое, что нам пришло на ум: «Почему бы не сделать объекты полыми, то есть внутри не создавать эти самые кубики? Ведь пользователь их все равно не увидит!»

Мы написали очень простой алгоритм, который позволяет исключать из нашего мира, который мы создали в отдельном редакторе, воксели, которые находятся внутри. Это просто колоссально снизило количество передаваемых данных — примерно на 78% уменьшило количество вокселей в мире.

2. User Mesher

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

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

Кстати, в некоторых фреймворках mesher включен по умолчанию. Так c Voxel.js мы получили достаточно приличный FPC изначально. В A-Frame такого нет, и мы использовали mesher уже дополнительно.

3. Enable compression for WebSocket (RFC 7692)

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

Мы передавали достаточно большое количество текста (в данном случае JSON) между клиентом и сервером. Эти данные были очень похожи друг на друга. Поэтому у нас возникла идея — почему бы нам их не сжать?

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

Там есть несколько технологий, основанных на использовании специальных плагинов. Фактически включение такой технологии на сервере в нашем случае позволило заметно понизить трафик — буквально с 5 MB передаваемых данных до 1,8 MB.

Приятно, что современные браузеры — такие, как Chrome, Firefox, Safari — поддерживают компрессию со стороны клиента. Вам достаточно правильно включить компрессию на сервере и реализовать ее, и все будет прекрасно работать.

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

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

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

Кстати, к РИТ++ 2018 ребята готовят ремейк логической игры Pipes — называется CloudPipes.

Что еще раз подтверждает тезис, участие в конференциях, особенно наших, — это весело!

Расписание фестиваля с докладами, митапами, викториной и «Что? Где? Когда?» готово, а у вас еще есть шанс приобрести билет.

Также на забывайте про Highload++ Siberia, которая тоже всего через месяц.

Как сделать воксельную игру

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

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

Например воксельное яблоко можно разрезать под любым углом и в любом месте, и увидеть на срезе его «наполнение». Полигональное яблоко будет просто «оберткой», которая не имеет внутреннего объема.

Также это сравнимо с растровой графикой, в которой построение конечного объекта происходит при помощи точек, содержащих в себе информацию о цвете — пикселей.

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

Если пиксель (pixel) является составным термином из слов «картина» и «элемент» (picture, element), то воксель является слиянием слов «объём» и «пиксель» (volume, pixel) CGITEMS_ voxel_1.png Пример того, как сильно отличается принцип построения полигональной и воксельной 3D моделей

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

История появления воксельной графики

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

В 1963 году американский физик Аллан Кормак повторно (но отличным от Радона способом) решил задачу томографического восстановления, а в 1969 году английский инженер-физик Годфри Хаунсфилд сконструировал «ЭМИ-сканер» — первый компьютерный рентгеновский томограф.

CGITEMS_ voxel_2.png

Вся их работа была направлена на то, чтобы добиться качественной визуализации человеческого тела и отдельных органов. Ряд медицинских устройств, например, КТ, УЗИ, МРТ, выдают изображения с большого количества рентгеновских и ультразвуковых снимков под разными углами. После они сканируются и, на их основе, создается трехмерный массив плотностей различных участков тканей исследуемого органа. Этот массив представляет собой объемное изображение элементом которого является воксель. Рентгеновские лучи и ультразвук помогают получить информацию о плотности, прозрачности частиц, их положении и высотах. Математические алгоритмы на основе этих данных позволяют сформировать воксельную модель — массив «кирпичей» на основе которых происходит визуализация, например, человеческого мозга. По сути это «выращивание» 3D модели из 2D среза

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

Применение воксельной графики в играх, краткий разбор технологий

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

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

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

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

CGITEMS_ voxel_3.jpg Крайне схематичный, но в тоже время наглядный пример того, как вода реализована при помощи вокселей и является полноценными частицами, а не сугубо визуальной симуляцией. Дождь падает реальными каплями, водопад течет настоящим потоком Представьте себе что таких кубиков десятки тысяч, а их размеры в сотни раз меньше. Получится вполне реалистичная вода, от которой ваш процессор расплавится, либо попросит добить его и избавить от мучений. CGITEMS_ voxel_4.png Пример классического способа реализации воды — плоскость, на которой имитируется поверхность воды, блики, волны и тд. С одной стороны дешевой и сердито, а с другой стороны это оптимизированный способ, посредством которого талантливые программисты выдают впечатляющие результаты не настолько требовательные к вычислительному ресурсу.

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

CGITEMS_ voxel_5.png

Начало применения воксельной графики в играх

Яркий пример первой (либо одной из первых популярных игр) это Comanche: Maximum Overkill , от студии NovaLogic , которая была выпущена в 1992 году.

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

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

CGITEMS_ voxel_6.png

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

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

CGITEMS_ voxel_7.png

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

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

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

К слову, даже Джон Кармак (ID software) приложил к этому руку в конце 90х, и между разработкой Quake 1/2 и Quake 3 провел ряд исследований. Но также пришел к тому, что железо пока отстает от полета мысли разработчиков. Как бы то ни было, начало было положено и воксельная графика начала применяться в производстве игр.

CGITEMS_ voxel_8.png CGITEMS_ voxel_9.png CGITEMS_ voxel_10.png CGITEMS_ voxel_11.png

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

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

В частности в Vangers миры были спроектированы студией K-D Lab с помощью собственного редактора ландшафта — Surmap ART, и сопутствующей технологии воксельно-полигонального моделирования.

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

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

Применение воксельной графики в современных играх

Нельзя просто взять и пройти мимо одного из самых крупных и известных проектов, основанных на воксельной графике и процедурной генерации — No man’s sky.

Она была разработана и выпущена британской инди-студией Hello Games в 2016 году. Не будем вдаваться в детали старта игры на релизе — она вызвала неоднозначную реакцию, но мы говорим о технологиях. А технологий там накручено щедро и со вкусом.

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

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

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

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

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

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

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

(сокращенная цитата с wikipedia).

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

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

CGITEMS_ voxel_12.png

В целях сравнения — скриншоты из No man’s sky и Comanche: Maximum Overkill . Комментарии, как говорится, излишни

Очень занятный пример, это игра Teardown 2020 года от студии Tuxedo Labs . Её фишка заключается в том, что здесь принцип воксельной графики использован по полной — полностью разрушаемые воксельные локации и большой простор для действий игрока.

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

CGITEMS_ voxel_13.png

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

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

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

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

Minecraft

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

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

Можно сказать, что это нечто среднее между No man’s sky и Minecraft. С одной стороны здесь реализована полностью разрушаемая природная среда, которая имеет внутреннее наполнение, с другой стороны это просто инструмент, на базе которого развернут мощный симулятор инженера, под капотом у которого есть даже возможность программирования устройств и блоков, которые вы создаете.

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

CGITEMS_ voxel_14.png

Space Engineers

Какой из этого можно сделать вывод?

Технология, намек на которую появился в начале 19го века прошла путь от медицинской сферы, через простенький (по нынешним меркам) военный симулятор, до огромных многофункциональных игр-конструкторов с громадным потенциалом и современной графикой. И все это (в разрезе игр) всего за каких то 30 лет. Что будет дальше? Кто знает. Перспективы очень впечатляющие несмотря на всю специфичность технологии.

CGITEMS_ voxel_14.jpg

А казалось бы, хотел очередной красивенький домик нарисовать и лайков десяток собрать, да?

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

Обзор редакторов, позволяющих работать с воксельной графикой

3D Coat

Во-первых, стоит присмотреться к редактору под названием 3D-coat.

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

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

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

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

CGITEMS_ voxel_15.png

3D coat

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

MagicaVoxel

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

CGITEMS_ voxel_16.jpg

MagicaVoxel

Qubicle

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

CGITEMS_ voxel_17.jpg

Qubicle

Voxel Max

Суть та же, с одним отличием — этот редактор доступен только для iOS и поддерживает работу пером.

CGITEMS_ voxel_18.jpg

Voxel Max

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

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

Надеемся, что эта информация пригодится вам, заставит задуматься, или, что еще лучше — вдохновит и подтолкнет к изучению чего-то нового. Удачи в начинаниях!

геймдев.png

Поделиться
Копировать

Что такое топология

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

Топология относится к геометрическим характеристикам поверхности 3D сетки. Также можно встретить понятие «Polygon Flow» - поток полигонов, но расположение вершин и ребер сетки также играет важную роль в создании 3d моделей.

Можно сказать, что по сути не существует четких стандартов или железных правил в работе с топологией. Это та сфера, успеха в которой можно достигнуть только посредством практики, анализа и наработки опыта, «насмотренности».

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

В чем же заключается важность топологии?

В принципе, это зависит от задачи стоящей перед художником.

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

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

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

Из чего состоит 3D модель

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

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

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

Polygon - многоугольник. Состоит из трех или более вертексов, с замкнутым контуром эджей. Это как раз та самая форма, которая определяет поверхность трехмерной сетки. Polygon flow - помните такое понятие, верно?

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

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

Наглядный пример как подразделяется 3D модель на её составляющие

Виды и особенности полигонов

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

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

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

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

Triangle, Quadrangle, N-Gon

Существует ряд мнений среди 3D сообщества на тему применения N-Gon и Triangle полигонов в создании модели. На деле все зависит от ситуации и целей, с которой создается модель.

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

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

Planar и NON-Planar полигоны (плоские и неплоские)

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

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

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

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

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

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

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

Subdivision Surface (SubD)

Subdivision Surface - это алгоритм подразделения поверхностей, который создает гладкую поверхность из «грубой» полигональной сетки. Когда сетка подразделяется, она становится более плавной, её детали принимают более финальный вид.

Это преобразование является обратимым, только если вы не применили финальное сглаживание (например, перед выгрузкой High Poly для запекания).

Слева направо: полигональная сетка, сетка с примененным SubD и Control Cage (контрольной клеткой), Final Smooth (финальное сглаживание)

Наиболее часто используемым алгоритмом subdivision surface является Catmull - Clark (CC SubD). Его разработали Эдвин Катмулл и Джеймс Кларк в 1978 году. Обратите внимание, насколько давно удачная идея стала инструментом актуальным до сих пор.

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

Этот алгоритм итеративен, то есть может повторяться раз за разом, наращивая количество подразделений. Таким образом, мы получаем high poly модель, и именно этот процесс нам надо учитывать при построении модели под SubD.

Схема подразделения полигонов по алгоритму CC SubD

Слева: Эдвин Катмулл - американский инженер-мультипликатор, специалист по компьютерной графике, президент DisneyToon Studios, Pixar и Walt Disney Animation Studios, тьюринговский лауреат, член Национальной инженерной академии США, четырёхкратный лауреат «Оскара».

Справа: Джеймс Кларк - бизнесмен, технолог, миллиардер. Основал Silicon Graphics, Netscape Communications, myCFO, Healtheon, «Neoteris», «Sciences DNA», Shutterfly.

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

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

Важные определения и понятия топологии, которые надо знать и учитывать

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

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

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

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

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

Простой пример PolyLoop - полигональной петли

EdgeLoop - в свою очередь это петля из эджей (ребер). Как и с PolyLoop - петля ребер это разрезы, которые вы будете делать на модели, и они буду замыкаться.

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

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

В работе с EdgeLoop также стоит мыслить именно петлями, а не отдельными ребрами.

Пример EdgeLoop - замкнутой петли рёбер

Звезда (pole, star, полюс) - это вершина в сетке, в которую приходит 3 и более ребер. В зависимости от ситуации это может быть как плохо, так и хорошо для вашей сетки.

Неправильное размещение звезд может привести к артефактам на сглаженной модели.

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

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

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

Примеры того, в каких ситуациях появляются звезды

E-pole - полюсы, которые состоят из пяти ребер, пересекающихся в одной вершине. N-pole - полюсы, которые состоят из трех ребер также пересекающихся в одной вершине.

Hold Edges (support edges, поддерживающие ребра) - подразделение поверхностей создает сглаженную поверхность модели.

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

Также во многих современных 3D редакторах есть такая функция, как Edge Creasing (иногда её называют Edge Weighting или вес ребра) - заострение ребра. Эта функция позволяет задать «натяжение» на выбранных ребрах. В целом Hold Edges также является очень мощным и многофункциональным инструментом, который можно и нужно использовать и знать, как он работает.

Пример применения Hold Edges слева направо: без поддержек, с обычными поддержками (support edges), edge creasing. Как видите, они дают очень разные результаты. Пробуйте и экспериментируйте с hold edges чтобы лучше понять, как они работают

Еще один пример работы с Support Edges. Также на этом примере можно отследить Edge Loops, Poly Loops и Poles

Немного о топологии в Low Poly

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

Суть его в том, чтобы на основе вашей High Poly модели сделать её облегченную версию, которая будет, скажем так, «облеплять» High Poly модель. Это необходимо для процесса запекания (baking) и дальнейшей выгрузки готовой модели в движок.

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

В процессе создания Low Poly модели вам надо будет избавиться от Support Edges, лишних Edge Loops, которые не влияют на силуэт и форму модели, сократить количество граней на цилиндрах, избавиться от фасок, удалить скрытые полигоны, сшить пересекающиеся элементы, проверить врезки «элемент в элемент», иначе говоря пересекающиеся элементы.

Так же как и в High Poly, в Low Poly нет четких условий в моделировании - все ситуативно и необходимо смотреть на финальный результат, при необходимости возвращаясь назад и внося корректировки.

Давайте возьмем за основу принцип «отрезать все лишнее и ненужное, оставляя суть модели». На этом этапе нас уже не интересует SubD, нам важна легкая, упрощенная модель дающая четкий силуэт, которую мы сможем триангулировать и отправить на запекание\в движок.

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

Несколько примеров того, как могут выглядеть Low Poly модели. Разница с High Poly очевидна, не так ли?

Итак, давайте подытожим

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

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

Используйте меньше полигонов там, где это возможно.

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

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

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

Соответственно, создавайте модель вдумчиво, ориентируйтесь на визуальный результат.

Ну и конечно помните о том, что хорошая сетка, это сетка на квадах.

Следите за размерами полигонов и снова - за их количеством.

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

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

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

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

Работая с LowPoly помните про количество полигонов, силуэт модели и то, что надо срезать все лишнее оставив самое важное.

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

[~DETAIL_TEXT] =>

Что такое топология

В чем же заключается важность топологии?

В принципе, это зависит от задачи стоящей перед художником.

Из чего состоит 3D модель

Наглядный пример как подразделяется 3D модель на её составляющие

Виды и особенности полигонов

Triangle, Quadrangle, N-Gon

Planar и NON-Planar полигоны (плоские и неплоские)

Subdivision Surface (SubD)

Схема подразделения полигонов по алгоритму CC SubD

Важные определения и понятия топологии, которые надо знать и учитывать

Простой пример PolyLoop - полигональной петли

В работе с EdgeLoop также стоит мыслить именно петлями, а не отдельными ребрами.

Пример EdgeLoop - замкнутой петли рёбер

Неправильное размещение звезд может привести к артефактам на сглаженной модели.

Примеры того, в каких ситуациях появляются звезды

Hold Edges (support edges, поддерживающие ребра) - подразделение поверхностей создает сглаженную поверхность модели.

Еще один пример работы с Support Edges. Также на этом примере можно отследить Edge Loops, Poly Loops и Poles

Немного о топологии в Low Poly

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

Несколько примеров того, как могут выглядеть Low Poly модели. Разница с High Poly очевидна, не так ли?

Итак, давайте подытожим

Используйте меньше полигонов там, где это возможно.

Соответственно, создавайте модель вдумчиво, ориентируйтесь на визуальный результат.

Ну и конечно помните о том, что хорошая сетка, это сетка на квадах.

Следите за размерами полигонов и снова - за их количеством.

Что такое топология

В чем же заключается важность топологии?

В принципе, это зависит от задачи стоящей перед художником.

Из чего состоит 3D модель

Наглядный пример как подразделяется 3D модель на её составляющие

Виды и особенности полигонов

Triangle, Quadrangle, N-Gon

Planar и NON-Planar полигоны (плоские и неплоские)

Subdivision Surface (SubD)

Схема подразделения полигонов по алгоритму CC SubD

Важные определения и понятия топологии, которые надо знать и учитывать

Простой пример PolyLoop - полигональной петли

В работе с EdgeLoop также стоит мыслить именно петлями, а не отдельными ребрами.

Пример EdgeLoop - замкнутой петли рёбер

Неправильное размещение звезд может привести к артефактам на сглаженной модели.

Примеры того, в каких ситуациях появляются звезды

Hold Edges (support edges, поддерживающие ребра) - подразделение поверхностей создает сглаженную поверхность модели.

Еще один пример работы с Support Edges. Также на этом примере можно отследить Edge Loops, Poly Loops и Poles

Немного о топологии в Low Poly

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

Несколько примеров того, как могут выглядеть Low Poly модели. Разница с High Poly очевидна, не так ли?

Итак, давайте подытожим

Используйте меньше полигонов там, где это возможно.

Соответственно, создавайте модель вдумчиво, ориентируйтесь на визуальный результат.

Ну и конечно помните о том, что хорошая сетка, это сетка на квадах.

Следите за размерами полигонов и снова - за их количеством.

Топология в 3D моделировании Документация, Основы
4416 просмотров

Подготовка к запеканию

Простая High-Poly модель 2_CGitems.ru_Запекание_текстур.png

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

Floaters. Парящая (летающая) геометрия

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

Из статьи про Averaged normal мы уже знаем как работают нормали при запекании - процесс напрямую связан с их направлением. В случае с парящей геометрией на плоскости, она будет запечена по направлению нормалей Low-Poly этой плоскости. Далее мы увидим это на примере. Парящая геометрия это важный инструмент, его применение ускорит вашу работу. Гораздо проще сделать подобный элемент отдельным, а не врезать его в остальную модель. Но как и всегда - все зависит от конкретной ситуации.

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

Еще пара моментов, на которых стоит заострить внимание:

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

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

Пример разного типа фасок 5_CGitems.ru_Запекание_текстур.png

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

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

На этом закончим с High-Poly, далее нам необходима Low-Poly модель, которая примет на себя информацию при запекании.

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

Важный момент готовой low-poly - это ее UV развертка. От того как вы ее сделаете будет полностью зависеть финальный результат запекания и внешний вид модели. Также это полезный инструмент для оптимизации модели и упрощения работы с ней. На деле ее функционал в разы шире, но в этот раз нас интересует запекание.

UV развертка

По сути, UV развертка это набор плоскостей составляющих вашу Low-Poly, развернутых и размещенных в 2D пространстве по определенным правилам. Хороший пример - это разобранная картонная коробка. Оси этого пространства называются U и V. U - горизонтальная ось, V - вертикальная.

Пример того как можно разложить UV шелы коробки на UV пространстве

UV развертка позволяет корректно проецировать на модель текстурные карты учитывая ее геометрию. Этот процесс называется Mapping. Именно UV развертка отвечает, в частности, за корректное запекание с High-Poly и формирование правильных финальных текстурных карт. Сам процесс UV развертки достаточно индивидуален и понимание деталей приходит с опытом. Суть UV в следующем.

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

Разрешение UV пространства определяет разрешение текстуры на UV развертке. Внутри этого пространства размещаются те самые элементы развертки. Когда UV пространство доходит до краёв от 0 до 1 - происходит повторение и новый отсчет от 0 до 1. На схеме это серые клетки по краям. Таким образом UV пространство дублируется до бесконечности во всех направлениях. Это называется tiling, повторение - текстурные карты в каждом таком дубликате будут повторять изначальное UV пространство. С этим связана такая возможность, как применение бесшовных (тайловых) текстур, но об этом в другой раз. В этот раз мы поговорим о таком использовании UV пространства как overlap (перекрытие). Это напрямую касается запекания и подготовки к нему.

Overlap

Посмотрим на схему - на UV есть часть текстуры (квадрат). Под воздействием повторения она будет копироваться до бесконечности во всех направлениях и находиться точно на том же месте. Это дает нам возможность схитрить при создании Low-Poly.

Предположим, что у нас есть некий относительно крупный элемент имеющий отдельную low-poly с готовой разверткой.

Теперь предположим, что у нас есть два таких элемента и они совершенно одинаковы. Эти элементы можно запечь вместе и при этом сэкономить место на UV. 10_CGitems.ru_Запекание_текстур.png

Каждый из них имеет свою развертку и каждая из них занимает индивидуальное место в квадрате 4х4. Как мы помним - это пространство ограничено от 0 до 1, и начинает повторяться. Следовательно, мы ограничены в количестве индивидуальных мест. Как при переезде при всем желании не получится запихать все в одну коробку, так и в случае с UV не получится разместить в один сет все, что захочется. Overlap - это способ, который позволяет при запекании (и в дальнейшем) переиспользовать текстурное UV пространство с одного объекта на другой или с одной стононы объекта на другую. Overlap помогает экономить место на UV. Чтобы применить Overlap, надо совместить развертки элементов точка в точку.

На примере видно, что выделен один куб, он станет копией. Его развертка накладывается на развертку исходника. Overlap сработает, так как эти элементы соответствуют друг другу на 100%. Важно, чтобы все стороны и их ориентация на UV совпадали - верх с верхом, правая с правой и.т.д. 12_CGitems.ru_Запекание_текстур.jpg

После того, как вы убедились что все совпало - надо выделить и сместить развертку копии на соседнее UV пространство (по факту на любое - верх, низ, левое, правое, лишь бы не основное), иначе запекание пройдет некорректно, так как оба элемента будут восприниматься как главные и конфликтовать. Важно, чтобы развертка копии заняла точно тоже место, что оригинал. В maya (UV editor) смещение делается стрелками клавиатуры, это позволяет правильно сместить UV одним нажатием. Если вы верно совместили UV и не забыли отбросить копию, то запекание пройдет корректно, а копия примет на себя информацию исходника. А теперь представьте, что таких копий может быть 5-10-20, все они могут быть наложены на все тот же первый исходник, отброшены на соседний квадрат и будут принимать на себя информацию исходника, но при этом место на UV по итогу будет занимать только исходник. Выглядит сложновато, но на деле все не так страшно, достаточно немного практики.

Padding

Еще один важный момент, который стоит учитывать при создании UV, это padding (отступы).

На примере видно, что в UV пространстве есть 4 шела UV развертки - расстояния между ними отмеченные пунктиром, это и есть отступы (Padding). Важно соблюдать их. Отступы влияют на то, как будут вести себя текстурные карты. Если не соблюдать отступ от общих границ UV развертки, то при запекании в этих местах будет артефакт. Если не соблюдать отступы между UV шелами - края UV шелов будут наползать друг на друга в определенных ситуациях. Хуже всего, если они будут залезать друг на друга, это 100% даст артефакт. Просто надо строго взять за правило, что всегда в любой ситуации должны быть отступы не менее 4 px между UV шелами и от границ UV развертки, а по хорошему чуть больше и это расстояние всегда должно быть на первом месте при компоновке, пренебрегать им не стоит.

Texel density. Разрешение UV пространства

Ранее мы коснулись темы разрешения UV пространства и его влияния на развертку. Параметр Texel Density является численным значением количества пикселей на единицу UV пространства. В нашем UV пространстве стороны 4х4 метра, итого 16 квадратов 1х1 метр. Заданы распространенные значения - разрешение 2048х2048, тексель 512px на единицу (в нашем случае метр). 512*4(метра в стороне)=2048 - одна сторона. Тексель распределяется равномерно. Вот чем это важно для процесса запекания - разрешение UV пространства влияет на то, какое разрешение текстур будет на запеченной Low-Poly. И это может как принести проблем, так и помочь в работе.

Существует такой инструмент как Checker - по сути это эталонная текстура-шаблон, по которой можно проверить равномерность текстуры на модели.

На примере куб с готовой UV разверткой, на ней установлен тексель 512px/m2. Включенный Checker позволяет увидеть как эта текстура выглядит на модели - как видите, размеры текстуры совпадают по всем сторонам. 29_CGitems.ru_Запекание_текстур.png

Вручную уменьшим размер двух шелов UV развертки - обратите внимание, что модель осталась прежней, уменьшены именно UV шелы. На кубе видно разницу - на двух полигонах изменился размер текстуры. Это как раз то, за чем также необходимо следить при создании UV развертки - шелы UV должны соответствовать значению тексель и быть одинаковы по масштабу относительно друг друга. Но есть исключения. Если вы будете пытаться запечь мелкий элемент на вашей модели, то скорей всего на нём практически ничего не будет видно. Это можно компенсировать принудительно увеличив его UV шел на развертке. Но главное с этим не перестараться. Еще одно исключение, а скорее правило - во многих моделях есть более заметные и менее заметные участки модели. Пример - оружие от первого лица, в нем Texel Density на элементах ближних к камере (задняя часть оружия) будет выше чем, например, на нижней части, которую игрок чаще всего не видит, либо видит мельком. И в этом суть - за размерами UV шелов нужно следить и настраивать при необходимости. Для начала достаточно просто следить за верным Texel Density и не давать мелким элементам съедаться, а понимание придет с опытом.

Итак, мы разобрали несколько важных моментов, которые обязательно стоит учитывать и проверять на финальных этапах подготовки Low-Poly. Рассмотрели ряд примеров, узнали как оптимизировать модель на этапе UV развертки. Самое время вернуться к примерам с которых мы начали, и запечь их учитывая все изложенное выше.

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

Как видите, занято очень много места, больше половины. Иногда это необходимо, ведь элемент может быть центральным, важным и требовать больше детализации и уникальности. Но чаще всего в этом нет большой необходимости, а уникальности можно достигнуть разными путями. Поэтому в случае примера будет применен уже знакомый вам overlap, но по несколько иному принципу, хотя в конечном итоге точно такой же. Отличие будет в том, что мы применим overlap внутри модели, а не от одной к другой. Это было учтено при создании high-poly - в ней все сделано симметрично, с учетом того что будет overlap слева направо. 16_CGitems.ru_Запекание_текстур.png Для этого оба элемента были разрезаны строго по середине, это дало разрез на UV. Развертка с копией - красная половина, была совмещена с разверткой исходника - синей половиной. Красная половина была в процессе отзеркалена, это важный момент, который влияет на корректное совмещение двух половин и отражение текстур слева направо. Как уже говорилось выше - каждая сторона должна совпадать с исходником как по периметру, так и по ориентации. Сам объект при этом остается цельным, просто с петлей эджей в центре. 15_CGitems.ru_Запекание_текстур.png В результате мы получаем более оптимизированную развертку, она занимает гораздо меньше места, а при покраске приятным бонусом будет, то что надо будет покрасить только одну половину объекта и свести стык по центру. Обратите внимание, что на развертке соблюдены отступы. Как видите, этот процесс полностью идентичен примеру с кубами и подчиняется тем же правилам. А индивидуальные способы применения и научитесь видеть со временем и практикой.

Еще один момент который важно учитывать - это совмещение High-poly и Low-poly. Они должны максимально совпадать по габаритам. Обычно это хорошо видно если присвоить моделям разные материалы, которые будут иметь разные цвета. Также это можно контролировать через режим Wireframe.

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

Baking

Запекать модель будем в Marmoset Toolbag, так как это удобная, современная и легкая для понимания программа. Суть запекания везде остается одинаковой. Чтобы получить текстурные карты, необходимо по-отдельности экспортировать Low-Poly и High-Poly. Подойдет формат obj, если вы пропекаете модель без ID Map. При экспорте, этот формат содержит только геометрию, один материал и один UV Set. Далее открываем Marmoset и создаем в нем Bake Project. В него помещаем свои объекты, там все подписано. Важно с самого начала следить за именами своих файлов, так как это поможет вам не запутаться. Также в Marmoset есть удобный функционал, который позволяет загружать модель одним файлом и автоматически распределять сразу по нужным Bake группам High-Poly и Low-Poly модели, но для этого вам потребуется уже FBX формат и правильный нейминг ваших моделей в Outliner вашего софта, в котором вы работаете.

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

Samples - определяет качество сглаживания текстур. Тут все просто - чем выше значение тем лучше (но не всегда нужно), и тем дольше может идти процесс запекания.

Soften - применяет “смягчающий” фильтр к текстурам. Это позволяет сделать более плавные переходы плоскостей и скрыть некоторые недостатки. Обычно хватает небольших значений от 0.05 до 0.1. Можно пробовать разные результаты и смотреть разницу исходя из конкретной ситуации.

Padding - определяет, насколько запеченное содержимое может выходить за границы UV элементов. Это необходимо, в частности, для правильной работы Mip-Mapping - изменения детализации текстуры при увеличении расстояния до нее от камеры. Обычно хватает стандартных значений.

Разрешение текстуры - собственно, разрешение финальных текстур. Всегда кратно двум и максимальное будет 8192х8192. Выбираем в зависимости от задач и потребностей. Частым вариантом является 2048х2048, его и возьмем.

Ещё необходимо указать путь для сохранения текстур.

Примечание: Marmoset не воспринимает кириллицу, поэтому все файлы и папки надо подписывать латиницей.

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

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

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

Пересечение объектов

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

Артефакты при пересечениях

Это происходит потому что пересекаются их Cage при бейке в одной Bake Group. Для того чтобы избежать этого, и получить равномерное запекание, применяется разнос элементов. Это можно сделать заранее в Maya, либо раздвинуть группы в Marmoset. В случае с Maya важно соблюсти совпадение Low-Poly и High-Poly. Мы раздвинем их в marmoset при помощи вкладки Transform, параметр Position.

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

Элементы модели раздвинуты 25_CGitems.ru_Запекание_текстур.png

Результат - чистое запекание без артефактов. Также над моделью была проведена работа при помощи инструмента Paint Skew и настройки Cage (Paint offset в Marmoset). Что это, мы детально разбирали в статье Average normal, так что не станем повторяться. Здесь был применен точно такой же принцип - увеличен Cage, чтобы спроецировать целиком выступающие элементы, и проведена настройка нормалей Cage.

Обратите внимание на пример - настройки Paint Skew отображаются только на одной половине элемента - той, что являлась исходником при применении Overlap. Изменения на ней копируются на зависимую половину. 27_CGitems.ru_Запекание_текстур.png

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

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

Мы узнали как можно улучшить свою High-Poly, если обращать внимание на фаски и скосы и применять парящую геометрию
Разобрали основы того, что такое UV развертка, для чего она нужна и почему важна при финальной подготовке Low-Poly под запекание
Поняли что такое Overlap, как его применять и для чего
Запомнили что всегда нужно настраивать Padding между UV шелами
Учли что существует такое понятие как Texel Density
Прошлись по базовым настройкам запекания и коснулись некоторых сложностей, которые могут возникнуть в процессе

Запекание это важный этап в работе над моделью для игры. И запечь её не так сложно, сложнее подготовить все к этому процессу. От качества подготовки зависит вся дальнейшая работа, так как запеченная модель, а тем более окрашенная, плохо поддается полноценному редактированию. По этой причине важно дотошно просматривать модель и UV развертку до финального запекания. Понимание того как это делается приходит с опытом и насмотренностью, как и на любом этапе создания модели. Всё с ходу, и за один раз учесть не выйдет, но чем внимательнее вы будете, тем большего числа проблем избежите. Это был очень простой пример запекания, и на деле у вас может быть в разы больше сложносоставных элементов, фаски на Low-Poly, огромные UV развертки с большим количеством Overlap. Наверняка вы рано или поздно столкнетесь с дорисовкой и монтажом готовых карт в Photoshop, чтобы сделать результат еще лучше. Но этот пример отлично показывает базовые принципы запекания, учитывая которые вы точно улучшите свой результат.

[~DETAIL_TEXT] => Baking, или запекание текстур - это процесс получения информации от high-poly модели и создание на ее основе текстурных карт, которые перенесут эту информацию на low-poly модель при помощи её UV развертки. Это часть процессов оптимизации моделей для игр, и она очень важна, так как это хороший способ сохранить внешний вид модели при меньшей нагрузке на движок во время рендера и на игровые компьютеры/девайсы игроков. Давайте разберемся с тем, как происходит этот процесс.

Подготовка к запеканию

Простая High-Poly модель 2_CGitems.ru_Запекание_текстур.png

Floaters. Парящая (летающая) геометрия

Еще пара моментов, на которых стоит заострить внимание:

Пример разного типа фасок 5_CGitems.ru_Запекание_текстур.png

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

На этом закончим с High-Poly, далее нам необходима Low-Poly модель, которая примет на себя информацию при запекании.

UV развертка

Пример того как можно разложить UV шелы коробки на UV пространстве

Overlap

Предположим, что у нас есть некий относительно крупный элемент имеющий отдельную low-poly с готовой разверткой.

Padding

Еще один важный момент, который стоит учитывать при создании UV, это padding (отступы).

Texel density. Разрешение UV пространства

Baking

Ещё необходимо указать путь для сохранения текстур.

Примечание: Marmoset не воспринимает кириллицу, поэтому все файлы и папки надо подписывать латиницей.

Пересечение объектов

Артефакты при пересечениях

Элементы модели раздвинуты 25_CGitems.ru_Запекание_текстур.png

Мы узнали как можно улучшить свою High-Poly, если обращать внимание на фаски и скосы и применять парящую геометрию
Разобрали основы того, что такое UV развертка, для чего она нужна и почему важна при финальной подготовке Low-Poly под запекание
Поняли что такое Overlap, как его применять и для чего
Запомнили что всегда нужно настраивать Padding между UV шелами
Учли что существует такое понятие как Texel Density
Прошлись по базовым настройкам запекания и коснулись некоторых сложностей, которые могут возникнуть в процессе

Подготовка к запеканию

Простая High-Poly модель 2_CGitems.ru_Запекание_текстур.png

Floaters. Парящая (летающая) геометрия

Еще пара моментов, на которых стоит заострить внимание:

Пример разного типа фасок 5_CGitems.ru_Запекание_текстур.png

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

На этом закончим с High-Poly, далее нам необходима Low-Poly модель, которая примет на себя информацию при запекании.

UV развертка

Пример того как можно разложить UV шелы коробки на UV пространстве

Overlap

Предположим, что у нас есть некий относительно крупный элемент имеющий отдельную low-poly с готовой разверткой.

Padding

Еще один важный момент, который стоит учитывать при создании UV, это padding (отступы).

Texel density. Разрешение UV пространства

Baking

Ещё необходимо указать путь для сохранения текстур.

Примечание: Marmoset не воспринимает кириллицу, поэтому все файлы и папки надо подписывать латиницей.

Пересечение объектов

Артефакты при пересечениях

Элементы модели раздвинуты 25_CGitems.ru_Запекание_текстур.png

Мы узнали как можно улучшить свою High-Poly, если обращать внимание на фаски и скосы и применять парящую геометрию
Разобрали основы того, что такое UV развертка, для чего она нужна и почему важна при финальной подготовке Low-Poly под запекание
Поняли что такое Overlap, как его применять и для чего
Запомнили что всегда нужно настраивать Padding между UV шелами
Учли что существует такое понятие как Texel Density
Прошлись по базовым настройкам запекания и коснулись некоторых сложностей, которые могут возникнуть в процессе

Запекание текстур. Baking Marmoset Toolbag, Документация
3728 просмотров

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

10 – бокс с 4 забевеленными эджами (гранями) по одной из осей.
18 – бокс со всеми забевеленными эджами.
26 – бокс со всеми забевеленными эджамии и углами.

Hull Count – общее количество примитивов.
Max Hull Vertex – общее количество вершин, которое будет иметь коллизия.
Hull Precision – коэффициент точности проекции коллизии.

Default – используются параметры выставленные в Static Mesh Editor.
Custom – задаются пользовательские параметры для инстанса.
NoCollision – нет коллизии.
BlockAll – статический объект блокирует по умолчанию все Actor.
OverlapAll – статический объект при пересечении задает overlap событие по умолчанию все Actor.
BlockAllDynamic – динамический объект блокирует по умолчанию все Actor.
OverlapAllDynamic – динамический объект при пересечении задает overlap событие по умолчанию все Actor.
IgnoreOnlyPawn – игнорируется только объект типа Pawn (например, персонаж игрока).
OverlapOnlyPawn – задает при пересечении overlap событие только объектом типа Pawn.
Pawn – сам объект типа Pawn, который может использовать капсульную коллизию.
Spectator – объект типа Pawn, который игнорирует все статические Actor.
CharacterMesh – объект типа Pawn, который используется для персонажа.
PhysicsActor – Actor с симуляцией.
Destructible – разрушаемый Actor.
InvisibleWall – статический невидимый объект.
InvisibleWallDynamic – динамический видимый объект.
Trigger – динамический объект, используемый как триггер.
Ragdoll – SkeletalMeshComponent с симуляцией.
Vehicle – блокирует другой транспорт, статические и динамические объекты.
UI – статический объект, который перекрывает все Actor.

Project Default – задаются параметры по настройкам проекта.
Simple and Complex – в зависимости от запросов в сцене может быть использована простая и сложная коллизия.
Use Simple Collision as Complex – используется только простая коллизия.
Use Complex Collision as Simple – используется только сложная коллизия.

NoCollision – тело коллизии не будет видно и как-либо использовано в пространстве или симуляции. Является лучшим вариантом для оптимизации.
Query Only – используется для пространственных запросов. Подходит для движения персонажей и объектов, которые не нуждаются в физической симуляции.
Physics Only – подходит для физической симуляции (скелетная анимация и ограничения). Полезно в работе с вторичной анимацией, где не нужно обнаружение костей.
Collision Enabled –может быть использовано как для пространственных запросов, так и при физической симуляции.

WorldStatic – используется для неподвижных объектов. Параметр хорошо подходит для объектов с одноименным типом (например: пак коробок или бочек).
WorldDynamic – используется для Actor, которые могут быть подвижны под влиянием анимации или кода (например: лифт, двери).
Pawn – объекты, контролируемые игроком (например: персонаж).
PhysicsBody – объект перемещаемый благодаря физической симуляции.
Vehicle – транспорту задается параметр по умолчанию.
Destructible – разрушаемому объекту задается параметр по умолчанию.

Ignore – любой объект будет проигнорирован.
Overlap – объект, при пересечении с которым может привести к заданному overlap событию, если события нет, он не отличается от игнора.
Block – объект будет заблокирован, произойдет столкновение.
Trace Responses – используется при трассировке лучей, например при использовании ноды Line Trace Channel в блюпринтах.
Visibility – тестирование общей видимости.
Camera – при использовании трассировки через камеру на что-либо.

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

10 – бокс с 4 забевеленными эджами (гранями) по одной из осей.
18 – бокс со всеми забевеленными эджами.
26 – бокс со всеми забевеленными эджамии и углами.

Hull Count – общее количество примитивов.
Max Hull Vertex – общее количество вершин, которое будет иметь коллизия.
Hull Precision – коэффициент точности проекции коллизии.

Default – используются параметры выставленные в Static Mesh Editor.
Custom – задаются пользовательские параметры для инстанса.
NoCollision – нет коллизии.
BlockAll – статический объект блокирует по умолчанию все Actor.
OverlapAll – статический объект при пересечении задает overlap событие по умолчанию все Actor.
BlockAllDynamic – динамический объект блокирует по умолчанию все Actor.
OverlapAllDynamic – динамический объект при пересечении задает overlap событие по умолчанию все Actor.
IgnoreOnlyPawn – игнорируется только объект типа Pawn (например, персонаж игрока).
OverlapOnlyPawn – задает при пересечении overlap событие только объектом типа Pawn.
Pawn – сам объект типа Pawn, который может использовать капсульную коллизию.
Spectator – объект типа Pawn, который игнорирует все статические Actor.
CharacterMesh – объект типа Pawn, который используется для персонажа.
PhysicsActor – Actor с симуляцией.
Destructible – разрушаемый Actor.
InvisibleWall – статический невидимый объект.
InvisibleWallDynamic – динамический видимый объект.
Trigger – динамический объект, используемый как триггер.
Ragdoll – SkeletalMeshComponent с симуляцией.
Vehicle – блокирует другой транспорт, статические и динамические объекты.
UI – статический объект, который перекрывает все Actor.

Project Default – задаются параметры по настройкам проекта.
Simple and Complex – в зависимости от запросов в сцене может быть использована простая и сложная коллизия.
Use Simple Collision as Complex – используется только простая коллизия.
Use Complex Collision as Simple – используется только сложная коллизия.

NoCollision – тело коллизии не будет видно и как-либо использовано в пространстве или симуляции. Является лучшим вариантом для оптимизации.
Query Only – используется для пространственных запросов. Подходит для движения персонажей и объектов, которые не нуждаются в физической симуляции.
Physics Only – подходит для физической симуляции (скелетная анимация и ограничения). Полезно в работе с вторичной анимацией, где не нужно обнаружение костей.
Collision Enabled –может быть использовано как для пространственных запросов, так и при физической симуляции.

WorldStatic – используется для неподвижных объектов. Параметр хорошо подходит для объектов с одноименным типом (например: пак коробок или бочек).
WorldDynamic – используется для Actor, которые могут быть подвижны под влиянием анимации или кода (например: лифт, двери).
Pawn – объекты, контролируемые игроком (например: персонаж).
PhysicsBody – объект перемещаемый благодаря физической симуляции.
Vehicle – транспорту задается параметр по умолчанию.
Destructible – разрушаемому объекту задается параметр по умолчанию.

Ignore – любой объект будет проигнорирован.
Overlap – объект, при пересечении с которым может привести к заданному overlap событию, если события нет, он не отличается от игнора.
Block – объект будет заблокирован, произойдет столкновение.
Trace Responses – используется при трассировке лучей, например при использовании ноды Line Trace Channel в блюпринтах.
Visibility – тестирование общей видимости.
Camera – при использовании трассировки через камеру на что-либо.

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

10 – бокс с 4 забевеленными эджами (гранями) по одной из осей.
18 – бокс со всеми забевеленными эджами.
26 – бокс со всеми забевеленными эджамии и углами.

Hull Count – общее количество примитивов.
Max Hull Vertex – общее количество вершин, которое будет иметь коллизия.
Hull Precision – коэффициент точности проекции коллизии.

Default – используются параметры выставленные в Static Mesh Editor.
Custom – задаются пользовательские параметры для инстанса.
NoCollision – нет коллизии.
BlockAll – статический объект блокирует по умолчанию все Actor.
OverlapAll – статический объект при пересечении задает overlap событие по умолчанию все Actor.
BlockAllDynamic – динамический объект блокирует по умолчанию все Actor.
OverlapAllDynamic – динамический объект при пересечении задает overlap событие по умолчанию все Actor.
IgnoreOnlyPawn – игнорируется только объект типа Pawn (например, персонаж игрока).
OverlapOnlyPawn – задает при пересечении overlap событие только объектом типа Pawn.
Pawn – сам объект типа Pawn, который может использовать капсульную коллизию.
Spectator – объект типа Pawn, который игнорирует все статические Actor.
CharacterMesh – объект типа Pawn, который используется для персонажа.
PhysicsActor – Actor с симуляцией.
Destructible – разрушаемый Actor.
InvisibleWall – статический невидимый объект.
InvisibleWallDynamic – динамический видимый объект.
Trigger – динамический объект, используемый как триггер.
Ragdoll – SkeletalMeshComponent с симуляцией.
Vehicle – блокирует другой транспорт, статические и динамические объекты.
UI – статический объект, который перекрывает все Actor.

Project Default – задаются параметры по настройкам проекта.
Simple and Complex – в зависимости от запросов в сцене может быть использована простая и сложная коллизия.
Use Simple Collision as Complex – используется только простая коллизия.
Use Complex Collision as Simple – используется только сложная коллизия.

NoCollision – тело коллизии не будет видно и как-либо использовано в пространстве или симуляции. Является лучшим вариантом для оптимизации.
Query Only – используется для пространственных запросов. Подходит для движения персонажей и объектов, которые не нуждаются в физической симуляции.
Physics Only – подходит для физической симуляции (скелетная анимация и ограничения). Полезно в работе с вторичной анимацией, где не нужно обнаружение костей.
Collision Enabled –может быть использовано как для пространственных запросов, так и при физической симуляции.

WorldStatic – используется для неподвижных объектов. Параметр хорошо подходит для объектов с одноименным типом (например: пак коробок или бочек).
WorldDynamic – используется для Actor, которые могут быть подвижны под влиянием анимации или кода (например: лифт, двери).
Pawn – объекты, контролируемые игроком (например: персонаж).
PhysicsBody – объект перемещаемый благодаря физической симуляции.
Vehicle – транспорту задается параметр по умолчанию.
Destructible – разрушаемому объекту задается параметр по умолчанию.

Ignore – любой объект будет проигнорирован.
Overlap – объект, при пересечении с которым может привести к заданному overlap событию, если события нет, он не отличается от игнора.
Block – объект будет заблокирован, произойдет столкновение.
Trace Responses – используется при трассировке лучей, например при использовании ноды Line Trace Channel в блюпринтах.
Visibility – тестирование общей видимости.
Camera – при использовании трассировки через камеру на что-либо.

Коллизия (Collision) Unreal Engine, Документация
2844 просмотров

Array ( [ID] => 363 [~ID] => 363 [CODE] => voxel-vokselnaya-grafika [~CODE] => voxel-vokselnaya-grafika [XML_ID] => 363 [~XML_ID] => 363 [NAME] => Voxel (воксельная графика) [~NAME] => Voxel (воксельная графика) [TAGS] => [~TAGS] => [SORT] => 500 [~SORT] => 500 [PREVIEW_TEXT] => Обзор технологии и ее применения в игровой индустрии [~PREVIEW_TEXT] => Обзор технологии и ее применения в игровой индустрии [PREVIEW_PICTURE] => Array ( [ID] => 3946 [TIMESTAMP_X] => 23.05.2023 22:45:23 [MODULE_ID] => iblock [HEIGHT] => 190 [WIDTH] => 320 [FILE_SIZE] => 101812 [CONTENT_TYPE] => image/png [SUBDIR] => iblock/bb8/a8k3myxmvdrpv5tjevfx83inzrrlgjxx [FILE_NAME] => Anons_Voxel.png [ORIGINAL_NAME] => Anons_Voxel.png [DESCRIPTION] => [HANDLER_ID] => [EXTERNAL_ID] => 619bde01abe23cd252b1b2be3be009d5 [VERSION_ORIGINAL_ID] => [META] => [SRC] => /upload/iblock/bb8/a8k3myxmvdrpv5tjevfx83inzrrlgjxx/Anons_Voxel.png [UNSAFE_SRC] => /upload/iblock/bb8/a8k3myxmvdrpv5tjevfx83inzrrlgjxx/Anons_Voxel.png [SAFE_SRC] => /upload/iblock/bb8/a8k3myxmvdrpv5tjevfx83inzrrlgjxx/Anons_Voxel.png [ALT] => Voxel (воксельная графика) [TITLE] => Voxel (воксельная графика) ) [~PREVIEW_PICTURE] => 3946 [DETAIL_TEXT] =>

Что такое воксельная графика

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

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

Также это сравнимо с растровой графикой, в которой построение конечного объекта происходит при помощи точек, содержащих в себе информацию о цвете - пикселей.

Пример того, как сильно отличается принцип построения полигональной и воксельной 3D моделей

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

История появления воксельной графики

В 1963 году американский физик Аллан Кормак повторно (но отличным от Радона способом) решил задачу томографического восстановления, а в 1969 году английский инженер-физик Годфри Хаунсфилд сконструировал «ЭМИ-сканер» - первый компьютерный рентгеновский томограф.

Вся их работа была направлена на то, чтобы добиться качественной визуализации человеческого тела и отдельных органов. Ряд медицинских устройств, например, КТ, УЗИ, МРТ, выдают изображения с большого количества рентгеновских и ультразвуковых снимков под разными углами. После они сканируются и, на их основе, создается трехмерный массив плотностей различных участков тканей исследуемого органа. Этот массив представляет собой объемное изображение элементом которого является воксель. CGITEMS_ voxel_2.png Рентгеновские лучи и ультразвук помогают получить информацию о плотности, прозрачности частиц, их положении и высотах. Математические алгоритмы на основе этих данных позволяют сформировать воксельную модель - массив «кирпичей» на основе которых происходит визуализация, например, человеческого мозга. По сути это «выращивание» 3D модели из 2D среза

Применение воксельной графики в играх, краткий разбор технологий

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

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

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

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

Начало применения воксельной графики в играх

Яркий пример первой (либо одной из первых популярных игр) это Comanche: Maximum Overkill, от студии NovaLogic, которая была выпущена в 1992 году.

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

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

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

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

В частности в Vangers миры были спроектированы студией K-D Lab с помощью собственного редактора ландшафта - Surmap ART, и сопутствующей технологии воксельно-полигонального моделирования.

Применение воксельной графики в современных играх

Нельзя просто взять и пройти мимо одного из самых крупных и известных проектов, основанных на воксельной графике и процедурной генерации - No man’s sky.

Она была разработана и выпущена британской инди-студией Hello Games в 2016 году. Не будем вдаваться в детали старта игры на релизе - она вызвала неоднозначную реакцию, но мы говорим о технологиях. А технологий там накручено щедро и со вкусом.

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

(сокращенная цитата с wikipedia).

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

Неплохо звучит, не так ли? Давайте на минуту задумаемся и сравним - с одной стороны был несколько смазанный запуск игры и несколько лет доводки, а с другой стороны очевидный скачок технологий всего за 30 лет.

В целях сравнения - скриншоты из No man’s sky и Comanche: Maximum Overkill. Комментарии, как говорится, излишни

Очень занятный пример, это игра Teardown 2020 года от студии Tuxedo Labs. Её фишка заключается в том, что здесь принцип воксельной графики использован по полной - полностью разрушаемые воксельные локации и большой простор для действий игрока.

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

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

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

Minecraft

Space Engineers

Какой из этого можно сделать вывод?

А казалось бы, хотел очередной красивенький домик нарисовать и лайков десяток собрать, да?

Обзор редакторов, позволяющих работать с воксельной графикой

3D Coat

Во-первых, стоит присмотреться к редактору под названием 3D-coat.

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

3D coat

MagicaVoxel

MagicaVoxel

Qubicle

Qubicle

Voxel Max

Суть та же, с одним отличием - этот редактор доступен только для iOS и поддерживает работу пером.

Voxel Max

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

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

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

[~DETAIL_TEXT] =>

Что такое воксельная графика

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

Пример того, как сильно отличается принцип построения полигональной и воксельной 3D моделей

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

История появления воксельной графики

В 1963 году американский физик Аллан Кормак повторно (но отличным от Радона способом) решил задачу томографического восстановления, а в 1969 году английский инженер-физик Годфри Хаунсфилд сконструировал «ЭМИ-сканер» - первый компьютерный рентгеновский томограф.

Вся их работа была направлена на то, чтобы добиться качественной визуализации человеческого тела и отдельных органов. Ряд медицинских устройств, например, КТ, УЗИ, МРТ, выдают изображения с большого количества рентгеновских и ультразвуковых снимков под разными углами. После они сканируются и, на их основе, создается трехмерный массив плотностей различных участков тканей исследуемого органа. Этот массив представляет собой объемное изображение элементом которого является воксель. CGITEMS_ voxel_2.png Рентгеновские лучи и ультразвук помогают получить информацию о плотности, прозрачности частиц, их положении и высотах. Математические алгоритмы на основе этих данных позволяют сформировать воксельную модель - массив «кирпичей» на основе которых происходит визуализация, например, человеческого мозга. По сути это «выращивание» 3D модели из 2D среза

Применение воксельной графики в играх, краткий разбор технологий

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

Начало применения воксельной графики в играх

Яркий пример первой (либо одной из первых популярных игр) это Comanche: Maximum Overkill, от студии NovaLogic, которая была выпущена в 1992 году.

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

Применение воксельной графики в современных играх

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

(сокращенная цитата с wikipedia).

В целях сравнения - скриншоты из No man’s sky и Comanche: Maximum Overkill. Комментарии, как говорится, излишни

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

Minecraft

Space Engineers

Какой из этого можно сделать вывод?

А казалось бы, хотел очередной красивенький домик нарисовать и лайков десяток собрать, да?

Обзор редакторов, позволяющих работать с воксельной графикой

3D Coat

Во-первых, стоит присмотреться к редактору под названием 3D-coat.

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

3D coat

MagicaVoxel

Qubicle

Voxel Max

Суть та же, с одним отличием - этот редактор доступен только для iOS и поддерживает работу пером.

Voxel Max

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

Что такое воксельная графика

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

Пример того, как сильно отличается принцип построения полигональной и воксельной 3D моделей

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

История появления воксельной графики

В 1963 году американский физик Аллан Кормак повторно (но отличным от Радона способом) решил задачу томографического восстановления, а в 1969 году английский инженер-физик Годфри Хаунсфилд сконструировал «ЭМИ-сканер» - первый компьютерный рентгеновский томограф.

Вся их работа была направлена на то, чтобы добиться качественной визуализации человеческого тела и отдельных органов. Ряд медицинских устройств, например, КТ, УЗИ, МРТ, выдают изображения с большого количества рентгеновских и ультразвуковых снимков под разными углами. После они сканируются и, на их основе, создается трехмерный массив плотностей различных участков тканей исследуемого органа. Этот массив представляет собой объемное изображение элементом которого является воксель. CGITEMS_ voxel_2.png Рентгеновские лучи и ультразвук помогают получить информацию о плотности, прозрачности частиц, их положении и высотах. Математические алгоритмы на основе этих данных позволяют сформировать воксельную модель - массив «кирпичей» на основе которых происходит визуализация, например, человеческого мозга. По сути это «выращивание» 3D модели из 2D среза

Применение воксельной графики в играх, краткий разбор технологий

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

Начало применения воксельной графики в играх

Яркий пример первой (либо одной из первых популярных игр) это Comanche: Maximum Overkill, от студии NovaLogic, которая была выпущена в 1992 году.

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

Применение воксельной графики в современных играх

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

(сокращенная цитата с wikipedia).

В целях сравнения - скриншоты из No man’s sky и Comanche: Maximum Overkill. Комментарии, как говорится, излишни

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

Minecraft

Space Engineers

Какой из этого можно сделать вывод?

А казалось бы, хотел очередной красивенький домик нарисовать и лайков десяток собрать, да?

Обзор редакторов, позволяющих работать с воксельной графикой

3D Coat

Во-первых, стоит присмотреться к редактору под названием 3D-coat.

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

3D coat

MagicaVoxel

Qubicle

Voxel Max

Суть та же, с одним отличием - этот редактор доступен только для iOS и поддерживает работу пером.

Voxel Max

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

Voxel (воксельная графика) Документация
2529 просмотров

Взаимодействие между объектами в играх. Коллизия

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

Что такое коллизия?

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

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

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

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

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

Если брать игровую индустрию, то там эти понятия (коллизия и коллайдер) работают несколько по разному, но по сути взаимосвязаны и отвечают за одно и тоже - столкновение с объектом. Возьмем за пример движки Unity и Unreal Engine - в них за одну и ту же функцию отвечают разные параметры. В Unity это вкладка Physics с вариантами коллайдеров (box collider, sphere collider и.т.д.) и дальнейшее присвоение свойств твердости, реакций на столкновение и.т.д. В Unreal это настройки Collision в Mesh Editor и также дальнейшая более гибкая настройка под конкретные задачи. Если кратко, то коллизия это более комплексный инструмент включающий в себя, в том числе, возможности коллайдера. Её суть в том, что она, в отличии от коллайдера, может считывать скорость воздействия, точки соприкосновения с объектом и реагировать на них (запускать события), если это предусмотрено игровым процессом (например вы наступили на плиту и она засветилась). Коллайдер имеет более базовые функции, о которых говорилось выше - задает границы объекта для проверки столкновения и является оболочкой коллизии, задает её границы. В игре, например, стена с коллайдером не позволит игроку пройти сквозь неё, так как движок определит в этом месте столкновение, но это будет его единственной функцией, если не добавить дополнительные параметры.

Пример создания коллизий в Unity и Unreal Engine (Mesh Editor)

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

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

Коллизии в играх

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

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

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

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

Коллизии и производительность. Динамика и статика

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

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

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

Пример расположения коробок после какого-то события в игровом процессе

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

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

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

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

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

В первом случае персонаж провалился в стену, во втором - условно говоря упёрся в неё в какой то момент.

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

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

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

Хитбоксы. Стрельба и регистрация попаданий

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

Хитбоксы персонажей из игры Team fortress 2

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

Первый способ

Это Hitscan. Его суть заключается в просчете попаданий через трассировку лучей.

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

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

Второй способ

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

Обратите внимание на то, что пуля имеет коллизию

Всё точно также, как в примерах с ящиками - движок будет использовать для расчета упрощенные оболочки, все остальное сделает видеокарта. Берется направление оружия игрока и в момент выстрела образуется коллизия, которая движется в заданном направлении с определенной начальной скоростью. В полете она будет подвержена физике, то есть будет иметь траекторию, а в некоторых играх даже подвергаться воздействию, например, ветра. Такой тип стрельбы будет более реалистичным и сложным, в том числе для просчета во время рендера кадра. Один из ярких примеров работы с такой системой расчета стрельбы, это игра Max Payne от студии Remedy Entertainment - благодаря работе с коллизиями разработчики смогли реализовать такую механику как Bullet-Time, или замедление времени.

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

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

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

Коллизии для объектов игрового окружения

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

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

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

Меню в Mesh Editor для создания коллизии в Unreal Engine

Sphere, Capsule, Box Simplified Collision

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

По умолчанию модель с Quixel имеет присвоенную коллизию, её можно удалить при помощи пункта Remove. Это можно сделать на любом объекте. 17_Что такое коллизия_cgitems.ru.png

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

Сфера не лучший пример, так как не особо поддается редактированию, но тем не менее мы сдвинули и уменьшили её для наглядности. Лучше всего редактирование показывает себя на коллизиях созданных вручную, мы коснемся их чуть позже. 19_Что такое коллизия_cgitems.ru.png

Второй пункт это капсула - довольно занятный и универсальный вид коллизии, который хорошо подходит для отдельных элементов

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

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

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

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

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

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

Custom collision

Самый простой и правильный способ сделать коллизию вручную, это воспользоваться 3D редактором, в нашем случае это будет Maya

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

Коллизия, которая близко повторяет форму нашего объекта

Наименование Custom коллизий

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

Официальная документация на сайте Unreal Engine рекомендует следующие варианты:

UBX_name object - для бокса
UCP_name object - для капсулы
USP_name object - для сферы
UCX_name object - сложная форма

В данный момент нас интересует UCX. Если имя самой бочки будет “SM_Barrel”, то имя коллизии будет “UCX_SM_Barrel”. А сама коллизия должна быть присвоена объекту бочки, чтобы они экспортировались вместе. Также важным условием является то, что их пивоты должны совпадать и находиться в центре координат.

Именование ассета и коллизии к нему для движка Unreal Engine 25_Что такое коллизия_cgitems.ru.png

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

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

Теперь, когда все готово и проверено - можно загрузить новый объект в движок Unreal Engine и проверить результат.

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

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

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

Настройка коллизий

За настройки коллизии в Unreal Editor отвечает раздел Collision в Mesh editor.

Давайте пройдемся по пунктам.

Primitives - выпадающем меню можно посмотреть сколько и каких примитивов содержит ваша коллизия.
Double sided geometry - он отвечает за включение и отключение просчета двух сторон на объекте. Обычно это относится к плоскостям, либо объектам с одной стороной и используется, если проверка столкновений необходима с двух сторон объекта.
Simple collision Physical Material - позволяет задать коллизии физические свойства какого-то конкретного материала - плотность, сила трения и прочие. Проще говоря помогает симулировать на объекте более конкретное поведение при столкновениях.
Collision presets - довольно обширный раздел, он содержит в себе пресеты настроек для взаимодействия объекта. Во первых он позволяет дать понять движку активна ли на объекте коллизия, во вторых - какую функцию она выполняет. Этот раздел охватывает по сути все, начиная с обычной и скучной стены и заканчивая теми самыми светящимися платформами, разрушаемыми стенами, разлетающимися коробками и.т.д. Если вы раскроете этот раздел, то вас встретит следующее: Это тонкая настройка реакций объекта на окружающее пространство и другие объекты. В случае бочки из примера ей задан пресет BlockAll, ниже видно что его коллизия активна (Collision enabled), еще ниже его тип - WorldStatic. Это означает что бочка является статичным элементом который будет блокировать все остальные объекты, все реакции бочки переведены в режим Block. Помните пример с катушкой и взрывом ранее? Она осталась стоять на месте именно потому, что у неё выставлены такие настройки - статичный блокирующий объект.
На деле это обширная тема требующая отдельного разговора и можно сказать, что художнику по окружению не обязательно знать досконально все эти настройки, так как многие из них имеют отношение к другим направлениям производства игр и требуют немало дополнительных знаний. Обычно вам просто скажут, какие настройки необходимо задавать объектам над которыми вы работаете, либо это будет указано в рабочей документации. C полным списком пресетов можно ознакомиться в документации к движку. Кто знает, может именно с них начнутся ваши эксперименты с “оживлением” ваших объектов в игровых уровнях.
Collision Complexity - этот раздел отвечает за сложность коллизий. Их есть два вида. Первый - Simple Collision, это простая коллизия, вроде куба, капсулы или цилиндра который мы сделали ранее. Complex Collision - это, соответственно, сложная коллизия, которая точно повторяет формы объекта. Лучше всего покажет разницу изображение из документаций Unreal Engine. Один и тот же стул имеет простую коллизию (слева) и сложную (справа). В первом случае персонаж соскальзывает с него, во втором - остается на стуле, так как его коллизия позволяет точно понять поверхность и отработать взаимодействие. Как видите, все просто.
- Project default - стандартная настройка, если она включена, то в расчетах будут применяться настройки проекта.
- Simple and Complex - будут учитываться оба типа коллизий в сцене.
- Use Simple Collision as Complex - эта настройка позволяет при любом типе коллизий игнорировать сложные. Все расчеты будут проводиться как простые, что позволит сэкономить производительность.
- Use Complex Collision as Simple - эта настройка противоположна предыдущей, и наоборот любую коллизию будет считать как сложную, то есть - детально учитывать её форму.
Как вы уже наверное догадались - эти параметры имеют отношение к оптимизации и производительности. Обычно выбор параметров коллизии будет определяться назначением объекта. Можно предположить, что в большинстве случаев объекты вроде бочки будут иметь настройку Use Simple Collision as Complex, так как они не требуют сложных расчетов, поэтому нет смысла нагружать движок. Но это не означает, что саму коллизию можно делать как вздумается.
Customized collision - здесь все просто, если вы загрузили свою коллизию вместе с объектом, то проставленная галка укажет движку что необходимо применить именно её.
Complex collision mesh - в этом разделе вы можете подключить к модели сложную коллизию из отдельного объекта.
Walkable Slope Override - это последний пункт из списка. Он позволяет настроить “проходимость” объекта, то есть то, может ли персонаж пройти по нему. Этот параметр задается углом. Если по умолчанию в проекте угол прохода задан 45, то если мы зададим в этой настройке, допустим, 50 - персонаж не сможет пойти по этой поверхности и соскользнет. Наверняка вам встречалась ситуация в играх, когда визуально некий откос выглядит проходимым, но персонаж по нему скользит вниз - именно так работает этот параметр.

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

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

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

[~DETAIL_TEXT] =>

Взаимодействие между объектами в играх. Коллизия

Что такое коллизия?

Пример создания коллизий в Unity и Unreal Engine (Mesh Editor)

Коллизии в играх

Коллизии и производительность. Динамика и статика

Пример расположения коробок после какого-то события в игровом процессе

В первом случае персонаж провалился в стену, во втором - условно говоря упёрся в неё в какой то момент.

Хитбоксы. Стрельба и регистрация попаданий

Хитбоксы персонажей из игры Team fortress 2

Первый способ

Это Hitscan. Его суть заключается в просчете попаданий через трассировку лучей.

Второй способ

Обратите внимание на то, что пуля имеет коллизию

Коллизии для объектов игрового окружения

Меню в Mesh Editor для создания коллизии в Unreal Engine

Sphere, Capsule, Box Simplified Collision

Custom collision

Коллизия, которая близко повторяет форму нашего объекта

Наименование Custom коллизий

Официальная документация на сайте Unreal Engine рекомендует следующие варианты:

UBX_name object - для бокса
UCP_name object - для капсулы
USP_name object - для сферы
UCX_name object - сложная форма

Именование ассета и коллизии к нему для движка Unreal Engine 25_Что такое коллизия_cgitems.ru.png

Теперь, когда все готово и проверено - можно загрузить новый объект в движок Unreal Engine и проверить результат.

Настройка коллизий

За настройки коллизии в Unreal Editor отвечает раздел Collision в Mesh editor.

Давайте пройдемся по пунктам.

Primitives - выпадающем меню можно посмотреть сколько и каких примитивов содержит ваша коллизия.
Double sided geometry - он отвечает за включение и отключение просчета двух сторон на объекте. Обычно это относится к плоскостям, либо объектам с одной стороной и используется, если проверка столкновений необходима с двух сторон объекта.
Simple collision Physical Material - позволяет задать коллизии физические свойства какого-то конкретного материала - плотность, сила трения и прочие. Проще говоря помогает симулировать на объекте более конкретное поведение при столкновениях.
Collision presets - довольно обширный раздел, он содержит в себе пресеты настроек для взаимодействия объекта. Во первых он позволяет дать понять движку активна ли на объекте коллизия, во вторых - какую функцию она выполняет. Этот раздел охватывает по сути все, начиная с обычной и скучной стены и заканчивая теми самыми светящимися платформами, разрушаемыми стенами, разлетающимися коробками и.т.д. Если вы раскроете этот раздел, то вас встретит следующее: Это тонкая настройка реакций объекта на окружающее пространство и другие объекты. В случае бочки из примера ей задан пресет BlockAll, ниже видно что его коллизия активна (Collision enabled), еще ниже его тип - WorldStatic. Это означает что бочка является статичным элементом который будет блокировать все остальные объекты, все реакции бочки переведены в режим Block. Помните пример с катушкой и взрывом ранее? Она осталась стоять на месте именно потому, что у неё выставлены такие настройки - статичный блокирующий объект.
На деле это обширная тема требующая отдельного разговора и можно сказать, что художнику по окружению не обязательно знать досконально все эти настройки, так как многие из них имеют отношение к другим направлениям производства игр и требуют немало дополнительных знаний. Обычно вам просто скажут, какие настройки необходимо задавать объектам над которыми вы работаете, либо это будет указано в рабочей документации. C полным списком пресетов можно ознакомиться в документации к движку. Кто знает, может именно с них начнутся ваши эксперименты с “оживлением” ваших объектов в игровых уровнях.
Collision Complexity - этот раздел отвечает за сложность коллизий. Их есть два вида. Первый - Simple Collision, это простая коллизия, вроде куба, капсулы или цилиндра который мы сделали ранее. Complex Collision - это, соответственно, сложная коллизия, которая точно повторяет формы объекта. Лучше всего покажет разницу изображение из документаций Unreal Engine. Один и тот же стул имеет простую коллизию (слева) и сложную (справа). В первом случае персонаж соскальзывает с него, во втором - остается на стуле, так как его коллизия позволяет точно понять поверхность и отработать взаимодействие. Как видите, все просто.
- Project default - стандартная настройка, если она включена, то в расчетах будут применяться настройки проекта.
- Simple and Complex - будут учитываться оба типа коллизий в сцене.
- Use Simple Collision as Complex - эта настройка позволяет при любом типе коллизий игнорировать сложные. Все расчеты будут проводиться как простые, что позволит сэкономить производительность.
- Use Complex Collision as Simple - эта настройка противоположна предыдущей, и наоборот любую коллизию будет считать как сложную, то есть - детально учитывать её форму.
Как вы уже наверное догадались - эти параметры имеют отношение к оптимизации и производительности. Обычно выбор параметров коллизии будет определяться назначением объекта. Можно предположить, что в большинстве случаев объекты вроде бочки будут иметь настройку Use Simple Collision as Complex, так как они не требуют сложных расчетов, поэтому нет смысла нагружать движок. Но это не означает, что саму коллизию можно делать как вздумается.
Customized collision - здесь все просто, если вы загрузили свою коллизию вместе с объектом, то проставленная галка укажет движку что необходимо применить именно её.
Complex collision mesh - в этом разделе вы можете подключить к модели сложную коллизию из отдельного объекта.
Walkable Slope Override - это последний пункт из списка. Он позволяет настроить “проходимость” объекта, то есть то, может ли персонаж пройти по нему. Этот параметр задается углом. Если по умолчанию в проекте угол прохода задан 45, то если мы зададим в этой настройке, допустим, 50 - персонаж не сможет пойти по этой поверхности и соскользнет. Наверняка вам встречалась ситуация в играх, когда визуально некий откос выглядит проходимым, но персонаж по нему скользит вниз - именно так работает этот параметр.

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

Взаимодействие между объектами в играх. Коллизия

Что такое коллизия?

Пример создания коллизий в Unity и Unreal Engine (Mesh Editor)

Коллизии в играх

Коллизии и производительность. Динамика и статика

Пример расположения коробок после какого-то события в игровом процессе

В первом случае персонаж провалился в стену, во втором - условно говоря упёрся в неё в какой то момент.

Хитбоксы. Стрельба и регистрация попаданий

Хитбоксы персонажей из игры Team fortress 2

Первый способ

Это Hitscan. Его суть заключается в просчете попаданий через трассировку лучей.

Второй способ

Обратите внимание на то, что пуля имеет коллизию

Коллизии для объектов игрового окружения

Меню в Mesh Editor для создания коллизии в Unreal Engine

Sphere, Capsule, Box Simplified Collision

Custom collision

Коллизия, которая близко повторяет форму нашего объекта

Наименование Custom коллизий

Официальная документация на сайте Unreal Engine рекомендует следующие варианты:

UBX_name object - для бокса
UCP_name object - для капсулы
USP_name object - для сферы
UCX_name object - сложная форма

Именование ассета и коллизии к нему для движка Unreal Engine 25_Что такое коллизия_cgitems.ru.png

Теперь, когда все готово и проверено - можно загрузить новый объект в движок Unreal Engine и проверить результат.

Настройка коллизий

За настройки коллизии в Unreal Editor отвечает раздел Collision в Mesh editor.

Давайте пройдемся по пунктам.

Primitives - выпадающем меню можно посмотреть сколько и каких примитивов содержит ваша коллизия.
Double sided geometry - он отвечает за включение и отключение просчета двух сторон на объекте. Обычно это относится к плоскостям, либо объектам с одной стороной и используется, если проверка столкновений необходима с двух сторон объекта.
Simple collision Physical Material - позволяет задать коллизии физические свойства какого-то конкретного материала - плотность, сила трения и прочие. Проще говоря помогает симулировать на объекте более конкретное поведение при столкновениях.
Collision presets - довольно обширный раздел, он содержит в себе пресеты настроек для взаимодействия объекта. Во первых он позволяет дать понять движку активна ли на объекте коллизия, во вторых - какую функцию она выполняет. Этот раздел охватывает по сути все, начиная с обычной и скучной стены и заканчивая теми самыми светящимися платформами, разрушаемыми стенами, разлетающимися коробками и.т.д. Если вы раскроете этот раздел, то вас встретит следующее: Это тонкая настройка реакций объекта на окружающее пространство и другие объекты. В случае бочки из примера ей задан пресет BlockAll, ниже видно что его коллизия активна (Collision enabled), еще ниже его тип - WorldStatic. Это означает что бочка является статичным элементом который будет блокировать все остальные объекты, все реакции бочки переведены в режим Block. Помните пример с катушкой и взрывом ранее? Она осталась стоять на месте именно потому, что у неё выставлены такие настройки - статичный блокирующий объект.
На деле это обширная тема требующая отдельного разговора и можно сказать, что художнику по окружению не обязательно знать досконально все эти настройки, так как многие из них имеют отношение к другим направлениям производства игр и требуют немало дополнительных знаний. Обычно вам просто скажут, какие настройки необходимо задавать объектам над которыми вы работаете, либо это будет указано в рабочей документации. C полным списком пресетов можно ознакомиться в документации к движку. Кто знает, может именно с них начнутся ваши эксперименты с “оживлением” ваших объектов в игровых уровнях.
Collision Complexity - этот раздел отвечает за сложность коллизий. Их есть два вида. Первый - Simple Collision, это простая коллизия, вроде куба, капсулы или цилиндра который мы сделали ранее. Complex Collision - это, соответственно, сложная коллизия, которая точно повторяет формы объекта. Лучше всего покажет разницу изображение из документаций Unreal Engine. Один и тот же стул имеет простую коллизию (слева) и сложную (справа). В первом случае персонаж соскальзывает с него, во втором - остается на стуле, так как его коллизия позволяет точно понять поверхность и отработать взаимодействие. Как видите, все просто.
- Project default - стандартная настройка, если она включена, то в расчетах будут применяться настройки проекта.
- Simple and Complex - будут учитываться оба типа коллизий в сцене.
- Use Simple Collision as Complex - эта настройка позволяет при любом типе коллизий игнорировать сложные. Все расчеты будут проводиться как простые, что позволит сэкономить производительность.
- Use Complex Collision as Simple - эта настройка противоположна предыдущей, и наоборот любую коллизию будет считать как сложную, то есть - детально учитывать её форму.
Как вы уже наверное догадались - эти параметры имеют отношение к оптимизации и производительности. Обычно выбор параметров коллизии будет определяться назначением объекта. Можно предположить, что в большинстве случаев объекты вроде бочки будут иметь настройку Use Simple Collision as Complex, так как они не требуют сложных расчетов, поэтому нет смысла нагружать движок. Но это не означает, что саму коллизию можно делать как вздумается.
Customized collision - здесь все просто, если вы загрузили свою коллизию вместе с объектом, то проставленная галка укажет движку что необходимо применить именно её.
Complex collision mesh - в этом разделе вы можете подключить к модели сложную коллизию из отдельного объекта.
Walkable Slope Override - это последний пункт из списка. Он позволяет настроить “проходимость” объекта, то есть то, может ли персонаж пройти по нему. Этот параметр задается углом. Если по умолчанию в проекте угол прохода задан 45, то если мы зададим в этой настройке, допустим, 50 - персонаж не сможет пойти по этой поверхности и соскользнет. Наверняка вам встречалась ситуация в играх, когда визуально некий откос выглядит проходимым, но персонаж по нему скользит вниз - именно так работает этот параметр.

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

Collision. Столкновение игрока с объектами в играх. Что такое коллизия? Unreal Engine, Unity, Документация