Разное

Unreal engine rus: Unreal Engine 4 • » Документация

Содержание

Unreal Engine 4 • » FAQ

Основное

Для чего мне нужен Unreal Engine 4?

Unreal Engine 4 предоставляет большой набор инструментария для создания 2D и 3D проектов. Это могут быть игры, архитектурная визуализация, различные демки и даже видеоролики. Нужно ли это, решать Вам.

Сколько стоит Unreal Engine 4?

Unreal Engine 4 распространяется бесплатно. Однако до тех пор, пока вы не выпустите свой первый коммерческий продукт на основе UE4.

Сколько нужно платить, если я хочу выпустить коммерческий продукт?

Когда вы выпустите свой проект и получите первые $3000 за квартал (за один проект), необходимо будет отчислять Epic Games 5%. Для получения большей информации, ознакомьтесь с FAQ по Лицензионному соглашению с конечным пользователем и выпуску проекта

Какие системные требования у Unreal Engine 4?

Вот рекомендуемые системные требования для UE4 в данный момент:

Настольный ПК или Mac

Windows 7 64-bit или Mac OS X 10.9.2 или старше

Четырехядерный процессор Intel или AMD, 2. 5 GHz или лучше

NVIDIA GeForce 470 GTX или AMD Radeon 6870 HD или лучше

8 Гб ОЗУ

Однако минимальные требования гораздо ниже, благодаря гибкой настройки графики.

Какие платформы доступны?

Unreal Engine 4 дает возможность создания проектов для Windows PC, Mac, Linux, iOS и Android, HTML5. Также есть встроенная поддержка Виртуальной реальности для Oculus Rift. Помимо этого UE4 поддерживает Xbox One и PlayStation 4 (включая Project Morpheus).

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

Проекты какого плана можно создавать на Unreal Engine 4?

С Unreal Engine 4 вы можете создавать абсолютно любой проект. Игры (2D-3D; RTS, Action-RPG, Shooter, Racing, MMO-игры и любой другой жанр и направление), симуляторы и даже программное обеспечение. Вы можете использовать UE4 для архитектурной визуализации и многое другого.

В Launcher есть вкладка Marketplace и Learn, где я могу найти бесплатные проекты.
Можно ли их использовать в своих проектах?

Вы можете использовать примеры из Learn для создания собственных проектов. Вы можете разбирать, изменять и улучшать их. Более того, вы можете использовать этот контент в коммерческих целях. То же правило распространяется и на бесплатный контент из Marketplace.

Где и как скачать UE4?

Воспользуйтесь инструкцией, которую можно найти тут: http://uengine.ru/download-unreal-engine-4

Где можно найти уроки по Unreal Engine 4?

Уроки на русском языке:
http://uengine.ru/category/ue4-tutorials
http://www.youtube.com/channel/UCLbkGIcYJxxL0tciH9RVebg
http://www.youtube.com/playlist?list=PLnUf3EaBFl2LIaDR-KK8D805NZj-vDmHd
http://www.youtube.com/user/glkimmortal/videos
http://www.youtube.com/channel/UChKnft1AGav8iEjO9qi0ixQ/playlists
http://www.youtube.com/channel/UC2C7OCZkBbDq1b-5kRzVawA
http://www.youtube.com/playlist?list=PLKSc47ZvUJEzFNAuLAQ469PkGc5LsfWWF

Уроки на английском языке:
http://www. youtube.com/user/UnrealDevelopmentKit
http://www.youtube.com/user/TeslaUE4
http://www.youtube.com/playlist?list=PLL0cLF8gjBpqDdMoeid6Vl5roMl6xJQGC

http://www.youtube.com/user/PeterLNewton

Графика

Как изменить графику?

Изменить можно в меню Тулбара > Settings -> Engine Scalability Settings.

Галочку напротив «Monitor Editor Performance» настоятельно рекомендуется отключить, так как из-за неё движок будет пытаться сделать графику оптимальной, но это далеко не всегда работает так, как надо.

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

Контент

Как перекинуть контент из одного проекта в другой?

В Content Browser нужно выбрать ассеты или папки, которые вы хотите переместить в другой проект, нажать по ним Правой Клавишей мыши, затем выбрать пункт Export из раздела Asset Actions. После данных действий у вас появится окно, где будет показан список ассетов и папок, которые будут перенесены в другой проект. Вы нажимаете ОК и далее указываете папку Content того проекта, в который хотите переместить контент.

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

Как экспортировать ассет в понятный для редакторов вид?

