Unreal Editor на ноутбуке: Scalability и stat unit вместо случайного отключения эффектов
Если тяжело работать во viewport Unreal Editor, сначала зафиксируйте одну сцену и времена кадра, а затем уменьшайте конкретную нагрузку. Пресет Low не является универсальной диагностикой: он меняет сразу несколько визуальных составляющих и может скрыть нужный для проекта эффект.
Руководство относится к Unreal Engine 5.6. Настройки редактора и итоговая производительность собранной игры — разные проверки. Мы не приводим обещаний FPS для какого-либо ноутбука.
Отделите неудобный Editor от медленной игры
Запишите версию движка, проект, карту, положение камеры, разрешение viewport и состояние Play In Editor. Не сравнивайте пустой уровень с рабочей сценой. Подготовку шейдеров и другие разовые операции отмечайте отдельно от устойчивого игрового участка.
Проверьте питание и выбранный профиль ноутбука, не вмешиваясь в BIOS или лимиты прошивки. Если цель — удобный монтаж сцены, измеряйте именно рабочий процесс Editor. Если нужна оценка игры, потребуется отдельная проверка соответствующей сборки.
Общие требования к ноутбуку для Unity и Unreal — лишь отправная точка. Число гигабайт не объясняет само по себе, какой этап кадра ограничивает конкретную сцену.
Включите понятные показатели
В документации Stat Commands для UE 5.6 описаны команды stat fps и stat unit. Для предусмотренного документацией режима PIE используйте консоль и смотрите не только счётчик FPS, но и времена.
stat fps
stat unit
Команды показаны по справке, не выполнены здесь на установленном Unreal Editor. Если их вывод отличается в вашей сборке или доступ к статистике ограничен конфигурацией, проверьте документацию именно этой версии.
| Поле stat unit | Какую гипотезу помогает проверить |
|---|---|
| Frame | Общее время формирования кадра |
| Game | Вклад игрового потока |
| Draw | Работа потока рендеринга |
| GPU | Время графического процессора |
| RHIT | Отдельно показываемая работа RHI-потока |
По справке близость Frame к Game или Draw помогает заподозрить ограничение соответствующим потоком. Но эти этапы синхронизируются: не нужно складывать все показанные времена как независимые последовательные задержки. Одного скриншота тоже недостаточно для окончательного диагноза.
Сначала проверьте зависимость от разрешения
Сохраните исходный вариант. На той же сцене уменьшите внутреннее разрешение или размер исследуемого viewport контролируемым способом и повторите наблюдение. В Scalability Reference описан Resolution Scale и переменная r.ScreenPercentage.
Не меняйте одновременно несколько графических пресетов. Если время GPU заметно изменилось при уменьшении нагрузки изображения, это направление для дальнейшего исследования графического участка. Если изменений нет, не делайте вывод, что видеокарта обязательно неисправна: ограничивать сцену могут другие этапы или выбранные условия опыта.
В документации отдельно сказано, что такой масштаб не применяется к 2D-интерфейсу тем же способом. Поэтому счётчик разрешения и визуальный размер UI не обязаны изменяться одинаково. Подпишите, какую именно настройку вы меняли.
Затем настройте группы Scalability
Для UE 5.6 справка указывает меню viewport Performance and Scalability. Группы позволяют управлять качеством теней, постобработки, текстур и других составляющих. Это инструмент выбора компромисса, а не сертификат оптимальности проекта.
Полезный порядок:
- Сохраните исходные настройки и положение камеры.
- Выберите группу, относящуюся к наблюдаемой сцене.
- Измените только её и повторите тот же участок.
- Запишите времена и визуальные потери.
- Верните исходный вариант для контрольного повтора.
Если вам нужно оценивать освещение, не принимайте сильное ухудшение освещения за безусловно удачную оптимизацию. Для моделирования и расстановки объектов может быть допустим облегчённый рабочий режим, а для проверки финального вида понадобится другой. Эти задачи нужно явно разделить.
Не копируйте целиком чужой BaseScalability.ini ради одной проблемы. Понимайте, какие значения меняются и как вернуться к сохранному варианту проекта. Изменение настроек глобального окружения и изменение данных проекта — не одно и то же.
Если ограничивает Game или Draw
Снижение разрешения не обязано исправить всю нагрузку CPU. Сохраните воспроизводимый участок и переходите к более подробному профилированию того этапа, который подозреваете. stat unit помогает выбрать направление, но не показывает автоматически строку пользовательского кода, которую следует переписать.
Не превращайте правило «GPU близко к Frame» в окончательный аппаратный диагноз. Ограничители, ожидания и особенности сцены требуют отдельной интерпретации. Для решения о покупке другого ноутбука нужен повторяемый рабочий проект, а не только сравнение маркировки процессоров.
Если проблема состоит в долгой подготовке и заполненном накопителе, отдельно проверьте Derived Data Cache. Снижение качества viewport не является заменой управлению кэшем и свободным местом.
Как оформить рабочий профиль
Храните две подписанные конфигурации опыта: исходную и выбранную облегчённую. Укажите версию UE, карту, режим запуска, разрешение, конкретные группы и повторяемость. Добавьте список эффектов, которые в облегчённом варианте нельзя корректно оценить.
После улучшения Editor проверьте целевой пользовательский сценарий отдельно. Не объявляйте выигрыш в рабочем окне гарантией такой же скорости packaged build или любого другого проекта.
FAQ
Low всегда самый правильный режим для слабого ноутбука?
Нет. Он может облегчить отдельную задачу, но изменить важные для проекта эффекты. Выбирайте минимально достаточный рабочий профиль и проверяйте финальный вид отдельно.
Можно сложить Game, Draw и GPU, чтобы получить Frame?
Нет как общее правило. Потоки и GPU работают с синхронизацией; документация объясняет связь показателей, а не простое арифметическое суммирование.