Movie Render Queue это одна из тех вещей в движке, которые экономят время молча, наравне со встроенными AI-помощниками. Нужен он потому, что реалтайм-движок считает кадр за миллисекунды, и ради этого жертвует всем, чем можно. Когда тот же движок используют для вывода готового видео, эти жертвы становятся видны: мыло на движении, шум в тенях, дёрганые отражения. Система очереди просчёта существует ровно для того, чтобы всё это выключить.
Ниже по шагам: что именно портит картинку в обычном режиме, какие настройки это лечат и чем платят за качество.
Почему обычная запись экрана не годится
Разница принципиальная, и её стоит понимать.
В реальном времени движок обязан выдать кадр за отведённое время. Не успевает считать честно, значит достраивает: берёт данные из предыдущих кадров, экономит на выборках, размывает то, что не успел уточнить.
В режиме очереди ограничения по времени нет. Движок может считать один кадр сколько нужно, накапливая качество.
Отсюда все дальнейшие настройки: они по сути отключают компромиссы, придуманные ради скорости.
Накопление выборок: главный параметр
То, ради чего очередь и существует.
Вместо одного прохода кадр считается много раз с небольшим смещением, и результаты усредняются.
Что это исправляет сразу. Лестницы на краях геометрии пропадают без всякого сглаживания. Шум в мягких тенях и отражениях уходит. Прозрачные и полупрозрачные объекты перестают мерцать.
Сколько ставить: зависит от сцены. Простая дневная сцена обходится десятками проходов, сложная с большим числом источников требует сотен.
Признак нехватки: остаточный шум в тенях и на матовых отражениях. Признак избытка: время растёт, а картинка не меняется.
Прогрев кадра
Настройка, без которой первые кадры получаются испорченными.
Многие эффекты в движке накапливаются между кадрами: глобальное освещение, отражения, объёмные среды, рассеивание в тумане.
При просчёте отдельного кадра этой истории нет, и эффект выглядит недосчитанным. На видео это проявляется как вспышка яркости в первые секунды или на первых кадрах после смены плана.
Лечится заданием нескольких холостых кадров перед каждым просчитываемым. Движок считает их, накапливает состояние и только потом записывает результат.
Сколько нужно: обычно достаточно нескольких десятков. Для сцен с плотным туманом больше.
Размытие движения
Место, где реалтайм и вывод расходятся сильнее всего.
В реальном времени размытие делается приближённо: по векторам движения на готовом кадре. Быстро и неточно: на быстрых объектах появляются шлейфы и артефакты по краям.
В очереди доступен честный способ: кадр считается несколько раз внутри интервала выдержки, и результаты складываются. Получается настоящее размытие, как в камере.
Цена вопроса: время просчёта умножается на число этих подкадров.
Параметр, определяющий силу: длительность открытия затвора относительно длительности кадра. Половина это привычное кинематографическое значение.
Практическая тонкость: честное размытие требует, чтобы движок знал о движении внутри кадра. Объекты, анимированные нестандартным способом, могут остаться без размытия, и это выясняется только на готовых кадрах.
Что ещё нужно отключить
Список реалтайм-компромиссов, вредящих финальному кадру.
Временнóе сглаживание. Оно использует предыдущие кадры и даёт то самое мыло на движении. При накоплении выборок оно не нужно.
Масштабирование разрешения. Все системы апскейла рассчитаны на экономию времени. Для вывода считаем в полном разрешении.
Экранные эффекты в упрощённом режиме. Отражения и затенение, считаемые по экрану, дают артефакты на краях кадра. Там, где доступны честные методы, включаем их.
Ограничения потоковой загрузки. В реальном времени текстуры подгружаются по мере надобности. При просчёте это даёт кадры с размытыми текстурами, особенно первые.
Последний пункт причина самой обидной ошибки: посчитанная ночью анимация с мыльными текстурами в половине кадров.
Потоковая загрузка текстур
Заслуживает отдельного разговора, потому что ломает результат тихо.
Механизм держит в памяти текстуры низкого разрешения и подгружает детальные, когда объект попадает в кадр. На глаз в игре это незаметно.
При просчёте камера может переместиться мгновенно, и система не успевает. Кадр записывается с текстурой низкого разрешения.
Решение: увеличить пул памяти под текстуры или полностью отключить потоковую загрузку на время просчёта. Второе надёжнее, если памяти хватает.
Проверять надо не на глаз в предпросмотре, а на записанных кадрах при увеличении.
Освещение при переходе к просчёту
Область, где картинка меняется сильнее всего и не всегда в лучшую сторону.
Динамическое глобальное освещение в реальном времени работает по экранному пространству: считает то, что видно в кадре. Объект за краем экрана перестаёт освещать сцену, и при движении камеры освещённость плавает.
В режиме просчёта доступны более честные методы, не зависящие от того, что попало в кадр. Включать их стоит, но с оговоркой: картинка изменится, и настроенный на глаз свет придётся пересматривать.
То же с отражениями: экранные отражения дают чёрные провалы там, где отражаемого объекта нет в кадре. Аппаратная трассировка это исправляет и заметно повышает стоимость кадра.
Практический порядок: сначала переключиться на честные методы, потом настраивать свет. Обратный порядок означает двойную работу.
Как устроено само динамическое освещение, разобрано в материале про Lumen в UE5.
Форматы вывода
Выбор, влияющий на дальнейшую работу.
Последовательность отдельных кадров надёжнее готового видеофайла. Просчёт можно прервать и продолжить, а сбой на трёхсотом кадре не уничтожит предыдущие.
Формат с расширенным диапазоном яркости нужен, если планируется цветокоррекция. Он тяжелее, но сохраняет информацию в светах и тенях.
Обычный формат с сжатием подходит, если кадр идёт в дело как есть.
Отдельно стоит выводить вспомогательные слои: глубину, векторы движения, маски объектов. Они дают контроль на этапе сборки без пересчёта.
Вспомогательные слои
Возможность, которой пользуются реже, чем стоило бы.
Карта глубины позволяет добавить или изменить размытие фона на этапе сборки. Пересчитывать сцену ради другой глубины резкости не нужно.
Маски объектов позволяют поправить цвет отдельного предмета.
Слой без постобработки даёт чистую картинку, к которой эффекты применяются позже и с контролем.
Стоит это почти ничего по времени, а свободы даёт много.
Когда стоит идти дальше в трассировку
Крайний режим, о котором стоит знать.
Кроме накопления выборок в обычном режиме, движок умеет считать кадр полноценной трассировкой путей. Это уже не реалтайм с улучшениями, а классический рендер внутри игрового движка.
Что это даёт: физически корректное освещение, честные отражения без экранных ограничений, правильные преломления в стекле, мягкие тени без компромиссов.
Чем платят: временем, сопоставимым с обычными рендер-движками. Преимущество в скорости практически исчезает.
Где это оправдано: короткие ключевые кадры, предметная визуализация, сцены со стеклом и водой, где экранные методы выдают себя.
Подробный разбор режима есть в материале про трассировку путей в UE5.
Время просчёта
Честная оценка, чтобы не удивляться.
Переход от реального времени к качественному просчёту умножает время на десятки. Кадр, который рисовался за шестнадцать миллисекунд, будет считаться секунды или минуты.
Умножается это на число подкадров размытия и на число холостых кадров прогрева.
Практический ориентир: перед запуском длинной анимации посчитать один кадр и умножить. Неприятные открытия лучше делать заранее.
Сравнение с классическим рендером всё равно в пользу движка: он остаётся кратно быстрее, просто не мгновенным.
Порядок, который убирает переделки
Последовательность, дающая предсказуемый результат.
Отключить временнóе сглаживание и масштабирование разрешения. Включить накопление выборок и подобрать их число по одному кадру. Добавить холостые кадры прогрева. Настроить размытие движения и число подкадров. Отключить или расширить потоковую загрузку текстур. Выбрать вывод последовательностью кадров. Добавить нужные вспомогательные слои. Посчитать пробный отрезок в десяток кадров и проверить.
Пробный отрезок обязателен: он ловит проблемы, которых не видно на одном кадре, в первую очередь мерцание и подгрузку текстур.
На чём ломается чаще всего
Карточки
Частые вопросы
Почему кадры из движка выглядят хуже предпросмотра?
Чаще всего из-за потоковой загрузки текстур: в предпросмотре камера двигалась медленно и всё успевало подгружаться. Проверять надо на записанных кадрах при увеличении.
Сколько выборок ставить?
Столько, чтобы в тенях и на матовых отражениях не осталось шума. Определяется по одному кадру за пару минут, а не подбирается вслепую.
Зачем нужны холостые кадры?
Эффекты, накапливающиеся между кадрами, при поштучном просчёте начинают с нуля. Холостые кадры дают им набрать состояние до записи.
Что лучше, кадры или видеофайл?
Последовательность кадров: устойчива к сбоям, позволяет продолжить с места остановки и не теряет качество на сжатии.
Заменяет ли это классический рендер?
Для многих задач да, особенно для архвиза и анимации в реалистичном стиле. Там, где нужна физически точная трассировка света, разница в качестве всё ещё есть.
Посчитайте пробный отрезок в десяток кадров, прежде чем запускать анимацию на ночь. Он ловит и мыло, и подгрузку текстур, и мерцание.