Выберете ассет в Content Browser, который вы хотите экспортировать, затем вызовите контекстное меню (ПКМ на ассете) и выберете пункт Export из раздела Asset Actions. После этого вам будет предложено выбрать путь, куда будет сохранен файл на вашем компьютере.

Экспортировать можно следующие типы ассетов:

  • StaticMesh
  • SkeletalMesh
  • Текстуры
  • Звуки

Остальное

Как скомпилировать игру?

Игра компилируется достаточно просто. Зайдите в File -> Package Project -> Выберите систему.

Локализация игр в Unreal Engine 4 / Хабр

Подготовка игры к локализации — важная часть разработки игр.

Мы работаем над игрой «Cat Movies!» в движке Unreal Engine 4. Это экономическая стратегия, в которой достаточно много текста, и его мы планируем переводить на различные языки. Как и многие другие (но это не точно, и, надеюсь, что это не так), мы решили отложить этап настройки локализации на более поздние итерации разработки и, как оказалось, зря.

Локализация в UE4 реализована шикарно, и если помнить, что достаточно весь текст, который будет переводиться, хранить в Ftext (Text в Blueprint’ах) полях, то в целом, с выхватом текста из игры нет никаких проблем. Достаточно открыть Localization Dashboard, потыкать пару кнопок — и вуаля.

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

Дополнено от 16. 10.19: Форматирование текста.
Дополнено от 13.09.20: Локализация ассетов.

Как хранить текст

Ребята из Epic Games упростили сборку текста до максимума, сводя все к одному клику и дальнейшему переводу.

Работает это все очень просто — для локализации используется тип данных FText (Text в Blueprint’ах), в который сохраняется текст, и этот текст в дальнейшем собирается системой локализации и предоставляется для перевода.

Как это работает?

FText — это не стандартный тип данных, который хранит в себе данные. Он, конечно, хранит в себе данные, но не те, которые мы ожидаем.

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

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

Когда запускается сбор текста, то система локализации собирает все Text — переменные из всех блюпринтов, виджетов и таблиц, и выкатывает один огромный список текста, который можно экспортировать в *.po и переводить.

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

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

Мы облегчили себе задачу, создав Data Table (таблицы данных), в которых мы начали хранить данные конкретных типов. Например, таблица отделов, которая содержит в себе название, описание, максимальный уровень, кол-во сотрудников на каждый уровень, и т.д. и т.п.

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

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

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

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

Поковырявшись в документации Epic Games, я обратил внимание на String Tables (далее «строковые таблицы»). Оказалось, это идеальный вариант — хранить текст в отдельной специальной для текстов таблице, которая создана именно для того, чтобы подключаться в FText — переменным. То есть, мы можем создать таблицу, которая будет хранить в себе текст. И этот текст мы можем подключать к любой переменной — будь то переменная в таблице данных, переменная в виджете, переменная в коде — все сводится к одному месту, где хранится текст.

Строковые Таблицы позволяют избегать повторения текста в проекте по нескольку раз чуть более, чем полностью, таким образом избегая ошибок.

Строковые таблицы создаются в движке, как и таблицы данных в разделе «miscellaneous»:

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

После того, как строковая таблица создана, текст теперь можно подключать к FText — переменной:

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

Локализация

Теперь нам остается только собрать весь текст и начать с ним работать. Для этого нам необходимо запустить Localization Dashboard и начать настройки локализации. Запустить таблицу можно через меню Window->Localization Dashboard.

И перед вами откроется примерно такое окно:

В этом окне нужно обязательно указать цель (модуль), из которого будет выдергиваться текст. В нашем случае, это игра — Game.

Далее, нужно указать, откуда именно будет в модуле будет выдергиваться текст. В нашем случае, это только блюпринты, так как в сурсах мы не храним текст. Поэтому нужно указать только «Gather from Packages» и указать, в каких папках и какие файлы нам необходимо рассматривать, чтобы искать тексты.

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

Так же в UE4 есть шикарная возможность создавать переводы прямо в движке, не экспортируя тексты для сторонних программ. Для этого нужно собрать весь актуальный текст в игре, нажав на кнопку №1. И после этого запустить редактор (кнопка №2):

Откроется окно редактирования перевода на нужный вам язык.

Сборка

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

В нашем случае, Internationalization Support установлен на All. То есть, наш проект будет поддерживать все типы языков от сложных иероглифов до простых английских букв. А вообще, есть 5 пакетов:

  • English (чистый английский).
  • EFIGS (English, French, Italian, German, and Spanish)
  • EFIGSCJK (То же, что и выше + Chinese, Japanese, and Korean )
  • CJK (Chinese, Japanese, and Korean).
  • All (Все языки).

