Жду новый пост

Серия «TOTAL RELOAD»

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

В процессе разработки вдохновение черпал везде где только можно. В основном из Interstellar, референсы и матмодели других разработчиков. Сразу приведу некоторые ссылки: youtube.com/watch?v=g-iw2DDNDeY (реализация без когда, полезно чтобы понять в общих чертах как сделать черную дыру)

А вот этот парень большой молодец (на мой взгляд):

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

Черная дыра глазами математика (ПОЕЗНОЕ И ПОЗНАВАТЕЛЬНОЕ)

А это мой вариант "Б" на случай если у меня не получилось бы сделать черну дыру приблизительно как в Интерстелларе. Такую версию дыры точно можно сделать:

Разработка

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

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

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

Структура черной дыры, некотороые попытки воссоздания

В целом черная дыра состоит из ядра (то что находится в центре) и диска (его называют аккреционным диском).

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

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

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

В моем случае была использована процедурная генерация звезд на основе вот такого шума (https://www.shadertoy.com/view/Xsl3Dl):

После того как немного пошаманил, получилось создать процедурное небо:

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

Черная дыра

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

В общем мой подход "ВСЕ ЧТО УГОДНО, НО НЕ РЕЙМАТЧИНГ" привел меня к таком результату:

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

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

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

Хотя облака диска у нас реализованы не на 100% так как показано на видео, посмотрел это видео чтобы погрустить на тему того, что придется много-много-много пробовать, экспериментировать.

Рейматч

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

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

Артефакт, в данном случае, - это как бы "шов" от замыкания облаков. Здесь показал изменение координат полярной системе. Шов находится в области резкого перехода красного в желтый. Если смажем переход (путем интерполяции), то шва не будет:

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

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

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

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

Результат

Выводы

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

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

Ссылки на нас

У нас уже есть страничка в стим, трейлер, скрины из игры :)

TOTAL RELOAD в STEAM / Сообщество ВК / Reddit / TORSHOCK

Ссылки на меня: CGAleksey_VK / CGAleksey_DTF

Готовы рассказать о процедурной генерации проводов и о том как она устроена в TOTAL RELOAD. Всего проводам будет посвящено 2 статьи (2 части). Выше приведен скриншот из игры на котором представлены финальные провода.

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

Предупреждение: эта статья не является инструкцией, также, скорее всего, она не будет полезна профессиональным программистам, которые имеют опыт работы с процедурной генерацией мешей. Статья содержит картинки, видео и обобщенные объяснения разработанной нами системы генерации проводов и обобщенный ответ на вопрос «что же такое меш (mesh)?» Итак, поехали!

Часть 1. Процедурная генерация проводов

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

Версия провода № 1

В самом начале разработки игры было принято решение не пытаться вытянуть качество графики до уровня ААА – проекта. Причины такого решения просты:

• команда состояла (и состоит) из 2-х человек, которым задач и так хватало

• не было уверенности, что все окупится

Итак, в первое время мы разработали «2D» систему проводов, которые были плоскими. Я думал, плоская – это хорошо в плане того, что меньше полигонов и объем проводам можно картами нормалей придать (если потребуется). Ниже представлен первый вариант системы проводов:

Как работала система проводов:

• имеется набор вложенных gameObjects – узлы проводов

• родительский объект создает процедурный mesh с UV. Mesh и UV создаются в зависимости от позиции узлов проводов.

Система позволяла выполнять поставленные задачи:

• отображала соединения объектов

• относительно гибко настраивалась

• генерируемый провод соответствовал первому минималистичному стилю

Меш провода генерировался процедурно по точкам. Здесь видно конечный результат (вариант провода №1):

Провод менял свою геометрию тогда, когда одна из точек меняла свою позицию. Провод мог гнуться на углы +/-90 градусов относительно родительского объекта. Еще одно видео:

Так планировалось прокладывать провод в уровне:

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

И вроде как все были довольны этой системой проводов, но…

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

