Интеграция Nvidia DLSS и профессиональные рабочие процессы в студиях на базе Unreal Engine 5 для AA-проектов

Введение в продвинутые архитектуры рендеринга и потребность в масштабировании

В современной индустрии видеоигр AA-студии (дважды А), не обладая бюджетами уровня AAA и командами из сотен людей, но стремясь достичь высоких целей в области визуального качества, выступают в роли наиболее активных пользователей технологических инноваций. Выпуск игрового движка Unreal Engine 5 (UE5) раздвинул границы фотореализма благодаря системе виртуальной геометрии Nanite и решению для полностью динамического глобального освещения (Global Illumination) Lumen. Однако эти революционные технологии создают огромную вычислительную нагрузку на графические процессоры (GPU). 1 Технология Lumen для достижения цели в 60 кадров в секунду (FPS) вынуждена снижать внутреннее разрешение до уровня, значительно меньшего по сравнению с родным (native) разрешением экрана (например, внутренний рендеринг в разрешении 1080p на экране 4K). 1 В этой точке стандартным в индустрии способом преодоления аппаратных ограничений и многократного повышения производительности при сохранении визуальной точности являются алгоритмы реконструкции изображений (image reconstruction) на базе искусственного интеллекта. Архитектура Deep Learning Super Sampling (DLSS) от Nvidia, являющаяся лидером индустрии в этой области, вместо масштабирования пикселей традиционными пространственными (spatial) методами представляет собой сложную технологию, синтезирующую недостающие пиксели с помощью нейронных сетей с использованием векторов движения (motion vectors) и буферов глубины (depth buffers), полученных из последовательных кадров. 3 Для профессиональной AA-студии добавление DLSS в проект — это не просто процедура активации плагина, а многомерная инженерная задача, требующая полной синхронизации конвейера рендеринга (render pipeline), управления исходным кодом, процессов обеспечения качества (QA) и рабочих процессов художников. В этом отчете подробно рассматривается то, как архитектуры DLSS 3.5, DLSS 4 и Streamline SDK интегрируются в проекты на базе Unreal Engine 5 в профессиональной среде.

Фреймворк Streamline SDK и архитектурные основы

Nvidia разработала Streamline SDK с целью модернизации интеграции DLSS и снижения нагрузки по интеграции с плеч разработчиков игр. Streamline — это открытый и не зависящий от производителей оборудования (IHV) фреймворк, который функционирует в качестве промежуточного (interposer) слоя между игровым движком и API рендеринга, такими как DirectX 11, DirectX 12 или Vulkan. 6

В прошлом разработчики были вынуждены писать отдельные ручные вызовы API (hooks) в конвейер рендеринга игрового движка для каждой технологии масштабирования (upscaling), такой как Nvidia DLSS, AMD FidelityFX Super Resolution (FSR) и Intel XeSS. 6 Архитектура Streamline сводит этот процесс к единой точке интеграции. Разработчик один раз помечает такие ресурсы, как векторы движения, буферы глубины и буферы цвета пользовательского интерфейса (UI), и передает эти данные во фреймворк Streamline. 6 Streamline использует эти данные для запуска всех поддерживаемых плагинов масштабирования на соответствующем этапе графического конвейера.

Жизненный цикл интеграции Streamline на уровне C++ и движка

Инициализация и управление Streamline SDK должны происходить на самых ранних этапах загрузки движка. Процесс инициализации выполняется с помощью функции slInit до вызова каких-либо API DirectX или Vulkan. 8 В этот момент движок загружает поддерживаемые и запрашиваемые функции, но еще не инициализирует их. Полная работоспособность функций запускается при создании движком устройства (device) API рендеринга. 9 Следующая структура демонстрирует, как библиотека Streamline инициализируется на C++:

#include <sl.h>
#include <sl_consts.h>
#include <sl_dlss.h>

sl::Preferences pref{}; 
pref.showConsole = false;  
pref.logLevel = sl::eLogLevelDefault; 
pref.applicationId = myId;  
pref.engineType = sl::eEngineTypeUnreal;  

if (SL_FAILED(res, slInit(pref))) { 
    if (res == sl::Result::eErrorDriverOutOfDate) { 
        
    } 
} 

Протоколы безопасности на этом этапе имеют важнейшее значение. Профессиональные студии обязаны проверять двойные цифровые подписи Nvidia и Streamline файла sl.interposer.dll для предотвращения создания читов (DLL hijacking) в многопользовательских играх. 6 Перед переходом на этап выпуска (Shipping) библиотеки с водяными знаками (watermarked), использовавшиеся в процессе разработки, обязательно заменяются на готовые к производству подписанные библиотеки. 6

Эволюция технологии DLSS и ее модульная структура

В среде Unreal Engine 5 DLSS — это не отдельная функция, а пакет технологий. 3 Студии принимают решение о том, какие модули этого пакета использовать, в зависимости от характера проекта:

1. DLSS Super Resolution (SR): Базовая форма повышения разрешения. Используя тензорные ядра, она генерирует высококачественный и детализированный выходной сигнал из входных данных с низким разрешением. 3

2. DLSS Frame Generation (FG): Представленная вместе с DLSS 3, эта функция с помощью искусственного интеллекта синтезирует абсолютно новый кадр между двумя реально отрендеренными кадрами. Она способна удвоить производительность, преодолевая традиционные узкие места процессора (CPU). 6

3. DLSS Multi Frame Generation: Новейшая функция, представленная с графическими процессорами серии RTX 50 и DLSS 4. Она обладает способностью генерировать до 3 искусственных кадров на каждый обработанный кадр. 10

4. DLSS Ray Reconstruction (RR): Модель искусственного интеллекта, которая в сценах с использованием трассировки лучей (Ray Tracing) и трассировки путей (Path Tracing) заменяет традиционные средства шумоподавления (denoiser) с ручной настройкой и обеспечивает гораздо более высокую временную (temporal) стабильность. 3

5. Nvidia Reflex: Технология с низкими задержками, синхронизирующая очереди процессора (CPU) и графического процессора (GPU) для компенсации временной задержки обработки (latency), создаваемой функцией Frame Generation. Поставляется напрямую с плагином Streamline. 6

Профессиональные рабочие процессы студий: Perforce, контроль версий и процессы сборки

В то время как независимые (Indie) разработчики обычно управляют своими проектами на локальных дисках или с помощью простых облачных инструментов синхронизации, сложные файловые структуры AA- и AAA-студий делают обязательным использование систем контроля версий стандартного для индустрии уровня. Проекты Unreal Engine состоят из бесчисленных бинарных файлов (binary assets), размер которых часто достигает десятков терабайтов и которые не являются текстовыми.

Почему Perforce (Helix Core) вместо Git?

Несмотря на то, что Git является де-факто стандартом в мире программного обеспечения, подавляющее большинство профессиональных игровых студий предпочитает инфраструктуру Perforce (Helix Core). 13 Git по своей природе является распределенной (distributed) системой и, хотя он прекрасно справляется с текстовыми операциями слияния (merge) кода, он не предназначен для работы с большими бинарными файлами. 15 Даже если плагин Git LFS (Large File Storage) используется в качестве заплаты, он представляет собой абстрактный и сложный опыт для художников. Самым критическим преимуществом Perforce является его централизованная структура и функция «Exclusive Checkout» (Эксклюзивное извлечение). Когда художник по окружению работает над гигантской картой Unreal Engine (.umap) или файлом анимации персонажа, он блокирует файл через Perforce. Это предотвращает одновременное внесение изменений другими художниками в тот же файл, сводя к нулю неразрешимые конфликты бинарных файлов. 16 Кроме того, благодаря встроенной интеграции в игровой движок, Perforce позволяет осуществлять версионирование материалов или правок текстур напрямую из интерфейса движка (in-engine). 13

Пользовательские сборки движка (Custom Engine Builds) и интеграция DLSS

AA-студии редко используют стандартные предварительно скомпилированные (pre-compiled) версии движка, предлагаемые через Epic Games Launcher. Они собирают движок из исходного кода (source) для выполнения оптимизаций на уровне C++ в соответствии с конкретными потребностями игры, изменения управления памятью или подключения глубоких плагинов, таких как Streamline. 17 Интеграция DLSS начинается именно с этой интеграции исходного кода на C++. Nvidia размещает свои модифицированные ветки Unreal Engine на GitHub. 19 В процессе интеграции разработчик в роли «Build Engineer» студии выполняет следующие шаги:

1. Клонируется специфическая ветка плагина из репозитория Nvidia (например, dlss3/sl2-5.1-dlss-plugin или актуальная ветка для соответствующей версии UE). 20

2. Хуки (hooks) Streamline объединяются (merge) с основным (main) репозиторием кода движка студии. 19

3. Если используется новейшая версия движка (например, 5.5.1) и официальная поддержка DLSS еще не выпущена, студия обязана интегрировать созданные сообществом неофициальные патчи (unofficial patches) в кодовую базу и пройти с этим кодом тесты на стабильность. 21

Непрерывная интеграция (CI/CD) и конвейеры развертывания

После объединения исходного кода движка и плагинов в дело вступает автоматизация, призванная избавить художников и дизайнеров от необходимости ожидать сборки движка в течение нескольких часов каждое утро. Инструменты непрерывной интеграции (CI/CD), такие как Jenkins, GitHub Actions или система Horde от Epic Games, автоматически пересобирают Unreal Engine с нуля на облачных серверах или локальных сборочных фермах (build farms) при каждом важном изменении кода в репозитории Perforce. 22 Когда сборка завершена, получающиеся гигантские бинарные файлы (Binaries) распространяются среди команды через Perforce или с помощью специализированных внутренних инструментов. 22 В этом процессе правила p4ignore или синтаксиса Perforce должны быть настроены чрезвычайно точно. Библиотеки динамической компоновки (DLL) Streamline, такие как sl.interposer.dll и nvngx_dlss.dll, хранятся в системе контроля версий, в то время как временные файлы кэша скомпилированных данных (Derived Data Cache — DDC), образующиеся на машинах разработчиков, не должны отправляться в репозиторий. 18 Это предотвращает раздувание репозитория и избыточный сетевой трафик.

Проблемы оптимизации в конвейере рендеринга и их решения

Добавление плагина DLSS в проект (активация через меню Edit -> Plugins) — это лишь самый простой шаг процесса. 19 Основные инженерные усилия тратятся на те моменты, когда модель искусственного интеллекта конфликтует со сложными проходами рендеринга (render passes) в Unreal Engine 5.

Конфликты между Temporal Anti-Aliasing (TAA) и Temporal Super Resolution (TSR)

Unreal Engine 5 использует разработанный самой Epic Games алгоритм Temporal Super Resolution (TSR) в качестве решения для повышения разрешения (upscaling) по умолчанию. 24 И TSR, и DLSS являются временными (temporal) алгоритмами, которые генерируют новые кадры, оценивая данные из предыдущих кадров (history frames). Их одновременная работа не только исчерпывает пропускную способность графического процессора, но и приводит к «борьбе» за аппаратные ресурсы, порождая тяжелые визуальные артефакты. 25 При включении DLSS в профессиональных рабочих процессах TSR должен быть немедленно отключен. Когда разработчики настраивают режимы качества через Blueprint или C++, DLSS автоматически перезаписывает (override) и отключает встроенную настройку процента экрана движка (r.screenpercentage). 25 Это избавляет разработчика от необходимости вручную вычислять процент экрана.

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

Векторы движения (Motion Vectors) и проблема размытия призраков (Ghosting)

Самым большим слабым местом алгоритмов реконструкции на основе искусственного интеллекта являются артефакты призрачных следов (ghosting) и размазывания (smearing). DLSS запрашивает у конвейера рендеринга векторы движения (Motion Vectors) в составе G-Buffer, чтобы отслеживать движение объектов. Если объект движется на экране, но не генерирует векторы движения, DLSS предполагает, что пиксели этого объекта остаются неподвижными. Когда рисуется новый кадр, данные старого кадра продолжают оставаться на экране и оставляют длинный след (хвост) позади объекта.

Устранение ошибок смещения в мировом пространстве (WPO) и растительности (Foliage)

В Unreal Engine 5 с этой проблемой чаще всего сталкиваются деревья и трава с эффектом ветра. В целях оптимизации движок по умолчанию не генерирует векторы движения для растительности, которая использует анимацию вершин (vertices) на базе GPU с помощью узлов шейдера WPO (World Position Offset).

Для решения этой хронической проблемы технические художники (Technical Artists) студий AA глубоко вмешиваются в конфигурационные файлы движка (DefaultEngine.ini). Прежде всего, в панелях деталей движущихся WPO-материалов обязательно нужно включить параметр «Support Accurate Velocities from Vertex Deformation». Затем для принудительного запуска прохода рендеринга используются следующие консольные переменные (CVars):

• r.BasePassForceOutputsVelocity=1: Принудительно заставляет базовый проход рендеринга (Base Pass) в любых условиях выдавать данные скорости (velocity). Это действие в значительной степени уничтожает появление призрачных следов, но имеет свою цену для производительности, поскольку увеличивает пропускную способность памяти GPU.

• r.NGX.DLSS.DilateMotionVectors=1: Обеспечивает расширение векторов движения наружу от краев объектов. Это позволяет DLSS лучше захватывать пиксели в сценах с тонкой геометрией (листья, провода).

• r.Shadow.Virtual.NonNanite.IncludeInCoarsePages=0: Движения на основе WPO постоянно инвалидируют кэш виртуальных карт теней (Virtual Shadow Maps — VSM), что приводит к колоссальному падению производительности. Эта команда возвращает производительность, исключая растительность без Nanite из грубых теневых страниц.

Управление моделями искусственного интеллекта: пресеты DLSS

Сила DLSS заключается в предложении различных моделей искусственного интеллекта, которые непрерывно обучаются на суперкомпьютерах NVIDIA. Разработчики могут выбирать разные модели, зашитые внутри файла nvngx_dlss.dll, в зависимости от специфического визуального стиля игры. Эти настройки называются пресетами J, K, L и M.

Например, в игре на базе чистой растеризации (без трассировки лучей) предпочтителен пресет M, который увеличивает производительность и одновременно снижает появление призрачных следов. Пресет M обеспечивает максимальную производительность на сериях RTX 40 и выше, но на предыдущих поколениях может вызывать проблемы со стабильностью. С другой стороны, если игра содержит интенсивную трассировку лучей (Ray Tracing) или активна функция DLSS Ray Reconstruction, пресет M может сделать изображение слишком зашумленным (noisy); в таких сценариях использование пресета K значительно повышает стабильность изображения.

Буферы пользовательского интерфейса (UI) и порядок постобработки

Даже если трехмерный мир игры отрендерен безупречно, двухмерные элементы HUD поверх экрана или 3D-виджеты, размещенные в игровом мире (World Space), могут быть разрушены функцией DLSS Frame Generation.

Механизм цвета и альфа-канала пользовательского интерфейса (TagUIColorAlpha)

При генерации искусственных кадров функция Frame Generation воспринимает экран как целостный холст. Если полоса здоровья или счетчик патронов игры находятся в углу экрана, а камера под ними вращается, алгоритм FG смещает и искажает пиксели интерфейса вместе с движением камеры. Это приводит к сильному мерцанию и размытию интерфейса.

Чтобы решить эту критическую проблему, NVIDIA добавила в плагин Streamline специальный механизм буферизации пользовательского интерфейса. Эта система вступает в работу сразу после того, как игровой движок отрендерил слой UI (но до его вывода / презентации на экран):

1. Разделение (Separation): Разработчик изолирует пиксели UI, активируя команду r.Streamline.TagUIColorAlpha=1.

2. Определение порогового значения: С помощью r.Streamline.TagUIColorAlphaThreshold пиксели, значение альфа-канала которых выше определенного уровня, получают метку «Это элемент пользовательского интерфейса, не включайте его в процесс генерации кадров» (значение по умолчанию — 0.0).

3. Объединение (Composite): Функция Frame Generation работает только с 3D-миром, генерирует искусственные кадры, а на последнем шаге изолированный слой UI накладывается поверх этих кадров с исходной четкостью.

Главная ловушка для разработчиков здесь заключается в использовании устаревшего метода UWidgetBlueprintLibrary::DrawText вместо виджетов UMG. Поскольку эта функция не производит запись в альфа-канал, она не может быть распознана Streamline как интерфейс и приводит к искажениям на экране. Аналогичным образом, если для 3D-виджетов в игровом мире режим смешивания материала (blend mode) изменить с Masked на Translucent (Полупрозрачный), можно уменьшить размытие, вызванное TSR и DLSS.

Расположение эффектов постобработки (Post-Processing)

Эффекты постобработки, такие как «Зернистость пленки» (Film Grain), «Хроматическая аберрация» (Chromatic Aberration), «Блик объектива» (Lens Flare) и «Глубина резкости» (Depth of Field), призванные имитировать эстетику кинематографа, являются главными врагами средств масштабирования изображений на основе искусственного интеллекта.

DLSS обучен брать чистое изображение и масштабировать его до более высокого разрешения. Если в конвейере рендеринга до выполнения DLSS в изображение добавляется искусственный шум зернистости пленки, нейронная сеть DLSS воспринимает это зерно как «ошибку» или «артефакт низкого разрешения». Алгоритм пытается сгладить (denoise) эти зерна, в результате чего изображение становится мутным.

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

Контроль качества (QA), профилирование и валидация производительности

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

Продвинутые инструменты профилирования и чтение метрик

Ориентироваться при оптимизации только на счетчик FPS может быть обманчиво. Unreal Engine не знает о дополнительных кадрах, полностью созданных с помощью искусственного интеллекта функцией Frame Generation. В ситуации, когда движок показывает производство 60 кадров в секунду, железо на самом деле может выдавать монитору 120 кадров.

Поэтому студии AA вместо стандартного stat fps используют следующие специальные инструменты и команды:

• stat dlssg: Эта консольная команда выводит на экран реальную частоту кадров с учетом сгенерированных искусственных кадров, а также вычислительную нагрузку (overhead) Frame Generation на видеокарту в миллисекундах (мс).

• Unreal Trace Insights & GPU Profiler: Изучает узкие места в конвейере рендеринга с точностью до микросекунды. Детализирует, сколько времени занимает каждый проход рендеринга (Base Pass, VisBuffer, Lighting). Время Nanite VisBuffer и HZB (Hierarchical Z-Buffer) оптимизируется здесь.

• Nvidia FrameView SDK и ICAT: Команды QA, измеряющие задержки и энергопотребление оборудования с помощью FrameView, одновременно проводят A/B тесты с использованием Nvidia ICAT (Image Comparison and Analysis Tool). Эти инструменты используются для обнаружения микроскопических потерь качества на сетке-рабице, волосах или деталях дальнего плана между нативным разрешением и разрешением DLSS.

Контрольный список проверки интеграции (QA Checklist)

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

Большая часть этих тестов не может быть выполнена внутри Unreal Editor. Функция Frame Generation имеет серьезные ограничения при работе в нескольких окнах PIE (Play-In-Editor) или в выбранном окне просмотра (viewport). Для получения достоверного профилирования и действительных результатов QA обязательно запускать игру в режиме «Standalone Game» или в скомпилированном виде непосредственно дистрибутивного пакета (Shipping Build).

Окончательная оценка

Интеграция Nvidia DLSS в проектах AA на базе Unreal Engine 5 — это не просто настройка в меню, а всеобъемлющий технологический мост, простирающийся до базовой архитектуры игрового движка, исходного кода и стратегий контроля версий студии. Студии преодолевают кризисы с большими бинарными файлами с использованием таких отраслевых стандартов, как Perforce, в то время как с помощью систем CI/CD они автоматизируют сборки кастомных движков, внедряя Streamline SDK в собственную инфраструктуру. 20

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

*Информация: Изображения были сгенерированы Google Gemini.