Однако в случаях, когда важен каждый байт в проекте (пакет All весит 15мбайт, а EFIGS 2мбайта), стоит более внимательно отнестись к тому, какой пакет нужно выбрать.

Переключение локализации

Переключение текста происходит в Runtime, то есть вам не нужно перезагружать игру, не нужно париться на тему оптимизации переключения — все делается легко и просто через метод «

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

И вот здесь есть некоторая такая загвоздочка. Дело в том, что разных странах есть свои ответвления языка, так, например, есть основной русский язык (ru), а есть белорусский (ru-BY), казахстанский (ru-KZ), молдавский (ru-MD), украинский (ru-UA) языки, которые попадают под ветку русского языка. Поэтому, при выборе какого-то языка, который не является основным, это нужно учитывать и указывать корректный язык. Если выбрать просто основной, то при переключении достаточно указать «ru».

Добавление в текст данных других данных в Blueprint’ах.

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


Например: «Вы желаете изучить технологию {Tech_Name}?»
И, в дальнейшем, в BP можно использовать ноду «Format Text», которая будет учитывать сам текст и какие там указаны параметры и создавать дополнительные пины для подключения этих самых данных:

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

Локализация ассетов.

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

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

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

Для этого нажмите по любому ассету в проекте ПКМ -> Asset Localization -> Create Localized Asset -> (выбрать язык).

После создания новой копии ассет можно найти в специализированной папке для локализации. Если лень искать — можно кликнуть ПКМ по основному объекту в проекте и через меню локализации выбрать редактирование нужной вам версии.

Там же можно и перейти к ассету в браузере. Все очень удобно и практично.

Заключение

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

То же самое касается и Сохранения и Загрузки в играх. Это оказалось не такой уж и простой задачей в условиях стратегии, где каждая мелочь должна фиксироваться там, где она стоит/лежит/имеет определенное состояние. Но об этом я напишу как-нибудь в другой раз. А сейчас вы можете продолжить наблюдать за нашей игрой в нашей группе VK и в Twitter’е =)

Lumen обеспечивает глобальное освещение в режиме реального времени в главе 4 Fortnite Battle Royale

Дэниел Райт, научный сотрудник отдела графики, и Кшиштоф Наркович, технический директор отдела графики |

26 января 2023 г.

Особенности

Fortnite

Трассировка лучей

Привет, мы Дэниел Райт и Кшиштоф Наркович, инженеры, работающие над Lumen. Lumen — это полностью динамическая система глобального освещения и отражений Unreal Engine 5, которая включена из коробки. В этом сообщении блога мы познакомим вас с тем, как Lumen работает в Fortnite Battle Royale Chapter 4, и выделите улучшения, которые команда внесла в Lumen при выпуске главы 4 (которые теперь доступны всем разработчикам в Unreal Engine 5.1). Мы также написали более ранний технический блог, посвященный Lumen, который мы настоятельно рекомендуем прочитать для общего обзора системы.

Fortnite Battle Royale Глава 4 поставляется с включенным Lumen на Playstation 5, Xbox Series X и Xbox Series S. Lumen включается на ПК и в облачных играх, когда для параметра качества «Global Illumination» установлено значение «High» или «Epic». », с возможностью использовать аппаратную трассировку лучей для еще более высокого качества, если это поддерживается видеокартой.

Люмен в
Fortnite Battle Royale Глава 4

До главы 4 Fortnite был ограничен технологиями динамического освещения Unreal Engine 4 на консолях следующего поколения. Для окружающего освещения использовалось только окружающее затенение Distance Field, из-за чего в интерьерах было холодно, поскольку голубой свет в крыше просачивался в здания. В главе 4 Lumen рассчитывает глобальное освещение с высоким качеством, добавляя отражение теплого солнечного света и детализированные непрямые тени.

Окружающая окклюзия поля расстояния в зависимости от общего освещения люмена. Автоматическая экспозиция включается вместе с Lumen GI.

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

