Архитектура Unreal Engine 5 Nanite: Комплексный технический анализ, стратегии оптимизации и руководство по разработке для PlayStation 5
Основы виртуализированной геометрии микрополигонов и смену парадигмы
Одной из самых больших проблем на протяжении десятилетий в индустрии технологий рендеринга в реальном времени (real-time rendering) и компьютерной графики являются неизбежные узкие места, создаваемые бюджетами полигонов и количеством вызовов отрисовки (draw call) в связи между центральным процессором (CPU) и графическим процессором (GPU) ради эффективного использования аппаратных ресурсов. 1 В традиционных рабочих процессах разработки игр 3D-художникам и техническим руководителям приходилось вручную выполнять оптимизацию топологии, создавать цепочки «Level of Detail» (LOD) и запекать (baking) детали высокого разрешения в карты нормалей (Normal Map), чтобы переносить детализированные модели (например, кинематографические скульптуры ZBrush, лазерные сканы или данные фотограмметрии) в игровые движки. 1 Этот процесс создавал тяжелую рабочую нагрузку, которая не только увеличивала график производства, но и загоняла уровень детализации на экране в искусственный лимит из-за ограничений памяти. 1 Технология Nanite, ставшая отраслевым стандартом вместе с Unreal Engine 5 (UE5), представляет собой систему виртуализированной геометрии микрополигонов (virtualized micropolygon geometry), которая в корне устраняет эти традиционные препятствия. 1 Nanite превращает бюджеты полигонов из технического ограничения, позволяя напрямую переносить в сцену исходные файлы, состоящие из миллиардов полигонов кинематографического качества, в реальном времени и без необходимости каких-либо ручных операций с LOD. 1 Система разработана так, чтобы обрабатывать на экране только те детали, которые в данный момент могут быть видны камерой игрока; ни один треугольник или фрагмент геометрии меньше размера пикселя не рендерится без необходимости. 3 Эта технология заменяет традиционный конвейер рендеринга (rendering pipeline) архитектурой потоковой передачи (streaming) данных, полностью ориентированной на GPU, предоставляя постоянную, плавную и непрерывную автоматическую систему LOD. 1 Основные инновации Nanite делятся на четыре основных направления 1:
Виртуализированная геометрия: Вся сцена обрабатывается как один гигантский статический меш (mesh), и в обработку включаются только те части, которые видны на экране.
Автоматический уровень детализации (LOD): Вместо ступенчатых и резких изменений LOD (LOD popping) обеспечивается бесшовное и плавное изменение детализации в зависимости от расстояния и разрешения экрана.
Конвейер (Pipeline), ориентированный на GPU: Вызовы отрисовки (draw calls) и операции отсечения (culling) забираются у CPU и передаются параллельной вычислительной мощности GPU.
Эффективная потоковая передача (Efficient Streaming): Потоковая передача данных в память осуществляется напрямую через SSD, благодаря чему в память мгновенно загружаются только необходимые геометрические данные.
В данном исследовательском отчете в рамках комплексной аналитической структуры рассматриваются принципы углубленной работы системы Nanite, необходимые шаги для интеграции в проект, требования к оптимизации, способы преодоления узких мест и особенности динамики разработки игр для платформы PlayStation 5 (PS5), обладающей уникальным сжатием на аппаратном уровне и высокоскоростной потоковой передачей данных (I/O).
Техническая архитектура Nanite и структуры данных
Философия, лежащая в основе системы Nanite, заключается не в том, чтобы рассматривать геометрические данные как гигантские статические меши (static meshes), которые пытаются уместить в ограничения памяти, а в том, чтобы обрабатывать их как фрагментированные наборы данных, которые динамически передаются в потоковом режиме (streaming) и управляются по запросу, как и в случае с виртуальными тектурами (virtual texturing). 3 В то время как традиционные движки пытаются загрузить в память и обработать весь объект целиком, даже если видна лишь небольшая его часть в поле зрения камеры (frustum), Nanite оценивает эту видимость с точностью до миллиметрового пикселя. 3
Иерархическая структура кластеров (Hierarchical Cluster Structure)
На этапе импорта (import) алгоритмы Nanite анализируют 3D-модели и разбивают их на иерархические деревья кластеров (cluster). 1 Каждый обрабатываемый статический меш разбивается на небольшие пакеты данных (cluster), состоящие ровно из 128 треугольников для достижения наилучшей производительности на аппаратном уровне. 1 Этот фиксированный размер в 128 треугольников — оптимальная единица, специально выбранная для максимального использования эффективности обработки блоков параллельных вычислений и пределов кэша (cache limits) за счет полного соответствия размерам волнового фронта (wavefront) или warp современных GPU. 1 Эти кластеры формируют между собой древовидную структуру данных (Tree Data Structure), похожую на направленный ациклический граф (Directed Acyclic Graph — DAG), которая содержит информацию о ограничивающих параллелепипедах (bounding box), метрики геометрических ошибок для выбора LOD в пространстве экрана (screen space) и отношения родитель-потомок (parent-child). 1 По мере приближения или отдаления камеры от соответствующего объекта система перемещается по этой древесной структуре в реальном времени, решая, какой кластер лучше всего соответствует плотности пикселей на экране для каждой области экрана. 1 В отличие от традиционных подходов, весь объект не меняется внезапно. Вместо резкого изменения LOD различные области на поверхности объекта могут обрабатываться на разных уровнях детализации кластеров одновременно и плавно соединяться по краям таким образом, чтобы не создавать никаких визуальных разрывов или трещин (crack) при аппаратной растеризации. 3
Буфер видимости (Visibility Buffer) и развязанное затенение
Самая критическая структура, которая позволяет Nanite преодолевать узкие места CPU и совершает революцию в современных архитектурах рендеринга, заключается в переносе большей части конвейера рендеринга (pipeline) непосредственно на GPU и замене традиционной логики прямого (Forward) или отложенного (Deferred) затенения (shading) на «Visibility Buffer» (Буфер видимости). 1 Концепция буфера видимости в цикле рендеринга Nanite работает следующим образом: в традиционных структурах G-Buffer при вычислении пикселей огромные объемы данных, такие как цвет, нормали и шероховатость (roughness), записываются в память для каждого пикселя. Вместо этого Nanite сохраняет для каждого пикселя на экране идентификационный номер (Primitive ID и Cluster ID) размером всего 32 или 64 бита. 1 Этот буфер памяти не содержит данных о цвете или затенении, он представляет собой лишь справочную карту, указывающую, какой треугольник и какой кластер видны в этом конкретном пикселе на экране. 1 После полного заполнения буфера видимости данные материалов вызываются только один раз для каждого пикселя в пространстве экрана, и выполняется процесс затенения. Благодаря этой «развязанной» (decoupled) архитектуре вычисления материалов не выполняются впустую для миллионов треугольников, которые остаются позади камеры, спрятаны за другим объектом или не вносят никакого вклада в финальное изображение. Эта ситуация полностью устраняет проблему «Overdraw» (избыточного рисования), являющуюся одним из главных врагов GPU, на базе вычислений материалов. 9
Механизмы отсечения (Culling), ориентированные на GPU
Операции отсечения (culling) в архитектуре Nanite выполняются не на базе объектов (actor), как в традиционных движках. Традиционная подготовка вызовов отрисовки на стороне CPU полностью обходится, и процесс отсечения передается непосредственно вычислительным шейдерам (compute shaders) внутри GPU. 10 На этапе перекрытия и отсечения (Occlusion Culling) Nanite использует структуру под названием HZB (Hierarchical Z-Buffer), в которой логарифмически сохраняются различные уровни глубины (mipmaps) в пространстве экрана. 9 HZB сравнивает ограничивающий параллелепипед (bounding box) каждого кластера из 128 треугольников с данными глубины в пространстве экрана. 9 Если кластер остается за другим объектом на сцене, он немедленно отбрасывается от рендеринга. Это отсечение настолько точно и выполняется на уровне кластеров, а не объектов, что при отсечении кластеров деревьев в огромном лесу, находящихся позади массивной горы, кластеры листьев, выступающие из-за вершины горы, продолжают обрабатываться. 8
Пути растеризации: Динамика программной и аппаратной обработки
Вместо использования единого обрабатывающего блока для преобразования треугольников в пиксели экрана (растеризация), Nanite использует два отдельных пути растеризации (raster path), решение о выборе которых принимается динамически в зависимости от размера треугольника на экране и свойств материала. 9 Оптимизация производительности зависит от идеального баланса между этими двумя путями.
Программная растеризация (Software Raster Path)
Программная растеризация — это самый эффективный, быстрый и инновационный основной путь обработки Nanite. 9 Этот путь вступает в силу, когда треугольники меньше одного пикселя (субпиксельные) или имеют точный размер в один пиксель на экране. 9 В этом сценарии Nanite полностью обходит аппаратные блоки отрисовки треугольников GPU и выполняет процесс через «Compute Shader» (Вычислительные шейдеры). С помощью 64-битных атомарных операций (atomic interlocks) обеспечивается сверхбыстрая запись пикселей в буфер видимости. При включении режима визуализации Raster Bins из консоли разработчика с помощью команды r.Nanite.Visualize.Advanced 1 или r.nanite.showmeshdrawevents 1 кластеры, проходящие через программную растеризацию, отображаются синим цветом. 9 В хорошо оптимизированной сцене подавляющее большинство геометрии должно быть синего цвета. 9
Аппаратная растеризация (Hardware Raster Path)
Аппаратная растеризация — это классический метод рисования GPU, который вступает в силу, когда треугольники на экране больше размера пикселя или когда используются специальные свойства материалов, которые программная растеризация Nanite на базе compute не может обработать. 9 Этот путь отображается красным цветом в режимах визуализации. 9 Вполне нормально, что система переходит на аппаратную растеризацию, особенно когда камера приближается к огромной стене, поскольку треугольники становятся больше пикселей. 9 Однако если объекты, удаленные от камеры, или микрополигоны все еще отображаются красным цветом, это указывает на возникновение «Hardware Fallback» (Аппаратного отката), что является серьезной проблемой оптимизации. 9 Основной причиной нежелательных сливов в аппаратную растеризацию является использование материалов с масками (masked), прозрачностью или сложными смещениями деформации. 9
Raster Bins (Корзины растеризации) и управление материалами
Сердце производительности Nanite заключается не столько в самой геометрии, сколько в том, как материалы, применяемые к геометрии, распределяются по виртуальным ячейкам, называемым «Raster Bins». 9 Nanite помещает все стандартные, непрозрачные материалы, не содержащие никакого смещения глубины пикселей (PDO) или смещения мирового положения (WPO), в одну гигантскую Raster Bin (Корзину растеризации), и система обрабатывает эту корзину с молниеносной скоростью за один проход (pass). 9 Однако при использовании материалов с перемещением (displacement), маскированием (masked/alpha test) или интенсивным WPO для эффектов ветра эти объекты выводятся из этого быстрого проходного пути Nanite, что приводит к созданию для каждого типа материала отдельной и независимой Raster Bin. 9
Класс производительностиТип материала и свойствоВлияние Nanite и статус обработкиСтратегическая рекомендация для разработчикаЛучший (Best)Opaque (Непрозрачные), чистые материалы без смещений WPO, PDO или Displacement.Смешиваются в пределах одной Raster Bin. Активно работает программная растеризация, стоимость вызова отрисовки (draw call) близка к нулю.9Более 90% дизайна окружения, зданий и твердых поверхностей (hard surface) в проекте должны состоять именно из таких элементов.9Хороший (Good)Opaque (Непрозрачные), но с минимальным уровнем WPO (World Position Offset).Из-за использования WPO статические кластеры начинают вычисляться на GPU отдельно. Ограничивающие параллелепипеды (bounding boxes) будут меняться из-за движения, что затрудняет процесс отсечения (culling).Расстояние перемещения WPO должно быть обязательно ограничено (clamp) во избежание искажения ограничивающего параллелепипеда и ошибочного отсечения.3 Если деформация статическая, ее следует запечь (baked).9Средний (Okay)Masked (Маскированные/с прозрачными краями, Alpha Cutout).Принудительно переходит на аппаратную растеризацию (Hardware Raster Path). В результате постоянной оценки пустых пикселей создает сильный «Overdraw» (избыточное рисование).Используется в классическом моделировании листвы или заборов, но из-за пагубного влияния на производительность применять его следует очень экономно.8Худший (Worst)Сложные деформированные материалы (Интенсивный WPO + PDO).Каждая вариация создает отдельную Raster Bin. Увеличивает количество изменений состояний (state changes), мгновенно выводя время кадров за рамки бюджета.Обязательно должен немедленно отменяться для объектов на дальних расстояниях (LOD fallback) или заменяться более современными альтернативами, такими как Nanite Skinning, поставляемыми с UE 5.7.9
Слишком большое количество Raster Bins означает увеличение изменений состояний (state changes) на GPU и рост вариаций вызовов отрисовки (draw calls), что серьезно замедляет работу GPU.9 В проекте, нацеленном на 60 FPS (16.66 мс на кадр), обязательно нужно удерживать время обработки VisBuffer ниже 4 мс, а времени BasePass — ниже 3 мс; в противном случае времени на другие системы, такие как постобработка, Lumen и искусственный интеллект, не останется.7
Интеграция Nanite: Как использовать ее в проектах?
Интеграция Nanite спроектирована таким образом, чтобы внедряться в существующие рабочие процессы разработки игр на Unreal Engine с минимальными усилиями. Устраняя процессы создания ручных LOD-моделей или запекания карт нормалей прошлых поколений, эта система при правильной настройке автоматически оптимизирует производительность.1
Типы геометрии и поддерживаемые компоненты
Чтобы геометрия могла использовать возможности Nanite, эту функцию необходимо активировать на этапе импорта (import) или после него через редактор статических мешей (Static Mesh Editor).3 В актуальных версиях Unreal Engine 5 типы компонентов, поддерживаемые Nanite, были значительно расширены:
● Статические меши (Static Meshes): Любой Static Mesh, добавленный в проект, можно преобразовать, отметив опцию "Enable Nanite Support" внутри редактора. В огромных сценах с тысячами объектов можно перевести всю библиотеку в формат Nanite одновременно с помощью массового выбора (batch-enable) через Content Browser.3 Основной целевой аудиторией системы Nanite являются именно эти меши.
● Скелетные меши (Skeletal Meshes): Если в ранних версиях UE5 поддерживались только статические объекты, то благодаря поддержке API скелетных мешей, появившейся в версиях UE 5.3 и выше, динамически деформируемые (анимированные) персонажи, существа и транспортные средства теперь также могут использоваться с Nanite.3 Самым большим нововведением для скелетных мешей является создание всего одного вызова отрисовки (one draw call) для всего меша. Skeletal Mesh'и Nanite работают, используя LOD-модели анимации вместо классических геометрических LOD'ов.3
● Составные поверхности по сплайнам (Spline Meshes) и ландшафты (Landscape): Nanite изначально поддерживает Spline Mesh'и, которые изменяют форму вдоль кривых (дороги, трубопроводы, стены), и топологию ландшафтов широкого открытого мира (через Nanite Tessellation).3 Мелкие детали смещения (displacement) на поверхностях могут быть получены напрямую через материалы, без создания полигональной плотности и снижения производительности.3
● Инстансированные меши (Instanced Static Meshes - ISM / HISM): Объекты с миллионами копий (например, камни в гигантском лесу или кирпичи зданий) рендерятся с единым объемом памяти благодаря буферу видимости Nanite. Однако следует помнить, что максимальное количество экземпляров (instances) Nanite, которое может находиться на сцене, аппаратно ограничено 16 миллионами.3
Создание и роль резервного меша (Fallback Mesh)
Когда при создании данных Nanite установлен флажок "Build Nanite", движок автоматически генерирует упрощенную геометрию с традиционным количеством полигонов, называемую "Fallback Mesh" (резервный меш), наряду с высокодетализированным мешем.13
Существование этого резервного меша имеет жизненно важное значение: ориентированная на GPU система растеризации Nanite не может напрямую использоваться для сложных расчетов физических столкновений (collision), предварительно рассчитанных карт освещения с помощью Lightmass (baked lighting) и, самое главное, отражений аппаратной трассировки лучей (hardware ray tracing / Lumen HWRT).13 Логические системы со стороны CPU игрового движка нуждаются в этих традиционных треугольных данных. Уровень детализации резервного меша можно контролировать, изменяя параметр "Fallback Relative Error" (резервная относительная погрешность).3 Чем ниже коэффициент ошибки, тем больше полигонов в резервном меше, что обеспечивает более точный расчет отражений с аппаратной трассировкой лучей (Lumen Hit Lighting), но также увеличивает использование памяти (VRAM) в той же пропорции.14
Nanite Foliage: Системы вокселей и сборок (Assembly), появившиеся в UE 5.6/5.7
Лесные массивы и густая растительность в игровых движках долгое время считались самой уязвимой точкой Nanite из-за множества накладывающихся друг на друга прозрачных (masked) поверхностей листьев.15 Традиционное моделирование травы или листвы (alpha cards) приводило к проблеме перерисовки (Overdraw), когда пиксели оценивались многократно поверх друг друга и попадали в HW Raster.8
Версии Unreal Engine 5.6 и особенно 5.7 решили эту проблему фундаментально и с помощью архитектурных изменений с помощью системы "Nanite Foliage" 12:
Nanite Voxels (Воксели): Сложные и создающие перерисовку треугольники листьев удаляющихся от камеры деревьев или растительности преобразуются в воксели на расстоянии путем настройки параметра "Voxelize" в меню "Shape Preservation".17 Эти воксели, похожие на блоки Minecraft, обрабатываются как объемные пиксели вместо треугольников, полностью устраняя необходимость в прозрачности (alpha) и тем самым предотвращая проблему перерисовки на аппаратном уровне.15 Сотни тысяч деревьев вдалеке обрабатываются с чрезвычайно низкими затратами в виде объемных вокселей размером с пиксель экрана, а при приближении плавно переходят в полноразмерные микрополигоны с полной детализацией.15
Nanite Assemblies (Сборки): Когда гигантские деревья моделируются в высоком разрешении, они достигают невероятных размеров на диске и в памяти. Благодаря функции Nanite Assemblies каждая ветвь, лист и ствол дерева считываются не как отдельный гигантский статический меш, а как иерархическое целое (сборка) через импортер USD (Universal Scene Description).12 Благодаря схемам NaniteAssemblyRootAPI, подготовленным в таких программах, как Houdini Solaris, тысячи листьев фактически вызываются методом инстансинга (instancing) того же самого маленького меша листа.19 Эта структура невероятно уменьшает объем занимаемой памяти.
Nanite Skinning: Традиционная ветровая анимация на основе WPO (World Position Offset) изменяла ограничивающий параллелепипед каждого кластера в каждом кадре, что требовало постоянных пересчетов (culling invalidation) на CPU/GPU.15 Благодаря Nanite Skinning, представленному в UE 5.7, деревья импортируются как скелетные меши (skeletal mesh); физические и процедурные эффекты ветра рассчитываются через кости (bones) с помощью плагина "Dynamic Wind".12 Таким образом, Nanite предлагает гораздо более органичные и последовательные взаимодействия с ветром без ущерба для производительности Raster Bins. Новая библиотека Quixel Megaplants и редактор процедурной растительности (Procedural Vegetation Editor - PVE) полностью интегрируют эти технологии, обеспечивая легкое достижение целей в 60 FPS.15
Процессы оптимизации: на что следует обратить внимание?
Хотя Nanite и разработана для повышения производительности, обещание «бесконечных полигонов» — это не волшебная палочка. При неправильном использовании и несоблюдении аппаратных ограничений это сложная система, которая может серьезно поставить под угрозу время кадров (frame).11
Прозрачность (Translucency), маскирование и проблема перерисовки (Overdraw)
В традиционной оптимизации игр (UE4 и более ранние версии) стандартным подходом было симулирование детализированного объекта путем наложения прозрачных масок (alpha texture / masked material) на низкополигональные поверхности.8 Однако в архитектуре Nanite этот подход полностью верен катастрофическим последствиям и ошибочен.8
При вычислении буфера видимости Nanite требуются дополнительные аппаратные проходы для пропуска прозрачных (пустых) пикселей. Когда маскированные материалы располагаются друг за другом (например, металлическая сетка или листья деревьев), система вынуждена читать и обрабатывать глубину и прозрачность одного и того же пикселя десятки раз, что называется "Overdraw".10
Критические правило: в системе Nanite "геометрия очень дешева, но прозрачность очень дорога". При создании перфорированных объектов, таких как листья, заборы или сети, вместо использования маскированного материала (masked material), контур формы должен быть полностью смоделирован (fully modeled), если необходимо, с сотнями тысяч дополнительных полигонов, а материал должен быть строго установлен как "Opaque".8 Полностью смоделированный лист дерева будет рендериться намного быстрее, чем маскированная плоская поверхность (plane).8
Интеграция виртуальных карт теней (Virtual Shadow Maps - VSM)
Традиционные карты теней (Cascaded Shadow Maps - CSM) не могут соответствовать огромному уровню детализации на уровне микрополигонов, предлагаемому объектами Nanite. Виртуальные карты теней (VSM), специально разработанные для использования с Nanite, динамически сопоставляют разрешение теней с пикселями экрана, обеспечивая кристально четкие тени.23
По своей природе VSM требуют большого количества памяти VRAM. Если объект, отбрасывающий тень, постоянно движется (например, листья, колышущиеся с WPO), кэш теней VSM (shadow cache) аннулируется (invalidated) в каждом кадре, и карта теней рассчитывается с нуля, вызывая серьезное падение FPS.22 Поэтому, в то время как статичные сцены или здания отлично работают в паре с Nanite и VSM, в лесных массивах с интенсивным движением следует вводить ограничения WPO или рассмотреть переход на классические карты теней (Shadow Maps) в соответствии с тестами производительности.25
Профилирование (Profiling) и команды чтения производительности
Для поиска первопричины проблем оптимизации и определения того, чем вызвано «узкое горлышко» — процессором или видеокартой, крайне важно регулярно читать встроенные команды профиля (stat), предлагаемые в UE5, с самого начала проекта (принцип optimize early).26
Команды профиля и инструменты визуализации, которые разработчики должны использовать регулярно, следующие 28:
Команда профиля / РежимОписание и цель использованияДействие разработчикаstat unitОбнаружение базового «узкого горлышка». Отображает общее время на экране в виде разбивки в миллисекундах (мс) на "Frame" (общее время), "Game" (игровой цикл CPU), "Draw" (подготовка к рендерингу CPU) или "GPU".28Если время GPU превышает 16.66 мс, следует обратиться к графическим ограничениям, а если превышено время Game — к оптимизации искусственного интеллекта или тиков Blueprint.
Команда / ИнструментФункция и описаниеДействие по оптимизацииstat gpu или stat scenerenderingПеречисляет конкретные нагрузки рендеринга внутри GPU. Детализирует, сколько времени занимают нагрузки Nanite BasePass, Lumen, теней (Shadow Depths) и постобработки.Если Nanite VisBuffer превышает 4 мс или BasePass превышает 3 мс, следует проверить Raster Bins или Overdraw.r.nanite.showmeshdrawevents 1Изучает в иерархическом порядке внутри GPU Profiler (Ctrl+Shift+,), какой конкретно материал и объект Nanite тратят время.Используется для обнаружения и изоляции дорогостоящих материалов WPO или прозрачных объектов.NaniteStatsОтрисовывает интерфейс прямо в углу экрана с помощью технологии "ShaderPrint". В режиме реального времени фильтрует, создают ли нагрузку на отрисовку в Nanite виртуальные тени или первичная область видимости (Primary View).Нагрузка активных проходов определяется вводом параметров (primary, VirtualShadowMaps) в консоль.View Mode > Nanite Visualization > OverdrawОкрашивает области на экране, где пиксели накладываются друг на друга, в спектре от синего (хорошо) до оранжевого и красного (плохо).Определяются зоны с высокой концентрацией прозрачных материалов, и проводится ревизия полного моделирования (opaque).
Связь между архитектурой ввода-вывода (I/O) PlayStation 5 (PS5) и потоковой передачей Nanite
При разработке игр для PlayStation 5 единственным фактором, который выводит потенциал Nanite из зоны теоретических ограничений на пик реальной производительности, является революционная архитектура SSD-накопителя и аппаратного сжатия/распаковки (decompression) консоли. Кластеры Nanite по 128 треугольников спроектированы в расчете на подгрузку по требованию (on-demand streaming pages), и иерархия ввода-вывода (I/O) PS5 находится в безупречной гармонии с этим подходом.
Аппаратное сжатие Kraken и интеграция Oodle Texture
В традиционных ПК-системах и консолях прошлого поколения (PS4, Xbox One) сжатые данные, прочитанные с диска (с помощью алгоритмов общего назначения вроде ZLIB), сначала попадают в оперативную память, после чего центральный процессор (CPU) должен распаковать их путем декомпрессии. Когда гигантские объемы кластеров Nanite, состоящие из миллиардов полигонов, при каждом движении камеры требуют потоковой передачи новых данных со скоростью в гигабайтах в секунду (ГБ/с), этот метод программной декомпрессии (software decompression) приводит к тому, что на ПК и старых консолях процессор зависает и оказывается не в состоянии обрабатывать игровую механику (искусственный интеллект, физику и т. д.).
Проектируя железо PS5, компания Sony не стала ограничиваться стандартами и интегрировала в свой комплекс ввода-вывода специализированный чип аппаратного декодера (hardware decompressor block) на уровне кремния, предназначенный для распаковки алгоритма сжатия Oodle Kraken, разработанного RAD Game Tools. По сравнению с форматом ZLIB прошлого поколения, Kraken позволяет уменьшать размер данных без потерь (lossless) на 29% эффективнее, превосходя его в 3–4 раза по скорости декомпрессии.
При использовании формата без потерь Oodle Texture (в сочетании с оптимизациями сжатия текстур вроде BC7Prep) чип Kraken на PS5 задействует множительный эффект для исходной скорости чтения SSD в 5.5 ГБ/с, обеспечивая передачу данных на невероятных скоростях пропускной способности: в среднем 8–9 ГБ в секунду, а в пиковых значениях (peak) — от 17 до 22 ГБ в секунду.
Преодоление узкого места CPU и множитель пропускной способности
Для Nanite значение этой архитектуры ввода-вывода огромно. В следующей таблице обобщено, насколько сильно технология сжатия PS5 экономит ресурсы процессора по сравнению с конкурентами и прошлыми поколениями:
Метрика аппаратного сжатия и алгоритмаPS4 / Предыдущее поколениеXbox Series XPlayStation 5Основной алгоритм сжатияZLIB (программный)BCPack (аппаратный вариант ZLIB)Oodle Kraken + Oodle Texture (специализированное аппаратное обеспечение)Максимальная скорость вывода (Peak Bandwidth)~100-200 МБ/с~6 ГБ/с (эффективная с SFS)~22 ГБ/сСредняя скорость вывода (Average Bandwidth)< 100 МБ/с~4.8 ГБ/с8-9 ГБ/с (17 ГБ/с с Oodle)Эквивалентная экономия производительности процессора (CPU)Полностью нагружает CPUЭквивалентно ~5 ядрам Zen 2Эквивалентно ~9 ядрам Zen 2
Эта таблица наглядно демонстрирует, что комплекс ввода-вывода PS5 в одиночку берет на себя нагрузку, для компенсации которой на обычном компьютере при распаковке данных с SSD потребовалось бы ровно 9 независимых процессорных ядер Zen 2.
Когда Nanite в каждом кадре (за 16 мс) запрашивает с диска десятки тысяч новых кластеров (streaming pages) в соответствии с новым ракурсом камеры, эти считанные с SSD данные через аппаратный чип Kraken направляются напрямую в пулы RAM и GPU, полностью минуя CPU. Игровые разработчики могут задействовать философию Nanite «Virtual Texturing for Geometry» (Виртуальное текстурирование для геометрии) по максимуму, не опасаясь, что данные «не успеют вовремя» (pop-in). Увидев этот колоссальный потенциал, инженеры Epic Games специально для уникальной структуры ввода-вывода PS5 переписали с нуля базовые подсистемы ввода-вывода (core I/O subsystems) Unreal Engine 5.
Управление VRAM и оптимизация пула потоковой передачи (Streaming Pool)
PlayStation 5 оснащена сверхбыстрой унифицированной (unified) памятью GDDR6 объемом 16 ГБ. Однако, в отличие от архитектур ПК, память на консолях имеет жесткую и негибкую структуру (fixed memory); переполнение виртуальной памяти недопустимо и приводит к немедленному краху системы (OOM — Out of Memory).
Используемые Nanite пулы памяти (streaming pool) геометрически увеличиваются в зависимости от разрешения экрана. Nanite использует буфер видимости (Visibility Buffer), размер которого прямо пропорционален размеру экрана и служит для хранения идентификаторов треугольников. Когда разрешение возрастает с 1080p до 4K (поскольку количество пикселей увеличивается в четыре раза), потребность Visibility Buffer в VRAM также возрастает ровно в 4 раза.
Для обеспечения оптимизации и управления VRAM в проектах для PS5 разработчик должен ограничить размер «Nanite Streaming Pool». В то время как размер пула по умолчанию в пустых проектах составляет около 512 МБ, в AAA-проектах с интенсивным использованием Nanite этот параметр необходимо настроить в командной строке или в файлах .ini (например, в DefaultEngine.ini в строке ``):
r.Nanite.Streaming.StreamingPoolSize = 2048
(примерно 2000–3000 МБ в зависимости от нагрузки сцены и других систем). Если этот бюджет пула будет задан слишком узким, высокодетализированные кластеры удаленных объектов не смогут загрузиться вовремя, и Nanite переключится на запасные модели (fallback); если же задать его слишком широким, то оперативной памяти не останется на поверхности кеша Lumen (Surface Cache), текстуры высокого разрешения и операционную систему. Начиная с версии UE 5.7, разработчики будут видеть срабатывание системы предупреждений в случаях, когда StreamingPoolSize превышает пределы консоли (обычно это перерасход в 2–4 ГБ).
Требования к разработке для PlayStation 5 и конфигурации консоли
Хотя процесс разработки под платформу PS5 с помощью Unreal Engine 5 стал весьма отлаженным в результате тесного сотрудничества Epic Games и Sony, для успешной сборки проекта и его работы на оптимальной скорости необходимо строго соблюдать специфические требования к комплекту разработчика (SDK) и системным конфигурациям.
Версии SDK и флаги компилятора (Compiler)
При сборке (build) под железо PS5 на актуальных версиях Unreal Engine 5.6 и 5.7 необходимо учитывать следующие требования к оборудованию и библиотекам программного обеспечения:
Поддерживаемые версии SDK и системы: Базовым требованием для среды разработки PS5 определены «Prospero SDK 11.00.00.40» (или SDK 12 для продвинутых систем хранения данных) и «Системное программное обеспечение 11.00.00.43». Несоответствие версий в конфигурации проекта (при работе со сторонними плагинами, такими как IntlNetwork SDK или Interhaptics) станет причиной сбоев.
Конфигурация компилятора (Compiler): В процессе компиляции помимо собственного тулчейна Sony используется clang-cl. Чтобы предотвратить неопределенное поведение (undefined behavior) и ошибки NaN (Not a Number) в Clang 19, исходный код теперь в обязательном порядке компилируется с флагом -fhonor-nans. Кроме того, параметр -ffp-contract=off, создававший проблемы кроссплатформенности в прошлом, был удален из компилятора PS5, поскольку он конфликтует с флагом -ffast-math.
Переход на стандартную библиотеку (Stdlib): Начиная с UE 5.7, добавлена поддержка стандартной библиотеки C++20 (stdlib v2) для PS5. Ради перспективной совместимости и прироста производительности разработчикам настоятельно рекомендуется явно прописать StandardLibVersion = 'v2' через файлы конфигурации UEBuildPS5.cs или BuildConfiguration.xml.
Настройки оптимизации системы: Для предотвращения накопления состояний семплеров (sampler) на GPU в архитектуре AgcRHI была внедрена новая система кэширования LRU (Least Recently Used). По умолчанию этот лимит настроен как r.Agc.MaxSamplerStates 4096.
Профили масштабируемости (Scalability) для цели 60 FPS
В UE5 целевой показатель 30 FPS (33.3 мс на кадр) на консолях PS5 и Xbox Series X настроен по умолчанию для уровня качества «Epic». В современных играх с трассировкой лучей и колоссальной полигональной нагрузкой нацеливание на 60 FPS (16.6 мс на кадр) требует осознанных компромиссов в отношении разрешения рендеринга и качества Nanite и Lumen.
Студиям, желающим выпустить игру на PS5 с плавными 60 FPS, необходимо понизить качество систем глобального освещения (GI) и отражений Lumen в настройках DeviceProfiles.ini на уровне движка до профиля «High», адаптированного под бюджет 60 FPS. В этом профиле игра рендерится во внутреннем разрешении (internal resolution) примерно 1080p или 1440p до того, как будет масштабирована (upscale) с помощью Temporal Super Resolution (TSR).
Следующий блок конфигурации следует добавить напрямую в файл [ProjectName]\Platforms\PS5\Config\PS5DeviceProfiles.ini внутри каталога игры:
; Set Lumen GI and reflection quality to High, targeting 60 fps console budget
+CVars=sg.GlobalIlluminationQuality=2
+CVars=sg.ReflectionQuality=2
Эта конфигурация снижает вычислительную нагрузку Lumen до пределов консоли, оставляя миллионам полигонов, обрабатываемых с помощью Nanite, запас времени в 16.66 мс на кадр. Кроме того, для повышения производительности Nanite важно сохранять активными возможности обнаружения тонкой геометрии (Thin Geometry detection) в TSR.
Специальные оптимизации PS5 для синхронизации Lumen и Nanite
Сама по себе система Nanite отвечает исключительно за статическую геометрическую отрисовку; однако то, что определяет визуальное качество игры — это Lumen, система глобального освещения (Global Illumination), которая создает фотореалистичные тени за счет лучей, отскакивающих от поверхностей Nanite. При объединении обеих систем железо PS5 работает на пределе своих возможностей.
У Lumen есть два режима работы: программная трассировка лучей (SWRT), использующая поля расстояний (Distance Fields), и аппаратная трассировка лучей (HWRT), рассчитывающая треугольники напрямую. Nanite передает свою сложную геометрию в механизм HWRT с помощью упомянутых ранее запасных сеток (Fallback Meshes). Если в старых версиях движка для 60 FPS принудительно рекомендовалась SWRT, то в версиях Unreal Engine 5.6 и 5.7 были проведены кардинальные улучшения HWRT для разгрузки консольного железа (в особенности RT-ядер на базе AMD RDNA2 у PS5):
1. Оптимизация ShortRangeAO: Расчеты ближнего пространственного затемнения (Ambient Occlusion) теперь выполняются в половинном разрешении (half resolution) при помощи нового шумоподавителя (denoiser). Эта операция делает данный проход на консолях ровно в два раза быстрее. 49
2. Режим Far Field (Дальнее поле) только для окклюзии (Occlusion Only): В огромных открытых мирах расчеты отскоков от очень удаленных объектов Nanite, загружаемых системой World Partition, могут перегрузить систему. Использование новой команды r.LumenScene.FarField.OcclusionOnly 1 ускоряет производительность дальнего поля Lumen на PS5 на 50%. 49
3. Пониженная дискретизация сбора экранных зондов (Downsampled Screen Probe Gather): Снижение коэффициента интеграционной дискретизации (r.Lumen.ScreenProbeGather.IntegrateDownsampleFactor) в проходе Probe Gather, проецирующем окружающее освещение на экран, экономит 0.3–0.5 мс времени на PS5 в сценарии рендеринга 1080p. 20 Несмотря на то, что в деталях заметно некоторое смягчение, этот компромисс крайне идеален для бюджета 60 Гц.
4. Переупорядочивание выполнения шейдеров (Shader Execution Reordering — SER): В сложных сценах с использованием HitLighting и лучевой полупрозрачности (ray-traced translucency) при наличии множества разнообразных материалов команда r.Lumen.HardwareRayTracing.ShaderExecutionReordering, активирующая переупорядочивание команд на аппаратном уровне, обеспечивает ускорение на поддерживаемых RHI-модулях. 49
Если разработчик, несмотря на высокую степень оптимизации Nanite в своей сцене, упирается в пределы рендеринга PS5, он должен измерить стоимость HWRT с помощью профилировщика «stat gpu» и на ранних этапах проекта протестировать сценарий возврата к классическим картам тени (Shadow Maps) вместо виртуальных карт теней (VSM) для направленных источников света с целью удешевления расчетов теней (optimize early). 25
Стратегический итог и рекомендации для разработчиков
В соответствии с проведенным глубоким анализом, архитектура Nanite в Unreal Engine 5 совершает подлинную революцию в индустрии компьютерной графики, органично сочетая возможности современных вычислительных шейдеров GPU (compute shader), интеграцию аппаратной трассировки лучей и алгоритмы сжатия данных нового поколения. Избавляя разработчиков от ограничений на количество полигонов и узких мест вызовов отрисовки (draw call), эта технология вместе с тем приносит новые рабочие процессы ( Assemblies, Voxelization) и строгую дисциплину бюджетирования памяти (Streaming Pools).
К числу основополагающих стратегических выводов, которые должны учитывать технические художники (Technical Artists) и инженеры движка (Engine Programmers), разрабатывающие игры под платформу PlayStation 5, относятся следующие:
1. Корректное использование преимущества ввода-вывода (I/O) на пределе возможностей: Уникальный аппаратный декомпрессор Kraken на PS5 обеспечивает невероятную пропускную способность ввода-вывода через SSD. Разработчикам целесообразнее отказаться от устаревших стратегий ручных LOD, ограничивающих потоковую передачу Nanite, и перейти непосредственно к использованию оригинальных исходных сеток (source mesh) кинематографического качества, что более естественно согласуется с естественным потоком данных системы.
2. Избежание затрат на прозрачность и перерисовку (Overdraw): Анимации на базе WPO (World Position Offset) и использование масок прозрачности Alpha Mask/Cutout, являющиеся ахиллесовой пятой Nanite, катастрофически снижают производительность, особенно на растительности. Представленные в UE 5.6 и 5.7 функции Nanite Voxels, Nanite Assemblies и Nanite Skinning должны стать ключевым методом вместо традиционного моделирования травы при достижении цели открытого мира в 60 FPS на PS5. Вместо оптимизации моделей обязателен переход к высокополигональной, но гладкой непрозрачной («Opaque») геометрии.
3. Точное бюджетирование VRAM: Фиксированная структура памяти PS5 может быстро истощаться идентификаторами видимости Nanite (Visibility Buffer) и кешем поверхности Lumen. Границы StreamingPoolSize должны настраиваться скрупулезно, а вместо нативного рендеринга в 4K целевые показатели внутреннего разрешения 1080p–1440p в сочетании с Temporal Super Resolution (TSR) должны использоваться для синтеза высокого визуального качества со стабильной частотой кадров.
4. Регулярный и ранний анализ профилирования (Optimize Early): Не дожидаясь окончания процесса разработки, необходимо активно отслеживать инструменты профилирования stat gpu, stat unit и NaniteStats. Следует выявлять и объединять проблемные структуры материалов, создающие «Raster Bins», сводя к минимуму изменения состояний между CPU и GPU.
Nanite — это не волшебная палочка для повышения производительности; напротив, это мощнейшая экосистема, которая при правильном использовании возможностей не сковывает видение, но при нарушении правил (например, чрезмерном использовании маскированных материалов) жестко натыкается на аппаратные барьеры. Когда специальная архитектура ввода-вывода железа PS5 и рендеринг-инновации Unreal Engine 5 работают синхронно, визуальные и объемные границы интерактивных медиа расширяются беспрецедентным образом.
*Примечание: Изображения были сгенерированы с помощью Google Gemini.