Продолжаем рассказывать о том, как мы достигли того результата, который вы не раз видели на наших скриншотах, а также о том, что ещё добавлялось в клиент игры помимо графики.
Отражения
В прошлой части мы рассказали про SSR отражения — отражения, которые работают исключительно с той информацией, что есть в данный момент на экране. Именно по этой причине такие отражения «исчезают», если камера смотрит вниз под сильным углом — информации на экране не хватает для построения полноценного отражения.
Но в игре используются не только они. Например, когда мы подходим к металлическому столбику, то мы хотим, чтобы в нём отражалось то, что находится вокруг — даже то, что находится за пределами нашей видимости (за нашей спиной, например). Для этого игра должна поставить камеру на место этого столбика, а затем сделать «захват» изображения всего, что находится вокруг и в последующем именно это «захваченное» изображение и используется для рисования отражения. Эдакая карта отражений.
Чтобы игра знала, где нужно создавать такие карты отражений, в редакторе расставляются специальные маркеры, называемые сферами захвата отражений (Sphere Reflection Capture) и боксами захвата отражений (Box Reflection Capture). В большинстве случаев используются именно сферы, а боксы применяются, например, в комнатах.
Вот так выглядят эти сферы у нас в MTA

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

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

А это пример со столбиками. В них видно красные оттенки — это отражается рядом стоящий ТЦ.
Помимо того, что эти отражения позволяют показывать то, что находится за пределами экрана, они также менее требовательны к мощности компьютера (особенно статические отражения).
Сложность, с которой мы столкнулись при их реализации — то, что такие отражения для оптимизации строятся либо очень редко, либо вообще всего один раз. Но тогда они не учитывают небо (время суток, цвет неба и т.п.). Пришлось хорошо подумать, чтобы совместить всё это вместе и при этом не потерять в производительности.
Сплайны
После того, как мы решили использовать в качестве редактора карты Unreal Engine, мы также задумались о том, чтобы добавить в MTA часть тех возможностей, которые широко используются в UE и значительно упрощают жизнь моделлерам/дизайнерам уровней.
Одна из таких возможностей — сплайны. Ведь очень удобно, когда можно поставить несколько точек и между ними автоматически построится, например, забор, рельсы, дорога или висящий провод.


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



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

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

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


В сочетании с атмосферным рассеиванием, о котором мы рассказывали во второй части дневников, получается вот такая красота:
Оптимизация
Оптимизация охватывает огромнейшее количество аспектов. Но сейчас расскажем только об одной оптимизации, которая называется Occlusion culling.
Это технология, которая позволяет не рисовать на экране те объекты, которые скрыты другими объектами.
В GTA SA эта технология также используется, но она там реализована на достаточно примитивном уровне, из-за чего её нельзя использовать для слишком большого количества объектов, иначе это может вызвать заметное падение производительности. Не говоря уже о том, что там все перекрывающие плоскости нужно расставлять вручную.
Так как у нас модели значительно более «тяжёлые» и сложные, использование такой оптимизации становится весьма критичным. Поэтому мы сделали свою версию оптимизации, где идёт автоматический расчёт размеров видимых объектов и если они занимают больше определённой площади на экране, то для них включается occlusion culling и все объекты, которые находятся за ними, перестают рисоваться.
Небольшая демонстрация:
Здесь красные боксы показывают границы объектов, которые были исключены из рисования на экране алгоритмом occlusion culling’а.
На сегодня всё, увидимся в следующей части!