В более ранних версиях Fortnite отражения на консолях следующего поколения ограничивались отражениями в пространстве экрана (SSR). Этот эффект может отражать только то, что происходит на экране, чего недостаточно для предотвращения утечки светового люка внутри здания. SSR также дает хорошие результаты только на зеркальных поверхностях, поэтому грубые отражения отсутствовали. Художники Fortnite обходили эти ограничения, почти полностью избегая бликов на материалах, используемых в помещении! Lumen Reflections обеспечивает точную трассировку лучей на глянцевых поверхностях, правильно визуализируя металлы и гладкие материалы, даже когда они находятся в помещении. Художники теперь могут видеть полную реакцию материала на освещение в режиме реального времени.

Screen Space Reflections vs Lumen Reflections на льду.

Люмен Отражения также распространены на воде, где они намного четче, чем SSR, и не ограничиваются отражением того, что видно на экране.

Экранные космические отражения и световые отражения на воде.

В Fortnite Battle Royale есть много игровых событий, требующих динамического освещения — время суток будет меняться, игроки могут строить и разрушать строения, открывать двери и так далее. Lumen полностью динамичен и реагирует на эти изменения в режиме реального времени. Lumen действительно амортизирует свои вычисления для нескольких кадров, чтобы снизить затраты, но с высокой частотой кадров, на которую нацелена Fortnite , артефакты временного накопления сведены к минимуму.

Путешествие в главу 4

Когда мы завершили работу над выпуском Unreal Engine 5.0, наше внимание переключилось на Fortnite Battle Royale Глава 4 и ее проблемы. Fortnite нацелен на минимум 60 кадров в секунду на консолях, что составляет всего 16,67 миллисекунды на кадр или даже меньше с запасом для динамического разрешения и затрат на игровой процесс во время тяжелых боев. Учитывая все функции рендеринга, которые мы хотели, у нас было всего четыре миллисекунды для динамического глобального освещения и объединенных отражений. Это чрезвычайно маленький бюджет, так как в играх категории «ААА» обычно тратится четыре миллисекунды только на отражения с трассировкой лучей. Нам нужно было сделать каждую оптимизацию возможной, не ставя под угрозу качество освещения следующего поколения.

Первое, что нам нужно было решить, это какой метод трассировки лучей использовать для Fortnite Battle Royale Глава 4. Мы уже выпустили The Matrix Awakens: Unreal Engine 5 Experience с Lumen, использующим аппаратную трассировку лучей на консолях, сделав значительный оптимизации, но у этой технической демонстрации был бюджет в 30 кадров в секунду. После нескольких предварительных тестов мы определили, что программная трассировка лучей Lumen необходима для достижения бюджета в 60 кадров в секунду из-за более низких затрат на трассировку. Но приблизительный характер программной трассировки лучей создал несколько проблем, особенно в отношении качества листвы и отражений от воды.

Fortnite Battle Royale В главе 4 есть леса и холмы, покрытые травой. Ни в одном из предыдущих проектов, в которых мы отправляли Lumen, не было значительной листвы, поэтому у нас еще не было возможности поработать над этим. Одной из больших проблем была чрезмерная окклюзия на листве.

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

Чрезмерная окклюзия на листве решена с помощью полупрозрачных стохастических пересечений полей расстояний.

Некоторые проблемы решить было проще. Lumen использует трассировку экрана, чтобы добавить деталей там, где отсутствует программная трассировка лучей, но трава настолько детализирована, что эти трассировки экрана вносили значительный алиасинг. Чтобы устранить артефакты, было достаточно простого обходного пути, чтобы пропустить попадание трассировки экрана на листву.

Сильный шум от следов экрана на траве решается путем пропуска попаданий в листву.

Еще одной серьезной проблемой программной трассировки лучей было низкое разрешение освещения, кэшированного на поверхностях, видимых в отражениях. Lumen поддерживает Surface Cache с довольно высоким разрешением для каждой сетки, чтобы эффективно обеспечивать освещение для попаданий лучей, но мы объединяли их в вокселизированное представление, которое было намного более размытым. Мы разработали структуру обратного просмотра, которая позволила нам сэмплировать поверхностный кэш для каждой сетки непосредственно при попадании лучей, обеспечивая гораздо более точное эмиссионное освещение и более четкие отражения в воде.

Более четкие отражения благодаря программной трассировке лучей, когда лучи напрямую отбираются из Lumen’s Surface Cache (трассировки экрана отключены для визуализации).

Что касается отражений в воде, у нас были артефакты с вертикальными полосами везде, где экранные следы Lumen прерывались объектом переднего плана. Это невероятно отвлекало персонажа в движении. Экранные трассировки Lumen не знают, насколько толстый объект, поэтому нам приходится переключаться на программную трассировку лучей для остальной части луча, которая часто дает другой цвет. Это был регресс даже по сравнению с Screen Space Reflections, который использовал гораздо более дешевый, но менее точный метод пересечения лучей, но позволял продолжать работу за объектами переднего плана. Мы смогли устранить вертикальные полосы, сэмплируя цвет экрана даже для программной трассировки лучей, что уменьшает несоответствие. Этот появился в самый последний момент, поэтому он не был частью выпуска UE 5.1 .

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

Другие улучшения качества стали неожиданностью. Lumen GI сильно снижает частоту дискретизации, чтобы уложиться в бюджет в четыре миллисекунды. Это делает шум более заметным, отвлекая от игрового процесса. Нам удалось значительно снизить уровень шума за счет интеграции пространственно-временного синего шума NVIDIA, метода, который предварительно оптимизирует шаблоны шума для быстрого подавления при накоплении в нескольких кадрах. Это дало гораздо более чистое непрямое освещение, не требующее трассировки дополнительных лучей.

Освещение неба, проникающее в дверь, имеет меньше шума благодаря Пространственно-временному синему шуму.

Элементы управления художественным оформлением

У художников уже есть некоторые инструменты для создания прямого непрямого освещения, такие как «Интенсивность непрямого освещения» для направленного света. Художники Fortnite использовали значение 2.0, чтобы усилить отраженное освещение и сделать игру более теплой. Однако внутренние помещения представляли собой проблему: они становились очень темными при точном глобальном освещении, когда поблизости не было окон или источников света. Это вызвало огромные колебания экспозиции при переходе из помещения на улицу. Художники могли бы обойти это, разместив больше источников света, но это увеличило бы затраты на затенение.

Мы разработали новые элементы управления непрямым освещением Lumen: «Skylight Leaking» и «Diffuse Color Boost» для параметра Post Process Volume. «Протекание света в крыше» можно использовать для добавления небольшого количества окружающего освещения в помещении, ограничивая диапазон экспозиции, а «Рассеянное усиление цвета» можно использовать для усиления непрямого освещения с множественными отражениями. Ни один из этих вариантов не увеличивает затраты на GPU, в отличие от добавления большего количества источников света. Художники Fortnite в конечном итоге использовали просачивание светового люка, чтобы внутренние помещения не становились слишком темными для игровых целей.

Утечка светового люка используется для предотвращения полного затемнения областей.

Точное глобальное освещение создает высококонтрастное освещение, когда ни одно значение экспозиции не работает должным образом. Яркие области изображения, особенно небо и любые поверхности, освещенные солнцем, пересвечиваются, а темные области недоэкспонируются. Unreal Engine 5.0 представил новую функцию под названием Local Exposure, которую художников Fortnite использовали для сохранения деталей света и тени в этих сложных условиях освещения с высоким динамическим диапазоном.

Детали в светлых и теневых участках сохранены с помощью Local Exposure, новой функции UE 5.0. Локальная экспозиция всегда должна быть настроена при использовании Lumen!

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

Lumen в значительной степени полагается на Temporal Upsampling с Temporal Super Resolution (TSR) Unreal Engine 5 для вывода 4K. Внутренний рендеринг в разрешении 1080p с TSR обеспечивает наилучшее конечное качество изображения вместо изначального запуска Lumen в разрешении 4K со значительно более низкими настройками качества.

Lumen можно настроить на целевую скорость 60 кадров в секунду на консолях следующего поколения, установив для групп качества «Глобальное освещение» и «Отражение» значение «Высокое» в профиле устройства платформы:

; Установите Lumen GI и качество отражения на High, ориентируясь на 60 кадров в секунду. луча на пиксель. Непрямое освещение становится менее стабильным во времени при отслеживании столь малого количества лучей, а шум становится более заметным в темных областях. Утечка светового люка — полезный инструмент для сокрытия этого повышенного шума.

Люмен при настройках 60 кадров в секунду против Люмен при настройках 30 кадров в секунду. Lumen лучше фиксирует мелкие детали и гораздо более стабилен во времени при настройках 30 кадров в секунду, чего не видно при сравнении скриншотов.

Мы сделали множество мелких оптимизаций Lumen GI во время работы над Fortnite Battle Royale Глава 4, но самое большое ускорение было достигнуто за счет переноса всего метода на конвейер асинхронных вычислений, что позволило сэкономить 0,8 миллисекунды. У Lumen есть много диспетчеров вычислений для различных алгоритмов, между которыми GPU ненадолго простаивает, но они складываются.

