Динамические декали это что
Этапные декали. Подчеркните своё мастерство!
Читайте также
Вы провели тысячи зрелищных сражений в World of Tanks, неоднократно демонстрируя своё мастерство и опыт на поле боя. Вы исследовали десятки машин и можете экспертно рассказать о каждой из них. Вы — настоящие профессионалы!
И, чтобы подчеркнуть ваши достижения, мы вводим особые знаки отличия — н астало время показать всем, чего вы стоите!
Пускай все знают о ваших достижениях!
В обновлении 1.9.1 мы добавим в игру новые этапные декали практически для всех существующих стилей и техники. Это не только новые элементы внешнего вида техники, но и свидетельства вашего мастерства и опыта, которые позволят остальным узнать о ваших игровых заслугах.
Эти особые отметки будут внушать уважение противнику, а товарищам по команде покажут, что вы — надёжный союзник!
Как получить новые декали?
Каждая этапная декаль состоит из 3 или 5 уровней (этапов) с возрастающей сложностью. Выполнение условий достижения первого этапа приносит вам одну соответствующую декаль. Потом, по мере выполнения условий, становятся доступными декали следующих этапов.
Как только вы достигнете следующего уровня, этап вашей декали автоматически повысится, а внешний вид — изменится. Уведомление о новом достижении придёт после боя, когда техника появится в Ангаре.
Новые этапные декали World of Tanks в обновлении 1.9.1
Такая возможность появляется с релизом обновления 1.9.1.
Как получить новую кастомизацию?
Здесь нет ничего проще! Для этого нужно просто играть в стандартном режиме в рандомных боях. После исполнения условий, декаль будет получена автоматически. Всего для каждой отметки запланировано 3-5 уровней с прогрессивно-повышающейся сложностью. Как упоминалось выше, с прохождением каждого этапа, визуализация декалей будет меняться в соответствии с фактическим прогрессом статистики.
После выхода обновления, игрокам будут доступны следующие декали:
Уведомление о прохождении очередного этапа декали появляется в персональных сообщениях игрока, после того, как техника возвращается в ангар.
Дополнительную информацию можно получить, перейдя во вкладку ВНЕШНИЙ ВИД. После релиза обновления, здесь появится подраздел ЭТАПНЫЕ ДЕКАЛИ.
Как новые отметки будут наноситься на стили?
К особенностям новых декалей можно отнести совместимость с другими элементами кастомизации техники, в том числе, 2D и 3D-стилями. Исключением из этого правила являются партнёрские танки, на которые уже нанесён неизменяемый стиль.
Для эффективного поиска поэтапных декалей предусмотрен специальный фильтр, расположенный на панели управления. Каждая отметка привязывается к конкретной машине, и прогресс прохождения этапов учитывается только для выбранной техники.
Согласно запланированным условиям, на каждую машину возможно нанесение 3-х декалей из 5. При этом первый элемент ставится бесплатно, когда выполнены все этапные условия. Дополнительные декали можно докупить за золото в игровом магазине.
Нужно уточнить, что отметки завершённых этапов сохраняются навсегда, поэтому при желании, на танк можно единовременно нанести декали разного уровня прогресса.
Простой и эффективный способ продемонстрировать личное мастерство!
2D магия в деталях. Часть третья. Глобальное освещение
Глобальное освещение, динамический свет и декали (да, есть такое слово 🙂 ) в действии.
Я очень люблю смотреть на белые предметы без текстуры. Недавно в художественном магазине я долго рассматривал гипсовые фигуры, которые художники используют в качестве модельных объектов. Очень приятно видеть все эти плавные переходы света и мягкие тени. Позже, когда я вернулся домой и открыл Unity3D, пришло понимание, что свет в моём проекте по-прежнему скучный и нереалистичный.
С этого момента началась история глобального освещения, которую я сегодня расскажу.
Предыдущие статьи
Оглавление
Как делать процедурно генерируемые эффекты
Самый первый комментарий к начальной статье этого цикла звучал так: «Магия! И прямые руки.» Не уверен в полной прямоте моих рук (в конце предыдущей статьи — визуальные баги, которые это подтверждают), но никакой магии тут нет. Поделюсь секретом процедурных эффектов:
Минимум треть работы уже сделана, как только вам в голову пришла идея сделать процедурно генерируемый контент. Это может быть что угодно: пятна на крыльях бабочек или атмосфера планеты, деревья и кусты и т.д. Иногда, особенно со светом, сразу понятно, как происходит «генерация» в реальном мире. Чаще всего алгоритм сводится к: «пустить бесконечно много лучей в бесконечное количество направлений и получить реалистичную картинку».
И это вторая треть — написать подобный алгоритм (с учетом того, что бесконечность хорошо аппроксимируется тысячей). Он получается простой, как «hello world», но медленный. Руки сразу тянутся что-нибудь оптимизировать, но, поверьте, не стоит. Лучше запустить его в редакторе и пойти пить чай. А после чая понять, что придуманный метод не даст красивой картинки и всё переделать. Если планируется единожды предрассчитать какую-то картинку в редакторе, и потом использовать её в билде — на этом можно остановится.
И, наконец, последняя треть — придумать алгоритм, который даст визуально близкий результат, но будет работать быстрее. Обычно тут пригождается знание всяких интересных контейнеров, алгоритмов, деревьев и т.д. За один из таких алгоритмов — большое спасибо Dionis_mgn, который когда-то рассказал, как сделать классные двумерные тени.
Планета из предыдущего проекта.
Например, небо для планет в одном из проектов предрассчитывалось так: для каждого пикселя неба выпускались по 20-30 лучей до разных частей Солнца, считалось, сколько лучей пересекается с самой планетой, какую часть пути луч прошел в атмосфере (для подобия рассеивания Рэлея). С хорошим качеством расчеты для одной планеты длились около 30-40 секунд и давали на выходе разнообразные атмосферы в зависимости от удаленности Солнца, «состава» и плотности атмосферы. А еще этому алгоритму удавались неплохие закаты.
Вся звёздная система.
Что такое глобальное освещение?
Необходимость что-то делать с освещением я заметил, когда добавил в демку смену дня и ночи. Лучи света от солнца и луны красиво освещали стены замков, но вот внутри помещений творилось что-то странное: как только рассветные лучи касались верхушек башен, в самых глубоких казематах становилось светло, простите за каламбур, как днём. Конечно, причина не в источнике света «defaultSun»: при смене дня и ночи менялись цвет и яркость неба. Вот они и влияли на каждый пиксель, в не зависимости того, был ли это пиксель травинки на старой крыше или камня в мрачной пещере.
Давайте определимся, какую картинку мы вообще хотим получить. «На свету светло, в темноте — темно» — звучит неплохо для отправной точки. Как в реальном мире: в шкафу темно, в коридоре светлее, в комнате еще светлее, а на крыше совсем ярко. Переформулируем: элементы фона, персонажи и прочие объекты должны получать столько света, сколько фотонов смогло добраться до них от небесной сферы (в нашем 2D случае — небесной окружности). Понятно, что лучше направлять наши «фотоны» не с неба, как в реальном мире, а наоборот, из освещаемой точки в небо: в противном случае нам понадобится слишком много бросков, да и то, многие уйдут «в молоко».
Ещё одно из условий: рассчитываем глобальное освещение только для статических объектов: стен, земли. Так мы сможем запускать его при загрузке и пользоваться результатами весь уровень (без влияния на fps).
Кусочек сцены. На самом деле, расчеты идут для всей сцены целиком.
Прямое освещение
Сказано — сделано. Создаём текстуру размером со всё игровое поле. Пробегаемся по каждому пикселю и смотрим, как много прямых лучей можно протянуть от этой точки до «неба». Лучи будем бросать с равными углами по всей окружности, а «небом» считаем ближайшую точку за пределами карты (вполне хватит расстояния диагонали описывающего карту прямоугольника).
Итого, алгоритм прямого освещения:
Напрашивается оптимизация: бросать лучи только в верхнюю полуплоскость. И только для непрямого освещения работать со всей плоскостью целиком. К сожалению, оптимизации (об этом ниже) не позволяют использовать разное количество лучей для прямого и непрямого освещения.
Демонстрация освещения одного пикселя.
Чтобы ускорить процесс, будем работать не с текстурой, а с одномерным массивом яркостей. Да и не обязательно обрабатывать каждый пиксель: введем коэффициент scale, при scale=4 будем работать с каждым четвёртым пикселем. Размер текстуры и скорость работы вырастет в scale^2 раз. Кроме того, нам не нужно обрабатывать «твёрдые» пиксели стен, но они нам понадобятся в дальнейшем. Заведём для них отдельный массив с булевыми значениями «твёрдости».
При 25и лучах получаем такую текстуру.
Помните, в прошлой части был раздел про Region tree? С его помощью бросать raycast’ы через всю карту оказывается достаточно быстрым делом.
Я не использую цикл по всей текстуре, так как больше половины пикселей принадлежат стенам. Вместо этого итерация производится по массиву индексов «нетвёрдых пикселей».
Непрямое освещение
Прямых лучей явно недостаточно: слишком темно будет в комнатах замка, да и резкие границы хорошо видны. Вспоминаем умные слова, вроде raytracing’а, и понимаем, как много времени займёт применение этих умных слов. С другой стороны — ведь любой переотраженный луч приходит откуда-то с карты, а всё прямое освещение мы только что построили! Расширяем массив и храним там целую структуру:
Переделаем алгоритм прямого освещения, добавляя данные о коллизиях:
* Нормали нужны по простой причине: точка пересечения, возвращаемая raycast’ом — в стене. Нам нужно отступить в сторону, чтобы получить координаты ближайшего к стене пикселя.
* Метод raycast’а для region tree я найти не смог, поэтому делюсь своими наработками:
1. Берем узел (изначально — корневой) и находим пересечение с ним с помощью алгоритма Лианга-Барски;
2. Из четверых узлов потомков находим тот, которому принадлежит ближайшая точка пересечения;
2.1. Если узел — твёрдый лист, возвращаем координаты точки пересечения и нормали;
2.2. Если узел не является листом, спускаемся ниже, начиная с шага 1;
3. Находим дальнюю точку пересечения прямой с узлом потомком (тот же алгоритм Лианга-Барски). Находим еще одного потомка, которому принадлежит эта точка (т.е., если мы сначала попали в верхний левый узел, а прямая — вертикальна, то теперь это будет нижний левый угол). Продолжаем с шага 2.1.
Если проще, мы проверяем пересечения отрезка с квадратами, начиная от самого большого и до самого мелкого, причем сортируем их по близости к началу луча, до тех пор, пока не наткнёмся на твердый узел.
Теперь у нас достаточно информации, чтобы рассчитать любое количество отражений: если
луч ушел в небо, получаем прямое освещение, в противном случае — непрямое из точки пересечения.
Так получается алгоритм непрямого освещения:
Демонстрация непрямого освещения. Собираем из коллизий уже рассчитанное прямое освещение.
Самое главное, что теперь вместо операции raycast’а по region tree нам достаточно взять значение яркости в массиве: так мы получим одно отражение. Конечно, этот метод подходит только для pixelart’a: не нужно учитывать нормали или заботиться о возникающих артефактах.
Посмотрите, какие результаты даёт этот алгоритм:
Готовый результат для фоновых стен.
Довольно шумная картинка получается. На самом деле, после применения такого освещения к реальным текстурированным объектам шумы почти не заметны. К тому же высокочастотный шум исчезнет при использовании scale > 1.
Освещение стен
Вот только стены в текущей текстуре чёрные. «Конечно», возразит зануда, далёкий от геймдева, пиксельарта и чувства прекрасного — «Ведь это не стены, а срез трехмерных стен в двумерном пространстве. А внутри стен, как известно, темно.». Поблагодарим зануду и продолжим эксперименты. Попробуем вообще не затемнять стены:
Стены без применения освещения.
В первом случае результат красиво смотрелся только под землёй, во втором — на поверхности. Нужно адаптивно менять яркость стен в зависимости от окружения.
А теперь история одного фейла. После многочасовых размышлений и прогулок в мне голову пришел исключительной красоты алгоритм, включающий в себя добавление новых методов в region tree, поиск ближайшей точки, не принадлежащей стене и прочее, прочее. Я реализовал этот код, потратив на него все выходные, оптимизировал, как только мог. Этот монстр вычислялся около минуты и всё равно выглядел не идеально. В какой-то момент я решил скрыть огрехи алгоритма, немного размыв по Гауссу результат. Это было идеально! Я ещё некоторое время вносил правки и небольшие изменения. Пока не наткнулся на ошибку в условии, из которой следовало, что результаты моего чудесного алгоритма отправлялись прямиком в garbage collector, а на финальные пиксели влияло только размытие. А вот картинка оставалась такой же красивой.
Зато теперь это самый быстрый этап всего глобального освещения. 🙂
Переведём наши массивы в текстуру, где в одном канале будет яркость пикселя, а другом — принадлежность стене. Размоем пиксели стены на GPU с помощью простого шейдера (простое среднее арифметическое с соседями) в цикле.
Размытые стены (scale = 2).
Вот такое недоразумение получится, если применить освещение.
В первой статье цикла я рассказывал про основы пиксельарта. Дополню еще одной важной аксиомой: никаких градиентов в духе photoshop’а! Это превращает аккуратную картинку в мыло и пластилин. На фоне градиенты не так бросаются в глаза, как на стенах. Пройдемся по текстуре с еще одним шейдером: для каждого пикселя стены с помощью простого округления (с коэффициентом из параметров шейдера) получим несколько градаций яркости. Конечно, полученные переходы далеки от идеала — рука художника не двигала пиксели, убирая кривые лесенки, но нам подойдет.
Световая маска с низкой дискретизацией (scale = 2).
Результат применения маски.
Результат применения маски при использовании реальных текстур.
Обратите внимание, как хорошо скрываются шумы и недочеты освещения, когда мы применяем его к реальным текстурам. Если бы глобальное освещение было динамическим, человеческий мозг, отлично распознающий движение, сразу же нашел бы косяки.
Итак, у нас есть глобальное освещение!
Плюсы этого алгоритма:
Декали
Хотя основная тема статьи раскрыта, это ещё не повод заканчивать стучать по клавишам. Скорее всего, это последняя статья про освещение. А значит, есть смысл рассказать про некоторые новые фишки, которые были добавлены после рефакторинга игры.
Декали («decal» — «переводная картинка»), это отличный способ сделать игру более живой, не сильно жертвуя производительностью. Идея проста: на определенную поверхность (стена, пол и т.д) накладывается прямоугольник с текстурой, как настоящая переводная картинка. Это может быть след от пули, какой-нибудь мусор, надпись, что угодно.
Но мы будем использовать декали немного иначе: в качестве источников света произвольной формы. Раз уж мы генерируем текстуру с освещением, мы можем добавлять в неё объекты произвольной формы. И эти объекты сразу же начнут светиться! Так можно легко реализовать эффекты люминесценции, теплового излучения.
Но есть два важных момента:
По сути, алгоритм простой:
Разделим все декали (например, с помощью тегов Unity3D) на декали переднего и заднего планов:
На примере будет понятнее:
Находим старый спрайт травы.
Позиционируем «траву» так, чтобы она закрывала кончики стен.
Рендерим спрайт только в текстуру освещения.
Добавляем свечение на стены.
Добавляем свечение на фон.
И получаем интересную радиоактивную плесень.
А еще можно делать раскаленные стены, уникальные светящиеся предметы и многое другое.
Стена светится от счастья.
Доработки динамического освещения
Это очень короткий раздел и весь от первого лица. Наконец-то добрались руки сделать рендеринг только видимых источников света. Все источники, которые не попадают в камеру, не отрисовываются и не кушают драгоценный fps.
Более того, оказалось, что источники света составляют отличную иерархию:
1. SkyLight. Фоновое освещение, где важны яркость и цвет;
2. SunLight. Точечный источник света без затухания. Важны яркость, цвет и позиция;
3. PointLight. Точечный источник света c затуханием. Важны яркость, цвет, позиция и радиус;
4. FlashLight. Фонарик с коническим лучом. Важны яркость, цвет, позиция, радиус, угол поворота и ширина луча.
А еще появилась возможность создавать любые другие источники света, наследуясь от базовых.
Вышеописанные источники света.
Заключение
Теперь в нашем проекте есть реалистичный свет, эффекты светимости и обновленные динамические источники света. Сравните с изображением из первой статьи, не так уж мало различий, правда?
Изображение из начала этой статьи.
Изображение из первой части цикла.
И самое интересное: теперь когда готово освещение и произведен рефакторинг алгоритмов и структуры проекта, пришло время написать про воду!
Спасибо за чтение и комментарии к прошлым частям и до следующей статьи!
Decal (декаль)
Декали (decal с англ.: бирка, ярлык, клеймо) это особый вид геометрии, который позволяет повышать детализированность игровых окружений без надобности запекать мелкие детали в текстуры, что может быть просто невозможным в ситуациях, когда множество поверхностей используют одинаковый материал. Обычно декали используют для отрисовки дырок от пуль, пятен крови или гари от взрывов, но в некоторых случаях использование уходит за пределы таких вещей. К тому же декали можно создавать не только в динамике, но и во время изготовления уровня.
Можно представить себе игровой уровень с большим количеством зданий. С помощью декалей стены этих зданий можно уникально «украсить» оборванными плакатами, трещинами или пятнами краски, здесь фантазия не ограничена. При наложении можно применять различные методы блендинга для достижения подходящего результата.
Для улучшения восприятия таких деталей можно использовать стандартные техники освещения, такие как bump mapping, parallax mapping и другие. Параллакс особенно хорошо выглядит, так как придаёт намного больше объёма и позволяет таким вещам, как дыркам от пуль «углубляться» в геометрию.
Создавать декали в динамике можно разными способами. Существует упрощённое решение, дающее во многих ситуациях неверные решения, так и более точное, требующее от двух и более треугольников под декаль.
Одно из простых решений, которое можно смело применять для создания «дырок» от выстрелов, заключается в поиске точки пересечения луча с треугольниками игрового уровня (тут нужны различные оптимизации, для того чтобы не проверять каждый треугольник и расчёт места пересечения занимал мало времени). Затем мы берём найденную точку, и используя бинормаль и тангент в этой точке создаём два треугольника, образующих квад. Если информации о бинормали и тангенте нету, можно просто взять два случайных перпендикулярных единичных вектора, расположенных в плоскости поверхности и строить квад по ним. Нормаль поверхности следует использовать как нормали в точках декаля для правильного освещения. Для избежания проблем с z-fighting’ом, который возникает на плоскостях расположенных близко друг к другу следует использовать Polygon Offset/Depth Bias. Текстурные координаты тоже можно находить разными способами, например, для дырок от выстрелов можно использовать координаты углов квада. А вот, например, для пятен крови, которые должны «размазываться» по направлению движения можно рассчитать текстурные координаты методами eye linear\object linear.
Но это простое решение может плохо работать для тех же пятен крови, имеющих большую площадь поверхности. Для таких декалей нужно рассчитывать не центральную точку пересечения, а находить треугольники попадающие в зону покрытия, и создавать множество геометрии на всех этих поверхностях.
Существует также метод при котором детали отрисовываются в текстуру, но это имеет ряд проблем, например требуется уникальность изменяемой текстуры (она должна использоваться только на одном объекте, иначе добавленные детали появятся на всех объектах, использующих изменяемую текстуру), а также страдает скорость из-за постоянных обновлений текстуры (если генерируются мип-уровни, то это будет занимать значительное количество времени).
Текстуры, используемые для декалей лучше хранить в одном текстурном атласе. В таком случае для огромного количества декалей на уровне можно будет использовать один вершинный и индексный буфера, и рисовать всю их геометрию за один вызов функции DrawIndexedPrimitive\glDrawElements.
CGI blog
Всё о CGI (Computer-generated imagery)
Декали в трёхмерной графике. Что это и как с этим работать?
Декаль (en decal) это «переводная картинка», которая накладывается на поверхность. В трёхмерной графике значение декалей очень велико. Без декалей не обходится не одна серьёзная большая композиция. Декаль представляет собой изображение с прозрачным фоном (альфа-каналом). Прозрачные изображения очень помогают в создании композиций.
Создаётся поверхность (плэйн) и на неё накладывается текстура с прозрачным изображением. Далее этот плэйн накладывается поверх других. Таким способом создаются различные рисунки на стенах, артефакты, трещины и т.д. Область применения декалей весьма обширна. В видео играх кровь и следы от выстрелов на стенах — это и есть декали. Т.е. декали отличаются от текстур тем, что они налепляются поверх. Расстояние между плейном с декалью и самой поверхностью, на которую он налепляется, крайне мало. Поэтому всё выглядит реалистично. Увидеть налеплённую на поверхность деталь можно если вид камеры разрезает эту поверхность в месте, где наклеена декаль. Можно увидеть, что в этом месте поверхность стены как бы двойная. Это потому, что на одну поверхность наклеивается плейн с декалью.
Как уже стало понятно, декали используются для того, чтобы сэкономить на геометрии. А делаются в виде отдельных плейнов они потому, что это гораздо легче, чем смешивать имеющуюся текстуру объекта с текстурой декали. Вообще тема смешения текстур до сих пор остаётся проблемной. Поэтому исторически так повелось, что проще на имеющуюся поверхность наклеить ещё одну с прозрачной текстурой.
Если вы серьёзно занимаетесь трёхмерной графикой, то вам придётся сталкиваться декалями. Что нужно знать при работе с декалями? Ничего особенного. Следите за размером, правильной стороной наклеивания и отключайте тень у плейнов с декалями.
На декали крайне желательно (чаще даже обязательно) устанавливать отключение отбрасывания тени, чтобы:
В играх всякие, точнее вообще все, декали (повреждения, следы от выстрелов, краска, граффити) также на стены наклеиваются на плейны поверх полигонов поверхностей.
Вот в принципе и всё, касательно декалей. Декали вообще лёгкая тема.