Имитация трёхмерных зданий в 2D-игре — опыт разработчиков Norland
Создаём объём при помощи света и теней.
Всем привет! Мы небольшой командой уже несколько лет разрабатываем 2D стратегию Norland — симулятор средневекового королевства.
Недавно мы вышли в свет с анонсом и трейлером, но на русскоязычных просторах довольно мало рассказывали про проект.
Поэтому я решил начать сразу с технической статьи : ) Итоговый результат на гифке, а заинтересованных прошу под кат.
Игра двухмерная, разрабатывается на Game Maker Studio 2 и во время работы я столкнулся с множеством задач а-ля «должно быть красиво». Где-то пришлось придумать свой велосипед, где-то повезло наткнуться на описание решения похожих задач. Но, в целом, в интернете довольно мало информации о реализации всяких 2D украшательств, поэтому моя статья будет нелишней.
Тени
Для того, чтобы сделать «трехмерные» тени для 2д здания, нужно сперва разметить это здание какими-то примитивами – кубами, цилиндрами, призмами и т.д. Но эти примитивы не будут «отбрасывать тень» в привычном понимании этого слова – они сами будут тенями.
Рассмотрим, к примеру, куб (так-то это параллелепипед, но слово куб короче). Он состоит из восьми вершин. В х-компоненту нормали каждой вершины записывается 0.0, если это основание и 1.0, если это верхняя часть куба. В текстурные координаты в x-компоненту записывается высота фигуры, которая будет отбрасывать тень.
Вся остальная работа происходит в вертексном шейдере. В него передаются параметры солнца (угол над горизонтом и длина теней). Дальше элементарно – вершины, у которых normal.x равно единице, сдвигаются на указанное расстояние на нужный угол, а остальные вершины остаются на месте.
Все преобразования будут считаться афинными, т.к. параллельные грани куба останутся параллельными после преобразований.
Упрощенный вид вершинного шейдера (GLSL):
Подобным образом создаются и другие примитивы – цилиндр и призмы для крыш двух видов (горизонтальная и вертикальная). Результат:
В итоге куб будет состоять из 8 вертексов и 10 треугольников (2 треугольника из основания куба можно выбросить – они ни на что не влияют).
Чтобы тени по итогу были полупрозрачными, но при этом в местах соприкосновения теней, не было наслоения, нужно отрисовать все тени с альфой равно единице на поверхность (surface). А уже поверхность рисовать с нужной альфой. Также поверхность можно размыть шейдером gaussian blur, чтобы сгладить несовершенство полигональных теней.
Z-сортировка и карта высот
Наша игра двухмерна (за исключением лопастей мельницы – использовать спрайтовую анимацию в этом случае было бы крайне сложно из-за больших размеров каждого кадра, поэтому пришлось использовать 3d модель), но персонажи должны иметь возможность оказываться как перед зданиями, так и за ними. В простых случаях это решается как-то так:
Однако нам нужно, чтобы персонаж корректно отображался еще и внутри здания – а ведь в нем может быть много объектов.
В этом нам поможет автоматическая сортировка на GPU с помощью Z-Buffer.
Для тех, кто не в курсе – Z-Buffer, это такая структура данных, в которой описывается глубина каждого пикселя числом от 0 до 1. Если подставить вместо чисел цвет, то получится черно-белая картинка.
В GMS 2 с буфером глубины можно работать с некоторыми ограничениями – его нельзя получить в виде текстуры, его нельзя считывать и модифицировать в шейдерах (по умолчанию так, но есть пути обхода). Но зато все еще можно просто использовать Z-сортировку! А это то, что нам нужно.
Z-сортировка позволяет отбрасывать пиксели, которые имеют бОльшую глубину (это поведение по умолчанию, но его можно поменять), чем те, которые уже нарисованы на экран (и в Z-Buffer соответственно).
Т.е. если нарисовать здание по кускам, указав каждому куску его глубину, а потом нарисовать персонажа (с глубиной равной -y), то с помощью Z-сортировки, те пиксели персонажа, которые находятся за условным столом, просто не будут рисоваться и получится так, что персонаж будет корректно перекрываться этим столом.
Но для этого нужно разметить здание. Поверх спрайта, я расставляю квады, у которых можно настроить, будет ли этот квад вертикальной стенкой (в этом случае верхние вершины квада будут иметь ту же глубину, что и нижние вершины) или горизонтальной поверхностью (верхние и нижние вершины квада будут иметь разную глубину, в зависимости от их позиции по оси y).
На скриншоте стенки отображаются как заполненные оранжевые прямоугольники, а поверхности как пустые белые прямоугольники. У квада также можно указать высоту над землей, но это уже нюансы.
Потом эти размеченные квады преобразуются в полигоны и записываются в вершинный буфер ассета. Помимо Z-уровня, вершины несут с собой информацию о UV-координатах текстуры здания (а также UV текстуры карты светящихся ночью окон, нормалей и другие вспомогательные параметры для всяких эффектов).
Минус этого подхода очевиден для тех, кто уже работал с Z-Buffer. Ведь он не поддерживает полупрозрачность. Т.е. если в буфер сперва было нарисовано полупрозрачное стекло, то потом, если мы попытаемся нарисовать что-то за этим стеклом, у нас ничего не получится, ведь стекло ближе, чем новые рисуемые пиксели. Чтобы обойти этот момент, нужно сперва отсортировать на CPU рисуемые ассеты от дальнего к ближнему и только потом рисовать их на экран (и в буфер). Но мы подошли к этому проще – в наших зданиях нет полупрозрачных элементов : )
Помимо Z-Quads (так я назвал эти полигоны для указания Z-уровня), важной частью разметки ассета, являются H-Quads (квады высоты). Эти квады нужны чтобы добавить в здания перепады высот (см. ступеньки и помост кафедры в храме, например). Тут все просто — прямоугольник с указанием высоты. Потом в рантайме находим пересечение нижней точки персонажа с H-Quad под ним и перемещаем персонажа на указанную высоту вверх или вниз.
Карты нормалей и окон
Есть такая технология Normal mapping. Если по простому, то это текстура, в которой в r, g, b-каналы каждого пикселя записываются x, y, z-компоненты вектора нормали для этого пикселя. Т.е. «куда направлен» этот пиксель относительно мировой системы координат.
Из-за особенностей записи вектора в rgb эквиваленте, на выходе обычно получается фиолетово-красно-зеленая карта. И если передать ее в нехитрый шейдер, то двигая виртуальную лампочку со светом, можно на 2D спрайте изобразить игру теней. А это то, что нам нужно.
Осталось понять, где взять эту карту нормалей. С 3D моделью все просто — современные пакеты трехмерного моделирования позволяют сгенерировать нормаль мапу в четыре клика, ведь для этого у модели есть вся необходимая информация.
С 2D спрайтом все иначе — это просто картинка. И только смотрящий на нее человек (и наверное современные нейросети) может определить, что вот это вот скат крыши, а вот это подоконник.
Но выход есть. Для ручного или полу-автоматического (с ожидаемым средне-плохим результатом) создания карт нормалей из 2D изображений существует какое-то количество софта. Например SpriteLamp, SpriteIlluminator, Laigter, Плагины для Gimp и т.п. Можно даже написать свою небольшую софтину с одним инструментом-кисточкой и трекболом указания требуемого угла рисуемой нормали.
Чтобы обрисовать в подобной программе несложное здание, не нужно много усилий. Вот здесь вертикальная стенка, вот здесь крыша, а здесь выступающая часть, которая может подсвечиваться более интенсивно. Зачастую хватает нескольких цветов. Можно быть не супер точным в этом деле, т.к. мы храним карту нормалей в 0.25x размере от спрайта здания, так что недостатки скроются интерполяцией.
Упрощенный вертексный шейдер GLSL:
Помимо карты нормалей используется также карта окон. При наступлении сумерек, пиксели рисуемого здания, которые соответствуют белым пикселям карты окон, должны получить оранжевый цвет.
Разумеется это не все эффекты, которые мы используем в своем рендере. На гифке из начала статьи еще есть свет вокруг окон, LUT-цветокоррекция для имитации смены времени суток (для реализации подобной штуки, могу посоветовать вот эту статью), частицы дыма из труб и т.д. А если приблизить камеру к зданию, то крыша будет сниматься с эффектом dissolve. Но это уже совсем другая история.
Внимательные читатели могли заметить, что тень не совсем совпадает (точнее совсем не совпадает) с освещением здания от карты нормалей. Мол, тень снизу, значит свет падает на заднюю, не видимую игроку, стену здания. Но при этом все равно освещается фасад.
Если бы тень от здания была сверху (т.е. солнце освещало фасад), то этого казуса можно было бы избежать, но я намеренно поместил тень именно снизу, т.к. так просто-напросто красивее. Особенно в полдень.
Надеюсь, статья сможет кому-нибудь помочь, ведь 2D игры умирать пока не собираются, а красивости все любят.
Если вас заинтересовал проект, то можете найти его в стиме (в начале статьи есть ссылка) и добавить в вишлист. Спасибо!
Game Maker Studio 2Выглядит красиво, желаю удачи с разработкой!
Спасибо!
Очень круто выглядит, ну вы молодцы что сказать! Единственное что я бы поправил свет из окна конкретно в первой гифке. Уж больно он не реалистично выглядит. А так все афигенно!
Спасибо, да, есть пути улучшения света. Можно добавить немного "лучей бога" или частицы пыли, которые подсвечиваются светом из окна. Возможно, что в будущем я вернусь и доработаю некоторые эффекты. Но пока есть куча другой работы по геймплею, что более приоритетно.
Но даже с таким светом получаются довольно ламповые пейзажи по ночам, особенно при отдалении камеры )
Получается для имитации 3д зданий в 2д игре нужны де факто 3д здания (информацию о направлении поверхностей и объемах по сути берется из 3д пайплайна)
Возможно оправданно было бы тогда просто брать 3д рефы как основу, их оставлять как источник теней и нормалей, а 2д обрисовывать поверх.
Да, по факту так оно и есть.
Проще всего вообще было бы использовать чистое 3D. Но тут и движок, по хорошему, другой нужен (В GMS работа с 3D отдается полностью на откуп разработчику - из коробки можно лишь грузить модели в буфер и менять матрицу трансформации при отрисовке), да и сам визуальный стиль поменяется.
Но по итогу расклад такой - на руках красивые домики, но полностью в 2D. А хочется сделать "трехмерные" тени и другие красивости. И с этого начинается путь самурая в различные технические ухищрения : )
Комментарий недоступен