Кроме того, отправка трассировки лучей имеет тенденцию иметь длинные хвосты, когда выполнение нескольких лучей занимает гораздо больше времени, чем остальные. Перенос этой работы в конвейер асинхронных вычислений позволяет графическому процессору заполнять пробелы остальной работой фрейма, более эффективно используя вычислительную мощность графического процессора. Async Lumen будет включен по умолчанию на консолях в UE 5.2, так как потребовались некоторые исправления, которые не успели сделать вовремя для UE 5.1.

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

Lumen Отражения масштабируются до бюджета 60 кадров в секунду за счет рендеринга с половинным разрешением, за исключением воды. Lumen GI уже производит грубые отражения, но Lumen Reflections необходимо проследить дополнительные лучи для резких отражений. Стоимость отражения может широко варьироваться в зависимости от того, какая часть экрана имеет достаточно гладкие материалы, чтобы нуждаться в отражении лучей. Одна из самых больших оптимизаций (одна-две миллисекунды) была связана с более частым пропуском лучей отражения на листве, которая уже имеет более высокие затраты в Base Pass и Shadow Depths и не вызывала заметной потери качества.

Xbox Series S представляет собой особую задачу. У него есть графический процессор с четырьмя терафлопами по сравнению с графическим процессором с двенадцатью терафлопами в Xbox Series X, поэтому требовалось более низкое внутреннее разрешение, но этого было недостаточно. Мы не хотели возвращаться к Distance Field Ambient Occlusion, который значительно меняет внешний вид. Вместо этого мы разработали режим, в котором Lumen GI обеспечивает грубые отражения, а Screen Space Reflections используются для зеркальных отражений. Это экономит около одной миллисекунды за счет отключения Lumen Reflections, но выглядит великолепно по сравнению с тем, чего можно было бы добиться, используя только Screen Space Reflections.

Lumen Global Illumination обеспечивает грубые отражения, даже если Lumen Reflections отключены для масштабируемости.

В конце концов, мы успешно вписали Lumen GI и Reflections в наш четырехмиллисекундный средний бюджет затрат на 60 кадров в секунду на консолях следующего поколения. Fortnite Battle Royale В главе 4 среднее внутреннее разрешение составляет 55–60 % от 4k на консолях нового поколения, при этом стабильно достигая 60 кадров в секунду.

Уменьшение масштаба

Fortnite поставляется на широкий спектр платформ, и только самые современные платформы поддерживают Lumen. Игровой опыт должен быть как можно более похожим, не требуя от художников повторного освещения для каждой платформы. Мы масштабируем окружающее освещение в соответствии с настройкой качества «Global Illumination»:

Epic и High.

  • Люмен включен, обеспечивая полное глобальное освещение
  • Используется утечка светового люмена, не позволяющая темным областям стать полностью черными
  • Автоматическая экспозиция включена для обеспечения правильной экспозиции в помещении
  • Локальное воздействие включено

Середина

  • Distance Field Ambient Occlusion включен вместо Lumen для крупномасштабного АО
  • Окружающая окклюзия экранного пространства включена для мелкомасштабного AO
  • Автоматическая экспозиция отключена

Низкий

  • Мансардное окно без тени
  • Интенсивность светового люка уменьшена с помощью r. SkylightIntensityMultiplier=0,7, чтобы лучше соответствовать среднему, так как отсутствует затенение мансардного окна

Мы надеемся, что этот обзор улучшений Lumen для Fortnite Battle Royale Глава 4 был полезен и ответил на вопросы о том, как выпускать кроссплатформенную игру с Lumen. Разработчики Unreal Engine могут получить доступ к подавляющему большинству этих улучшений уже в Unreal Engine 5.1. Для получения дополнительной информации ознакомьтесь с документацией Lumen.

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

НАЧНИТЕ СЕЙЧАС

Добавление нанитов в Fortnite Battle Royale в главе 4

Грэм Вихлидал, научный сотрудник отдела графики |

26 января 2023 г.

Особенности

Fortnite

Nanite

Программирование

Unreal Engine 5

Unreal Engine 5. 1

Привет, я Грэм Вилидал, инженерный совет (графики) в EPIC Games. Я здесь, чтобы продемонстрировать интересные функции и улучшения, которые мы разработали в этом году, чтобы запустить Nanite в Fortnite Battle Royale Глава 4. Эти функции доступны для опробования в Unreal Engine 5.1 (в виде бета-версии).

Unreal Engine 5.0 запущен с Nanite в состоянии готовности к производству. Его уже можно было использовать для множества удивительных вещей, но в начальной версии не было полной поддержки всего множества функций, доступных для не-нанитовых сеток. Вместо этого мы сосредоточили свое время на доработке основной функциональности Nanite.

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

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

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

Чтобы поддерживать вышеупомянутые функции в Nanite, нам нужно было сделать сам растеризатор программируемым .

Первоначальный прототип

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

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

Ваш браузер не поддерживает видео HTML5.

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

Мы определили несколько четких целей для развития этой работы:

  • Сохраняйте профиль производительности существующего быстрого пути «фиксированной функции» — введение программируемого растеризатора не должно замедлять существующий контент.
  • Убедитесь, что пути к фиксированным функциям и программируемым растеризаторам в значительной степени используют один и тот же путь кода, по соображениям удобства обслуживания.
  • Имейте в виду, что программируемый растеризатор будет интенсивно использоваться большим количеством контента, поэтому простые оценщики должны обеспечивать производительность, которая лишь незначительно ниже, чем у растеризатора с фиксированной функцией.
  • Выполните отбраковку экземпляров и кластеров только один раз.
  • Сведите к минимуму дополнительную нагрузку на память для сцены GPU и Nanite.
  • Предоставьте это как производственную функцию в UE 5.1.

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

Средневековая игра почти полностью преобразована в нанит!

Визуализация треугольника Nanite

Уникальные «контейнеры» (материалы) растеризатора в сцене

Даже с функциональной тестовой сценой Medieval Game оставалось много работы по оптимизации и доработке функций, чтобы сделать Nanite Programmable Rasterizer framework поставляемым в игре .

Очень рано стало ясно, что Fortnite Battle Royale Глава 4 хочет использовать нанит, но мы еще не поддерживали необходимые функции, необходимые для массового внедрения. Даже, казалось бы, простые сетки, такие как непрозрачные строительные элементы, нуждались в смещении мировой позиции, чтобы анимировать культовый эффект «отскока» при повреждении. Fortnite стал первым пользователем программируемого растеризатора.

Fortnite вариантов использования
Анимированный реквизит

Первый поддерживаемый вариант использования — это простые непрозрачные статические реквизиты сетки, которые используют смещение мировой позиции для вторичной анимации. Хотя эти реквизиты не требуют эффективного рендеринга Nanite, производительность Virtual Shadow Map намного лучше масштабируется с сетками Nanite, поэтому было важно визуализировать как можно большую часть сцены с использованием Nanite.

Ваш браузер не поддерживает видео HTML5.

Ваш браузер не поддерживает видео HTML5.

Здания
Важным аспектом Fortnite являются различные строительные наборы, и уже было доказано, что Nanite с легкостью справляется с большими городами. Неудивительно, что мы решили использовать Nanite для всех строительных сеток — чтобы повысить визуальную точность, устранить всплывающие окна уровня детализации и повысить производительность.

Строительство

В 9 слишком много сеток зданий.0015 Fortnite , чтобы восстановить их все с нуля на всех платформах, поэтому мы создали автономный процесс, который может использовать созданные художником текстуры и правила смещения и создавать высококачественные смещенные нанитовые сетки с гораздо большим количеством треугольников, чем в традиционных версиях.

Примечание. Это не смещение во время выполнения, а специальный автономный рабочий процесс Fortnite для создания смещенной сетки.

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

Все здания в Fortnite представляют собой непрозрачные статические сетки и могут быть полностью визуализированы с помощью нашего набора функций Nanite, доступного в Unreal Engine 5.0, за исключением эффекта «колебания», который возникает временно, когда часть здания получает повреждения (например, игрок бьет его киркой).

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

Благодаря значительному количеству строительных сеток в Fortnite мы реализовали оптимизацию для этого шаблона, в котором можно включить специальный режим ( r.OptimizedWPO ), а затем независимо от того, имеет ли материал логику для управления Смещение мирового положения, Nanite будет оценивать эту логику только в том случае, если для данного примитивного компонента включена функция «Оценивать смещение мирового положения» (настройка по умолчанию).

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

Эта оптимизация оказалась полезной во многих местах (включая отключение смещения положения мира на расстоянии), но она была жизненно важна для раскачивания здания. Мы отключили «Оценивать смещение положения в мире» по умолчанию для всех моделей зданий и изменили код игры в Fortnite , чтобы программно установить это значение в зависимости от того, повреждено ли здание в данный момент (и качается).