У Совы, насколько мы знаем, брови изначально (наверно с рождения) повернуты под 90 градусов. А после всего того, что мы показали, они у нее просто вывернулись на все 360.

Провода нужно было переделывать.

Что не устроило Сову:

• Обыденность и минималистичность: где-то она уже видела этот провод;

• Скрытность: он плоский, сбоку его вообще не видно;

• Повороты кратны 90 градусам: уровень будет иметь углы только кратные 90 градусам, это снижает возможности разработчика уровней до… лучше не думать, даже некоторые первые в мире игры имели стены, которые располагались под произвольными углами.

По проводу все осталось в общем по-старому, только в ТЗ добавилось 4 требования:

• провод должен гнуться не только на 90 градусов;

• провод должен быть объемным, так как плоский визуально сливается с полом;

• текстура должна тайлиться, а не растягиваться;

• уникальность проводу нужно придать моделью + материалом.

Пара слов о генерации меша

Хотелось бы чтобы статья содержала больше полезной информации чем просто результаты нашей работы.

Немного глубже затронем тему процедурной генерации мешей.

Что такое меш (mesh)?

Меш – это, условно, модель, которая крепится к компоненту «MeshFilter», который, в свою очередь, принадлежит «GameObject». MeshFilter берет меш из ассетов и передает его в MeshRenderer, последний участвует в рендере меша на экране.

Способы создания моделей для игр:

• в редакторах моделей (например: Blender, Maya, 3ds Max и другие);

• процедурно

• можно редактировать существующий меш (в общем-то это процедурная генерация меша)

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

О том как создавать меши уже написано столько всего, что мне остается дать одну из ссылок на материалы и обьяснить, в общем виде, как все работает. Ссылка на то как сгенерировать меш в Unity3D: http://www.martin-ritter.com/2019/02/unity-simple-mesh-generation/

При создании меша, во-первых, относительно локального (0,0,0) создается геометрия. Геометрия – это набор вершин (точек), которые соединены между собой. Потом идет массив «triangles». Этот массив содержит порядок точек. Тут стоит совсем немного пояснить:

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

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

Итак, этого в общем-то достаточно для рендера геометрии, но недостаточно для наложения текстур на геометрию. Для наложения текстур нужно создать массив UV – координат. Эти координаты показывают в какую область текстуры проецируется каждая вершина геометрии/модели. Обычно UV принимают значения из диапазона [0,1]. Где (0,0) – нижний левый угол текстуры, (1,1) – правый верхний. В некоторых случаях UV могут принимать значения больше 1 и меньше 0. Это зависит от задачи, которую поставили перед «shader-artist» и его конкретной реализации шейдера.

Кроме vertex и uv, меш может содержать и другие данные:
- uv2, uv3…, uv9 (не знаю чем определяется предел uv[i], наверно платформой)

• tangents

• normal

• color

И да, чуть не забыл, нужно создать AABB. AABB – это axis-aligned bounding box. То есть это «коробка», которая позволяет движку быстро исключать игровые объекты из процесса отрисовки на основе попадания их AABB в область видимости камеры.

Зачем? Это сделано для того, чтобы быстро отбрасывать объекты, которые за спиной игрока, чтобы они даже не пытались подаваться на графический конвейер. Оптимизация! :)

Версия провода 2

В основу этой версии легли сплайновые кривые, а вернее, деформация модели вдоль сплайновой кривой. Что такое сплайн и как он работает? Это достаточно базовая математика, в сети есть даже готовые примеры проектов со сплайнами, детальный разбор того как все работает (не буду повторять то, что замечательно расписано здесь: catlikecoding.com), не будем на них останавливаться.

Вот как выглядит настройка провода:

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

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

Здесь версия проводов ближе к финальной (на концах установлены вилки, заданы текстуры, доработаны модели):

Ссылки на нас:
TORSHOCK.RU / VK / DTF / Twitter / FB