Балансировка визуальной четкости и производительности в Projekt Z: Beyond Order

Проект Z: Beyond Order, первая большая коммерческая игра от 314 Arts, это кооперативный зомби-шутер на четырех игроков, который сочетает в себе кинематографическое повествование с интенсивным, командным игровым процессом.

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

Проект Z: Beyond Order: Пример использования Unity

Как студия повышает визуальную четкость, сохраняя производительность на платформах?

Когда 314 Arts представила Проект Z: Beyond Order на нескольких платформах, их мотивация заключалась не только в охвате рынка – это также было связано с решением технической задачи.

“Консоли имеют ограниченные ресурсы, поэтому достижение наших визуальных и игровых целей при сохранении производительности является сложной задачей – но именно это делает ее захватывающей,” говорит Джастин Мерш, соучредитель и дизайнер игр/уровней в 314 Arts. «Вы постоянно оптимизируете, выжимая каждую каплю мощности из оборудования.» Наблюдать, как игра приближается к нашей цели, невероятно приятно.»

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

Результаты

Увеличенная производительность с неприемлемого уровня до стабильных 30 fps на Steam Deck

Увеличенная частота кадров на GTX 1060 с 30 fps до 55 fps

Получено около 2-3 мс времени GPU

Использование Процесса рендеринга высокого разрешения (HDRP)

С самого начала 314 Arts знали, что Projekt Z: Beyond Order нуждается в мощной технологии рендеринга, чтобы достичь своей темной, кинематографической атмосферы. «HDRP был критически важен для достижения наших целей», говорит Мерш. «Нам нужно было высокое качество с максимальной гибкостью, и он дал нам именно это – решение, готовое к будущим технологиям, таким как трассировка лучей.»

Раннее использование HDRP дало команде доступ к развивающимся функциям, таким как Глобальное освещение в пространстве экрана (SSGI), Суперсэмплирование глубокого обучения (DLSS), FidelityFX Суперразрешение (FSR) и Масштабируемая временная постобработка (STP), что улучшило как визуальное качество, так и доступность для оборудования начального уровня. Однако профилирование показало, что тени были основным узким местом производительности. Чтобы решить эту проблему, не жертвуя качеством, команда разработала собственный инструмент – Менеджер теней HDRP (HSM).

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

Максимилиан Кубе, соучредитель и программист, объясняет, что многие проблемы с рендерингом возникли из-за творческих амбиций команды. «Дело никогда не в движке – дело в том, чтобы делать разумный выбор, когда речь идет о визуальной четкости.» Оптимизируя объемные эффекты, тени и текстуры, мы добились значительных улучшений. Мы уменьшили бюджет объемного тумана, снизили разрешение теней до 512 или 1K и выборочно изменили размеры текстур.»

Создание разрушаемых уровней

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

Поскольку они создали свою собственную систему миссий на основе узлов, дизайнеры уровней создавали анимации в Timeline и связывали их с редактором узлов для миссий. Это позволило им быстро тестировать идеи.

«Как только мы получили одобрения, мы обновили модели внутри Timeline и добавили к ним некоторые VFX и SFX. Это действительно ускорило итерацию миссий», говорит Мерш.

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

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

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

Улучшение производительности GPU

По мере увеличения проблем с производительностью команда привлекла команду Integrated Success от Unity для поиска решений. С доступом к премиум-поддержке они решили большинство критических проблем в течение 24 часов.

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

Захваты GPU на NVIDIA RTX 3090 показали, что даже при 1080p игра превышала свой бюджет кадров. Проходы, такие как SSGI и отложенное освещение, хорошо масштабировались, но GBuffer, теневое картирование, предварительный проход глубины и векторы движения требовали оптимизации.

«Проход GBuffer сам по себе занимал более 20% времени нашего GPU. Анализ PIX показал, что отключение Early-Z из-за неправильной настройки GPU вызвало некоторые дорогие вызовы отрисовки. Early-Z пропускает пиксельное шейдинг на закрытых пикселях, выполняя тест глубины перед пиксельным шейдером», объясняет Куб. «Как только мы исправили конфигурацию шейдера, которая отключала оптимизацию Early-Z, мы получили около двух-трех миллисекунд на кадр.»

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

Оптимизация предварительного прохода глубины также была важна. Разработчики использовали опцию полного предварительного прохода глубины, которая отрисовывала все меши для заполнения буфера глубины. По умолчанию HDRP ограничивает этот проход сложными материалами, такими как объекты с альфа-обрезкой или подповерхностным рассеиванием, чтобы уменьшить нагрузку на GPU.

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

Улучшения векторного движения еще больше снизили нагрузку на GPU. «Движок ненужно отрисовывал много статических объектов в проходе векторного движения», - объясняет Мерш. «Установив для неанимированных объектов режим "Только движение камеры" или "Принудительно без движения", и отсекая удаленные объекты, мы значительно сократили время работы GPU без ущерба для визуальной четкости».

После внедрения этих рекомендаций производительность улучшилась значительно. Игра теперь стабильно работает на 30 fps на Steam Deck, а на GTX 1060 частота кадров увеличилась с 30 fps до 55 fps.

«Команда Integrated Success не только помогла нам исправить производительность – они научили нас лучше понимать движок», - говорит Мерш. «Прямой доступ к инженерам Unity и практические советы сделали всю разницу».

Оптимизация производительности CPU

С учетом контроля узких мест GPU внимание переключилось на процессорный конвейер. Хотя игра ограничена GPU на 4K на GeForce RTX 3090, на 1080p нагрузка смещается, и основной поток тратит примерно половину своего времени кадра в 28 мс на отрисовку. «Профилирование показало, что граф рендеринга HDRP и скриптовый контекст рендеринга были ответственны за большую часть нагрузки на CPU», - говорит Мерш.

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

Для оптимизации команда оценила настройки HDRP, включив динамическое отсечение проходов рендеринга, чтобы пропускать ненужные проходы, и протестировала такие опции, как низкое разрешение прозрачности, отсечение по расстоянию и расстояния отсечения на основе слоев. «Отсекая мелкие объекты ближе к камере, мы уменьшили количество команд отрисовки, теневых кастеров и переотрисовку. Это помогло как производительности CPU, так и GPU», - объясняет Мерш.

Обновление команды до Unity 6 также улучшило производительность ЦП. Они использовали функцию GPU Resident Drawer (GRD), чтобы использовать API BatchRendererGroup для уменьшения количества вызовов отрисовки, загрузки меньшего объема данных на кадр и снижения блокировки основного потока. «Включив GRD, как основной, так и рендерный потоки показали измеримые улучшения», объясняет Мерш.

Они также автоматически отсеивали мелкие сетки, используя настройку Small-Mesh Screen-Percentage, что уменьшало количество вызовов отрисовки от объектов, слишком маленьких, чтобы существенно повлиять на кадр.

«HDRP широко использует систему Render Graph в своей реализации, что может привести к некоторым накладным расходам на ЦП. С Unity 6 мы использовали кэширование Render Graph, которое повторно использует результаты компиляции предыдущего кадра», говорит Куб. «Движку больше не нужно перекомпилировать график рендеринга каждый кадр, что значительно снижает наши затраты.»

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

Загрузите Unity Pro сегодня

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