Запекание симуляции нужно потому, что считается она один раз, а используется много. Между этими двумя состояниями лежит кэш, и именно с ним связана большая часть проблем: он теряется при переносе файла, не обновляется после правок или внезапно оказывается пустым в момент запуска финального рендера.
Посмотрим по пунктам, как устроено запекание, чем отличаются режимы хранения, что ломается при переносе и как отдать симуляцию в движок.
Зачем вообще запекать
Три причины, из которых следует всё остальное.
Скорость. Посчитанная симуляция воспроизводится мгновенно. Без кэша каждая перемотка означает пересчёт с первого кадра.
Стабильность. Симуляция зависит от порядка вычислений. Без кэша один и тот же кадр может посчитаться по-разному, и при рендере на нескольких машинах результат разъедется.
Возможность править. Запечённая симуляция становится данными, которые можно редактировать, обрезать, комбинировать.
Третий пункт недооценивают: после запекания симуляция перестаёт быть чёрным ящиком и становится обычной геометрией или набором точек.
Два режима хранения
Различие, из-за которого чаще всего теряются данные.
Внутри файла сцены. Кэш хранится в самом файле. Удобно: один файл, ничего не теряется. Неудобно: файл раздувается до гигабайтов, и сохранение начинает занимать минуты.
Во внешней папке. Кэш пишется отдельными файлами по кадрам. Файл сцены остаётся лёгким, кэш можно передать отдельно или удалить.
Практическое правило: короткие симуляции внутри, длинные снаружи. Граница проходит там, где файл сцены становится неудобно тяжёлым.
Главная проблема внешнего режима: путь к папке. Перенесли файл на другую машину, а кэш остался по старому пути и не нашёлся.
Относительные пути
Простое решение половины проблем с переносом.
Путь к папке кэша по умолчанию бывает абсолютным: полный путь на вашем диске.
Достаточно задать его относительно файла сцены, и кэш будет находиться где угодно, если папка лежит рядом.
Рабочая структура: папка проекта, внутри файл сцены и подпапка с кэшем. Переносится целиком, работает везде.
Отдельная тонкость при работе с сетевым хранилищем: путь должен быть одинаковым у всех, иначе каждый пересчитывает своё.
Когда кэш не обновляется
Симптом, который сбивает с толку.
Вы поменяли параметры, а симуляция выглядит по-прежнему. Кажется, что настройка не работает.
Причина: кэш уже посчитан и используется вместо пересчёта. Система не всегда понимает, что изменение требует нового расчёта.
Что делать: сбросить кэш явно перед пересчётом. Это отдельная команда, и без неё вы будете крутить параметры вхолостую.
Обратная ситуация тоже бывает: кэш сбрасывается сам от незначительного изменения, и часы расчёта пропадают. Защита от этого одна: хранить финальный кэш во внешней папке и делать копию.
Сколько занимает места
Планирование, без которого диск заканчивается посреди расчёта.
Объём зависит от типа симуляции и от разрешения. Объёмные среды вроде дыма и огня занимают больше всего: каждый кадр это трёхмерная сетка значений.
Жидкости с частицами тоже тяжёлые, особенно с высокой детализацией поверхности.
Ткань и твёрдые тела занимают немного: это положения вершин или объектов.
Практический ориентир: перед длинным расчётом посчитать десять кадров, посмотреть размер и умножить. Обнаружить нехватку места на трёхсотом кадре неприятно.
Про то, как это вписывается в общий объём проектов, есть материал про SSD для 3D-проектов.
Сжатие
Компромисс, который стоит понимать.
Кэш можно хранить сжатым. Место экономится заметно, чтение замедляется.
Для работы в вьюпорте сжатие мешает: перемотка становится рваной.
Для архива и передачи помогает.
Отдельный вариант это уменьшение точности хранения. Половинная точность занимает вдвое меньше и для большинства визуальных задач неотличима. Для физически точных расчётов нет.
Типичные срывы расчёта
Что идёт не так и почему.
Карточки
Про проблемы столкновений подробно есть в материале про провалы ткани сквозь объект.
Кадры разгона
Приём, решающий проблему неверного начала.
Ткань в начальном кадре висит неестественно: она ещё не упала под собственным весом. Жидкость стоит ровной поверхностью.
Решение: начать симуляцию раньше, чем начинается нужное действие, и дать ей прийти в естественное состояние.
Сколько нужно: обычно десятки кадров, для тяжёлых тканей больше.
Альтернатива для ткани: зафиксировать полученное состояние как новое начальное. Тогда разгон не нужен вовсе, и симуляция стартует с правильной формы.
Шаг расчёта и точность
Параметры, определяющие устойчивость.
Симуляция считается дискретными шагами. Чем быстрее движение, тем мельче должен быть шаг, иначе объект за один шаг проскакивает сквозь препятствие.
Увеличение числа шагов на кадр решает проблему провалов и взрывов, но замедляет расчёт пропорционально.
Отдельно существует точность решения столкновений: сколько раз система пытается развести пересекающиеся объекты за шаг.
Практический порядок: столкнувшись с провалами, сначала поднимать число шагов, потом точность столкновений, и только потом трогать остальное.
Экспорт наружу
Как отдать симуляцию в другой пакет или в движок.
Симуляция как таковая не переносится: в другом пакете её пришлось бы считать заново с другими настройками и другим результатом.
Переносится результат, то есть геометрия, меняющаяся покадрово.
Основной формат для этого хранит анимированную геометрию напрямую: положение каждой вершины на каждом кадре. Он объёмный, но универсальный.
Что учитывать: число вершин может меняться от кадра к кадру, и не все системы это принимают. Для таких случаев симуляцию приводят к постоянной топологии.
Отдельно объёмные среды: они экспортируются другим форматом, хранящим сетку плотности.
Симуляция в движке
Альтернатива экспорту.
Часть эффектов проще пересчитать в движке, чем переносить: ткань на персонаже, простая физика предметов, разрушение.
Что переносить всё-таки приходится: сложные симуляции, которые движок не воспроизведёт, и всё, где важен точный повтор.
Критерий выбора: если результат должен быть одинаковым каждый раз, переносим. Если может отличаться, считаем в движке.
Про сам механизм физики в реальном времени есть материал про физику в UE5.
Зависимости между симуляциями
Случай, где порядок расчёта становится критичным.
Часто одна симуляция влияет на другую: ткань лежит на объекте, который сам двигается по физике. Дым поднимается от объекта, который падает.
Пересчитывать их надо в правильном порядке: сначала то, что влияет, потом то, на что влияет.
Если порядок нарушен, вторая симуляция посчитается по старому положению первой, и результат разъедется.
Практический приём: запечь и зафиксировать первую симуляцию, убедиться, что она больше не пересчитывается, и только после этого считать вторую.
Симптом нарушенного порядка: всё выглядело правильно, а после перезапуска файла разъехалось.
Расчёт на нескольких машинах
Практическая сторона для длинных симуляций.
Симуляция, в отличие от рендера, плохо распараллеливается: каждый кадр зависит от предыдущего, и разделить её между машинами нельзя.
Отсюда правило: симуляция считается на одной машине, рендер можно раздать.
Что из этого следует для рендер-фермы: кэш должен быть посчитан заранее и доступен всем машинам, иначе каждая начнёт считать своё.
Именно поэтому внешний кэш в общей папке это не удобство, а необходимость при распределённом рендере.
Разбор самой схемы есть в материале про домашнюю рендер-ферму.
Правка запечённого
Возможность, о которой забывают.
После запекания симуляция становится данными, и с ними можно работать напрямую.
Что можно сделать. Обрезать лишние кадры. Сдвинуть по времени. Замедлить или ускорить. Смешать два кэша. Поправить отдельные кадры вручную.
Последнее особенно полезно: один кадр с артефактом проще исправить руками, чем пересчитывать всю симуляцию ради него.
Именно ради этой свободы симуляции в производстве всегда запекают, а не считают на лету.
План действий
Схема, экономящая пересчёты.
Настроить симуляцию на низком разрешении и коротком отрезке. Добиться нужного поведения. Задать внешнюю папку кэша с относительным путём. Добавить кадры разгона. Посчитать десять кадров и проверить объём. Запустить полный расчёт. Сделать копию готового кэша. И только потом заниматься материалами и рендером.
Копия готового кэша это не перестраховка: случайный сброс после часов расчёта случается регулярно.
Чего делать не надо
Абсолютный путь к кэшу. Файл переехал, кэш потерялся.
Правка параметров без сброса. Настройки крутятся вхолостую.
Расчёт на финальном разрешении сразу. Часы уходят на проверку поведения.
Отсутствие кадров разгона. Неестественное начало.
Кэш внутри файла для длинной симуляции. Файл становится неподъёмным.
Отсутствие копии. Случайный сброс уничтожает работу.
Причёска живёт по тем же правилам: волосы в Blender 4.x тоже держат кэш и так же теряют его при смене диапазона кадров.
Частые вопросы
Почему симуляция не меняется после правки настроек?
Используется старый кэш. Нужен явный сброс перед пересчётом, иначе система показывает посчитанное ранее.
Где хранить кэш?
Для коротких симуляций внутри файла, для длинных во внешней папке рядом со сценой и с относительным путём.
Почему объекты проваливаются друг в друга?
Шаг расчёта слишком велик для скорости движения. Увеличение числа шагов на кадр решает это в большинстве случаев.
Как перенести симуляцию в другой пакет?
Экспортом результата в виде анимированной геометрии. Сама симуляция не переносится, переносится то, что она посчитала.
Сколько места занимает кэш?
От десятков мегабайт для ткани до десятков гигабайт для объёмного дыма высокого разрешения. Оценивать надо по первым кадрам до запуска полного расчёта.
Задайте внешнюю папку кэша с относительным путём до того, как считать. Потерянный кэш после переноса файла обходится дороже минуты настройки.