Отражения

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

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

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

Вот так выглядят эти сферы у нас в MTA

Основное их предназначение именно в этих местах — отражения в стёклах торгового центра.

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

А это пример со столбиками. В них видно красные оттенки — это отражается рядом стоящий ТЦ.

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

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

Сплайны

После того, как мы решили использовать в качестве редактора карты Unreal Engine, мы также задумались о том, чтобы добавить в MTA часть тех возможностей, которые широко используются в UE и значительно упрощают жизнь моделлерам/дизайнерам уровней.

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

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

Облака

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

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

Заняла эта работа почти месяц.

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

А это облака с правильным тонмаппингом и постобработкой:

Нравится? Мы довольны получившимся результатом.

Не обошлось и без забавных багов

В сочетании с атмосферным рассеиванием, о котором мы рассказывали во второй части дневников, получается вот такая красота:

Оптимизация

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

Это технология, которая позволяет не рисовать на экране те объекты, которые скрыты другими объектами.

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

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

Небольшая демонстрация:

Здесь красные боксы показывают границы объектов, которые были исключены из рисования на экране алгоритмом occlusion culling’а.

На сегодня всё, увидимся в следующей части!

Отражения и PBR

Не раз мы читали под нашими скриншотами сообщения вроде «в MTA/GTA SA нет отражений». Да, таких отражений, как у нас — нет (хотя и в GTA SA есть, например, зеркала и зеркальный пол). Но у нас всё достаточно серьёзно переработано и мы сделали Screen Space Reflections (к слову, на первой версии рендера такие отражения было бы сделать очень и очень проблематично, если вообще возможно).

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

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

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

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

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

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

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

А это уже более-менее финальный вариант отражений. Сцена не настроена и отражения специально выкручены «на максимум», чтобы их можно было лучше рассмотреть.

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

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

Ландшафт

Обычный путь, который используется для создания ландшафтов для GTA SA — это моделирование в каком-то редакторе (3ds Max, Blender и т.п.), затем нарезка его на части размером не более 256×256 метров и после — перенос этих мешей в игру. И при необходимости внесения любого изменения весь этот процесс нужно повторять снова и снова. В общем, сложно, долго, жутко неудобно и запросто может приводить ко всяким проблемам вроде зазоров между кусками ландшафта, провалам, невидимым стенам и другим проблемам, которые могут добавить большое количество головной боли.

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

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

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

Стандартная система GTA SA для физики использует коллизии, сохранённые в col файлах. Также она используется для того, чтобы задавать различные свойства поверхностей: внешний вид (где растёт трава, например), звуки, тени, а так же определяет, видим ли объект на экране.

Для того, чтобы динамически создавать ландшафт, нам пришлось модифицировать эту систему, чтобы была возможность создавать коллизии «на лету», причём, произвольного размера, не ограничиваясь максимальными для GTA SA 256×256 метров (это не совсем верно, так как и в стандартной GTA SA можно использовать гораздо более крупные коллизии, но вряд ли можно рекомендовать это делать, потому что как раз за счёт этой «нарезки» производится значительная часть оптимизации).

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

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

В специальном отладочном режиме хорошо видна полигональная сетка ландшафта.

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

GUI

Из-за способа, который мы применили, чтобы перевести игру на DirectX11/12, мы не могли использовать обычные GUI системы для MTA, так как это очень сильно снижает производительность в нашем случае. Нам требовалось интегрированное непосредственно в клиент игры решение, напрямую работающее с DirectX11/12. Мы проверили множество доступных вариантов и остановились на совершенно нетипичном для GTA SA решении — NoesisGUI.

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

Подключение NoesisGUI к MTA заняло всего несколько дней, а вот интеграция с Lua потребовала значительно больше времени. Всего на это ушёл примерно месяц.

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

На сегодня, пожалуй, всё! Увидимся в следующей части!

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

Как известно, GTA SA работает на DirectX 9, который был выпущен в далёком 2002 году. Естественно, что за эти почти 19 лет, прошедшие с того момента, появилось множество технологий — как программных, так и аппаратных, — дающих множество преимуществ как разработчикам, так и простым пользователям.

Поэтому первым делом мы перевели GTA SA на DirectX 11/12. Хотя это и звучит так просто, работа была проделана огромнейшая (что заняло где-то в районе полугода работы), так как вся MTA «заточена» под DX9. То есть, если переключить игру на DX11/12, то почти весь функционал MTA, связанный с графикой, перестанет работать и нет какого-то простого эффективного способа обойти эту проблему. Однако, мы успешно справились с этой задачей, что позволило нам сделать кучу оптимизаций, использовать современные средства разработки и получить качественный результат. А некоторые вещи без этого было бы сделать вообще невозможно.

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

Тени

После перехода на DX11/12 мы начали работу над тенями. Сначала это просто чёрные пятна

к которым позже добавляется прозрачность

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

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

Небо

Следующим шагом стала работа над небом.

Пока что базовым — без облаков, солнца, луны и звёзд. Казалось бы, а что в таком случае там ещё осталось? Всё очень просто — осталась атмосфера. В зависимости от времени суток у нас корректно рассчитывается цвет неба и атмосферное рассеивание света.

Кто-то из вас наверняка видел подобное небо в Unreal Engine или Unity, либо в играх, сделанных на этих движках (есть даже те, кто думал, что скрины с одного из этих движков, видя такое небо). А кто-то скажет: «просто какой-то туман, чего такого?». Но нет, это не простой туман. Вот пара картинок из интернета, показывающих, что даёт атмосферное рассеивание:

Красота, не правда ли? Вот и у нас это будет, когда завершим работу*.

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

PBR

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

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

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

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

Чтобы всё работало, нам пришлось также существенно переработать множество вещей в GTA SA и MTA. Например, мы используем собственные форматы моделей и текстур.

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

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

Ambient Occlusion и сглаживание

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

Если интересны технические подробности, то на момент написания статьи для сглаживания поддерживаются SMAA 1x, SMAA 1x + TSSAA и SMAA 4x, а для Ambient Occlusion — SSAO, HBAO и Alchemy AO.

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

Результат простого сглаживания:

А это результат работы базового алгоритма самозатенения:

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

Совмещаем самозатенение и сглаживание, что значительно улучшает результат:

Что было дальше?

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

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

Чтобы не было недопонимания, данный рендер — не ENB. Это гораздо более сложная работа. Если вкратце, то мы полностью отключили ту часть GTA SA, которая отвечает за отображение игры и вместо этого сделали свою собственную систему.

Сначала мы хотели просто добавить тени и качественные отражения.

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

Затем добавили Ambient Occlusion (самозатенение близко располагающихся поверхностей):

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

Дальше следовал многократный процесс настройки визуальной части.

В 2020-м году подключили это всё к RPBOX, а также начали заниматься настройкой транспорта на нём

и постепенно пришли к чему-то такому:

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

Увы, стёкла зарелизить не успели, так как в проект вернулся Никита и мы всей командой ушли. А вы просто посмотрите на эту красоту:

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

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

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

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