Наряду с этой новой оптимизацией мы добавили представление отладки Nanite «Оценить WPO» ( r.Nanite.Visualize EvaluateWPO ), который показывает зеленый цвет, если сетка в данный момент оценивает смещение мировой позиции, и красный – в противном случае.

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

Пример снимка

r.OptimizedWPO выкл. и вкл.

Деревья
Больше всего времени на прототипирование и разработку мы потратили на деревья. Для главы 4 нам нужны были густые леса, поэтому нам нужно было эффективное решение с предсказуемой производительностью. Деревья основывались на совершенно новой функциональности Nanite, которую мы никогда раньше не добавляли в игру, поэтому было проведено много работы по прототипированию и оптимизации, чтобы определить подход, который мы в конечном итоге будем использовать.

Строительство
Наши первоначальные эксперименты проводились с использованием замаскированных материалов и карт для деревьев.

Для контента Fortnite мы обнаружили, что обычно быстрее избегать маскированных материалов и вместо этого полагаться на увеличение количества треугольников сетки и сохранение непрозрачности материалов, особенно для деревьев и травы. В основном это связано с тем, что замаскированные материалы в Nanite несут значительные затраты во время затенения базового прохода, поскольку нам приходится пересчитывать барицентрики треугольников на пиксель, а отрицательное пространство в альфа-картах добавляет дополнительные затраты на перерисовку.

Заповедник

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

Чтобы исправить это, мы добавили новую логику в конструктор нанитов (опция «Сохранить область», которую можно включить в сетке «Настройки нанитов»), которая перераспределяет потерянную область на оставшиеся треугольники, расширяя открытые граничные края. В случае листьев это то же самое, что и остальные листья, которые становятся больше. Хотя это выглядит странно, если выполняется вблизи, на расстоянии, когда активируется сохранение области, вместо этого кажется, что поддерживается плотность, которая должна быть там.

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

Ваш браузер не поддерживает видео HTML5.

Без области сохранения

Ваш браузер не поддерживает видео HTML5.

С заповедником

Анимация ветра
Было бы странно, если бы все деревья отображались с высокой точностью, но не анимировались на ветру. Традиционно Fortnite выполняла анимацию ветра со сложной логикой, управляющей смещением мировой позиции. Учитывая, что у нанитовых деревьев значительно больше вершин (~300-500 тыс.), чем у их не-нанитовых аналогов (~10-20 тыс.), а логика мирового положения теперь оценивается внутри растеризатора нанитов, мы исследовали другие способы анимации деревьев в способом, который снизил стоимость оценки каждой вершины.

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

Из геометрии дерева мы можем извлечь опорную точку каждой ветви и уровень в иерархии, а также родительскую ветвь каждой ветви. Мы можем сделать скелет из этой информации и ввести его в симуляцию Houdini Vellum.

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

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

Отбор по расстоянию
Симуляция ветра на деревьях очень важна вблизи камеры, но почти неразличима на расстоянии. В качестве оптимизации производительности мы добавили для Nanite возможность отключать вычисления смещения положения в мире на расстоянии, определяемом художником. Эта оптимизация основана на режиме «Оценить смещение мировой позиции».

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

Ваш браузер не поддерживает видео HTML5.

Ваш браузер не поддерживает видео HTML5.

Пейзаж (нанит)

Из-за особенностей работы виртуальных карт теней большие не-нанитовые сетки отрисовывают тени гораздо медленнее, чем нанитовые сетки того же размера. Это было особенно проблематично для ландшафта, который представляет собой массивную сетку без нанитов, которая требует много времени GPU. Мы реализовали экспериментальную функцию рендеринга Nanite для ландшафта, выпущенную в UE 5.1, которая преобразует поле высоты ландшафта в сетку Nanite во время сборки. Преобразование не повышает визуальное качество, но обеспечивает все характеристики производительности отбраковки и растеризации нанитов при рендеринге в базовый проход или виртуальные карты теней.

У Lumen есть специальный путь для отслеживания по полю высоты ландшафта, а Nanite в настоящее время не поддерживает рендеринг в виртуальные текстуры среды выполнения, поэтому в этих случаях представление Nanite не используется, а вместо него используется поле высоты.

Будущая работа

Возможно, наиболее важной оставшейся вещью является точное (покадровое) вычисление экземпляра и ограничивающего объема кластера, которое соответствует анимации, выполняемой World Position Offset. Это жизненно важно для того, чтобы отбраковка окклюзии Nanite удаляла как можно больше кластеров перед растеризацией.
 

Ваш браузер не поддерживает видео HTML5.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *