Как запустить unreal engine 4 на слабом компьютере

Обновлено: 02.07.2024

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

Significance Manager

Основная идея решения в том, что бы каждого игрока разделить в свой Significance Bucket по важности, основанной на дистанции, размерах, видимости и другой информации. У каждого такого сегмента есть максимальный размер и приоритет. Significance Manager может проводить расчет для LOD игрового мира. К примеру, приоритет игрока который не попадает в кадр в разы ниже, чем у игрока который находится рядом в зоне видимости.

Кроме того, Significance Manager можно использовать в качестве базовой системы для управления другими Scalability системами. Например, "Fortnite" - многоплатформенная игра, реализация которой под разные платформы очень различается. Мы можем установить разные параметры Bucket для разных платформ и даже разных моделей. Например, для консолей MaxSize каждого из наших сегментов составляет 5, 10, 10, 75, для мобильного телефона - 1, 5, 15, 79 и т. д. соответственно. Он также поддерживает настройку параметров для определенных моделей мобильных телефонов.

Анимации

В "Fortnite" персонаж состоит из 5 основных частей: Базового Скелета, головы, тела, рюкзака и оружия. "Базовый Скелет" это пустой скелет без какой либо информации о внешности. Каждая часть анимации имеет свой собственный AnimBP и все они выполняют свои процессы после CopyPose с "Базового Скелета", например, симуляция физики. Это решение очень гибкое и удобное, но несет большие трудности с точки зрения эффективности обработки. Так как у нас 100 игроков, что означает что около 500 SkeletalMesh, которые необходимо постоянно обрабатывать в GameThread. Мы конечно можем применить LOD к мешу, не сильно, но он уменьшит количество костей, но эти расчеты костей проводятся в WorkerThread.

Есть несколько альтернатив данному решению, например Mesh merge, который использовался в "Unreal Tournament", но оно несет свои проблемы. Во-первых, увеличивается количество используемой памяти, так как каждый игрок имеет свою уникальную сетку. Во-вторых, этот подход теряет какую либо гибкость. Ведь каждая часть может иметь свою собственную уникальную логику и если материалы объединить, уникальность анимации может исчезнуть.

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

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

Процесс обновления анимации в Unreal Engine разделен на 3 этапа. Сперва выполняется операция обновление в GameThread. Обновление используется для расчета некоторых значений, таких как веса например. Следующим шагом идет тяжелый процесс по обработке Eval, такие как анимация, декомпрессия, смешивание(blend) и т.д. И завершает этот процесс запуск Notify и отправку данных в RenderThread.

В одном кадре очень много персонажей, которые выполняют просчет скелетных анимаций. Все мы знаем что, сейчас мобильные устройства многоядерные. Чтобы лучше использовать их мощностя нам необходимо лучше обрабатывать запросы BPVM(Blueprint virtual machine) и разделение на потоки. На основе двух вышеуказанных способов оптимизации, мы не используем Event Graph, а делаем игровую логику как часть AnimInstanceProxy, тем самым движок сможет автоматически определять, сможет ли Event Graph обновлятся в других потоках. Если вы используете Fast Path, мы можем поместить обновление скелета в WorkingThread. Например есть 50 персонажей. В начале любого обновления персонажа, вычисления разделяются на другие потоки, а основной поток продолжает свою работу.
Если в AnimBP, есть хоть одна нода (not Fast Path), которой необходимо пройти BPVM, то вся система не сможет быть отправлена в обработку в асинхронном потоке. Это связано с тем, что безопасность потоков не может быть гарантирована для произвольных обращений узла ВР к интерфейсу и самому ВРVM.
Если же Event Graph реализован собственным Proxy в собственном наследуемом классе AnimInstance, и все его свойства в AnimInstance также реализованы в собственном наследуемом классе, то весь процесс обновления не нужно делать с помощью BPVM, поэтому он также будет автоматически помещен в AnyThread для обработки.

Перенос Event Graph to C++

Blueprints замечательная технология, но у нее есть свои проблемы и недостатки. Один из таких AnimBP - Event graph. Если он содержит много логических вычислений и сам по себе сложен, расходы ресурсов могут быть особенно большими. Перенеся вычисления из ВР в С++, может позволить сэкономить много процессорного времени.

Fast Path

Некоторые математические вычисления часто используются в AnimGraph, поскольку выполнение в ВР часто сопровождаются лишними вызовами виртуальной машины. Некоторые расчеты можно перенести в AlphaCurveScaleBiasClamp в ноде, тем самым перенеся вычисления в С++, что само по себе снижает расходы на вызовы BPVM. Отличительной чертой Fast Path есть небольшой значок молнии, и необходимо старатся превращать эти ноды в Fast Path как можно больше в процессе разработки.

Отключать обновление анимации как можно чаще

У Skeletal Mesh есть одна очень важная настройка, MeshComponentUpdateFlag, которую можно установить в OnlyTickPoseWhenRendered, тем самым, когда персонаж не будет попадать на экран, любая обработка анимации будут пропускаться(например, если у вас звуки шагов привязаны к anim notify, за вашей спиной они не будут слышны). Это одна из тех вещей, которые могут быть обработаны при помощи Significance. Когда игроки слишком далеки от вас, отпадает необходимость обрабатывать анимацию оружия, в некоторых случаях даже игрока.

Большинство падающих объектов имитируют физику и являются Skeletal Meshes. Одна из проблем расчета для таких мешей это динамический путь. Статические объекты в UE, будут непосредственно сортироваться и группироваться при добавлении на сцену, что значительно сокращает потребление ресурсов при отрисовке сцены. Динамические же объекты получаются на этапе initViews каждого кадра в начале рендера. Этот процесс весьма отличается от статики, он не попадает в статическую таблицу отрисовки и тем самым снижает эффективность процесса. Такие скелетные объекты, данные которых не нуждаются в изменении в каждом кадре, добавляются в StaticRenderPath, тем самым ускоряя рендеринг

URO (Update Rate Optimization)

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

Дополнительно с настройками Skeletal LOD, мы можем установить Skeletal Control Code для управление анимации в AnimGraph, чтобы не рассчитывать на определенных LOD, тяжелых процессов, таких как ИК, физика и т.д.

RigidBody

Использование RigidBody, как замена AnimDynamics, приносит в проект неоспоримое улучшение как производительности так и гибкости настроек.

Calculation of Bounds

Нельзя просто взять и применить Use Fixed Bounds. Аниматоры создают классные анимации, и после применения Fixed, начинают происходить странные вещи(например, персонажи пропадают). Bounds Расчитываются каждый кадр используя Collison Shapes. Мы можем использовать Bound родителя, для того что бы не расчитывать его 5 раз(рюкзак, парашут, оружие получают Bound родителя). (Подробнее как происходит расчет Bound вы можете узнать из USkinnedMeshComponent::CalcMeshBound).

Другие способы оптимизации анимаций

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

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

Niagara simulates a large group , подходит для моделирования сцены массового побоища огромного количества людей и относится к GPU-симулируемым анимациям.

В этой части мы рассмотрели Significance Manager и оптимизацию через анимации. Продолжение статьи можно прочитать по ссылке.

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

Необязательные параметры

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

Unreal Engine – игровой движок, разрабатываемый и поддерживаемый компанией Epic Games. Первой игрой на этом движке был шутер от первого лица Unreal, выпущенный в 1998 году. Хотя движок первоначально был предназначен для разработки шутеров от первого лица, его последующие версии успешно применялись в играх самых различных жанров, в том числе стелс-играх, файтингах и массовых многопользовательских ролевых онлайн-играх.

Системные требования Unreal Engine

Минимальные системные требования Unreal Engine

Процессор: двухъядерный Intel или AMD, 2.5 ГГц или больше
Видеокарта: с поддержкой DirectX 11 или DirectX 12
Оперативная память: 8 ГБ
Операционная система: Windows 10 64-разрядная

Компьютер для Unreal Engine

Процессор для Unreal Engine

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

Для большинства пользователей отличным выбором будет 12-ядерный AMD Ryzen 9 5900X. Этот процессор имеет 12 ядер и 24 потока, что обеспечивает отличную производительность. Если позволяет бюджет, можно присмотреться к 16-ядерному Ryzen 5950X.

Тем, кому нужна максимально возможная производительность для многопоточных задач, таких как работа с освещением или компиляция, мы рекомендуем следующие процессоры. AMD Threadripper 3960X на 25% быстрее, чем Ryzen 5950X в таких задачах, а Threadripper 3970X и 3990X будут еще быстрее. Обратите внимание, что эти процессоры могут быть немного медленнее в других задачах, поэтому рекомендуем Threadripper только тем пользователям, которые тратят значительно много времени на создание освещения или компиляцию.

Тестирование в компиляции кода

Тестирование в рендеринге освещения

Видеокарта для Unreal Engine

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

Мы рекомендуем следующие видеокарты для рабочего компьютера, в зависимости от вашего бюджета и того, планируете ли разработку VR-контента:

NVIDIA GeForce RTX 3070 8 ГБ – эта видеокарта предлагает отличную производительность и обладает достаточной мощностью для работы с несколькими дисплеями одновременно.
NVIDIA GeForce RTX 3090 24 ГБ на данный момент является одной из лучших видеокарт для разработки игр, VR и архитектурной визуализации. Большой объем видеопамяти делает его подходящим для рабочей станции с тремя или даже четырьмя 4K-мониторами, а дополнительная мощность отлично подходит для игр со слабой оптимизацией.

Оперативная память для Unreal Engine

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

32 ГБ оперативной памяти для большинства пользователей
64 ГБ + ОЗУ, если вы создаете освещение

Имейте в виду, что это базовые рекомендации и они охватывают только объем оперативной памяти, необходимой для самого Unreal Engine. Если вы часто работаете одновременно с другими программами параллельно с Unreal Engine, вам может потребоваться еще больше ОЗУ в вашей системе, так как каждой программе потребуется отдельный фрагмент ОЗУ.

Хранилище (жесткие диски) для Unreal Engine

Unreal Engine может быть не самым тяжелым приложением для хранения, но все же важно иметь быстрое и надежное хранилище, чтобы не отставать от остальной части вашей системы.

Какой тип накопителя следует использовать для Unreal Engine?

Существует три основных типа накопителей, которые вы можете использовать: SSD, NVMe и традиционные жесткие диски. Из этих трех традиционные жесткие диски являются самыми медленными, но они дешевы и доступны с гораздо большей емкостью, чем твердотельные накопители или накопители NVMe. Благодаря этому из них получаются отличные накопители для длительного хранения файлов.
Твердотельные накопители SATA в несколько раз быстрее жестких дисков, но при этом они дороже. Эти диски отлично подходят для широкого круга задач, таких как хранение вашей операционной системы и программ, а также хранение проектов, над которыми вы работаете.
NVMe-накопители бывают двух видов (M.2 и U.2), и они значительно быстрее, чем SATA-SSD. Они, как правило, дороже, чем твердотельные накопители SATA, но зато могут быть в двенадцать раз быстрее! В большинстве случаев вы не увидите значительного увеличения производительности с диском NVMe, поскольку современный стандартный твердотельный накопитель уже достаточно быстр и редко является узким местом производительности, но поскольку стоимость этих дисков продолжает снижаться, их можно использовать в качестве диска с операционной системой и программами, чтобы они запускались немного быстрее.

Рабочие компьютеры для Unreal Engine

Мы надеемся, что это руководство поможет вам понять, какой компьютер нужен для Unreal Engine, или на что ориентироваться при покупке собранного компьютера. Также предлагаем вам ознакомиться с нашими рабочими компьютерами Delta Game, которые отлично подойдут для Unreal Engine.

Почему важно оптимизировать PC-игры под интегрированные графические решения и как заставить на них выдавать 60 кадров в секунду Unreal-проект, — в блоге движка рассказали инди-разработчики из High Horse Entertainment.

Зачем разработчики вообще взялись за оптимизацию под интегрированное решение? Причин две.

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

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

Disc Jam Во-вторых, разрабатываемый ими фритуплейный проект Disc Jam рассчитан на игру при 60 кадрах в секунду. Это критично для достижения победы в самой игре, представляющей собой PvP по метанию дисков.

Что же сделали в High Horse Entertainment?

Изначально они тестили производительность Unreal Engine 4.12.5 “из коробки” на имеющимся примере “Шутер”. На машине с процессором Intel® Core™ i7-4720 и графикой Intel® HD Graphics 4600 демка на максимальных параметрах показывала порядка 20 кадров в секунду, а на минимальных — около 40 кадров в секунду.

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

Но у Unreal Engine 4 есть особенность — Mobile Preview, которая позволяет визуализировать игру на десктопе, используя мобильный рендер. Демка “Шутер” в рамках Mobile Preview стала выдавать порядка 100 кадров в секунду.

20fps Low Quality Settings:

40fps OpenGL ES 3.1 + AEP Mobile Preview:

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

Disc Jam* High-End Renderer and Lighting Disc Jam Low-End Renderer and Lighting

При запуске же игр из Steam сами пользователи после релиза игры смогут выбрать, какую версию игры они хотят запускать: полноценную или для слабых машин.

Disc Jam пока еще не вышла, но уже сейчас, согласно SteamSpy, у игры, находящейся в закрытой пре-альфе, около 80 тысяч пользователей.

Читайте также: