Автор описывает собственный набор инструментов для создания крупного, полностью играбельного окружения (пустынный биом Saros) на связке Blender + Unreal Engine 5. Главная цель — сделать процедурные решения удобными для художника окружения, а не только мощными технически.
Философия инструментов
Выделены три ключевых принципа дизайна тулов:
- Минимум трения: чем сложнее и менее интуитивен тул, тем выше шанс, что художники его игнорируют и создают неоптимальные сцены.
- Минимум ожидания: долгие пересчёты (по 5 минут и больше) ломают цикл итераций — сложно понять, какие правки дали результат, и проще смириться с плохим аутпутом.
- Максимум контроля художника: в AAA‑производстве нужны точные правки по фидбеку дизайнеров и руководителей; если тул не даёт ручного контроля, он не подходит.
Генерация фрактур в Blender
Задача — заранее «разломать» модульный архитектурный кит так, чтобы сохранить модульность и бесшовность. Любые швы на стыках модулей (например, колонн) сразу выдают границы модулей.
Обычно для оффлайн‑фрактур используют Houdini (RBD Fracture и др.), но это противоречит принципам автора:
- дополнительное ПО повышает порог входа;
- нужны импорты/экспорты, растёт время разработки;
- любое изменение меша требует повторной обработки.
Инструмент разрушения в Unreal Engine
Следующий шаг — внутриигровой тул, позволяющий левел‑артисту неразрушающе «ломать» архитектуру. Вместо Houdini HDA автор использует заранее фрактуренные в Blender меши, чтобы обеспечить отзывчивость и независимость от внешних связок.
Общая идея:
- воссоздать цельный меш из набора мелких фрагментов;
- удалять/прятать фрагменты по пересечению с «сферой разрушения».
Ключевая техническая проблема — как сохранять и передавать в движок информацию о позициях фрагментов и их центрах, чтобы:
- в Blender фрагменты были раздельными;
- в Unreal их можно было корректно собрать и управлять ими через Blueprints.
Реализация сделана через Component Script в Blueprints. Основная нерешённая задача — рандомизация (случайный флип мешей) реализована не полностью. Ещё один минус — каждый новый Blueprint создаёт новый Instanced Static Mesh компонент. Автор рекомендует рассмотреть батчинг инстансов (например, через ISMCellTransformer при использовании World Partition) или сразу смотреть в сторону Unreal Engine PCG для более оптимального решения.
Ограничения:
- нет интеграции с существующим Array Tool (объединение логики возможно, но трудозатратно);
- падение производительности при большом числе сфер разрушения (>150), оптимизация не найдена.
PCG‑рассеивание с контролем художника
Процедурное рассеивание (debris, растительность) через PCG в Unreal даёт производительность и гибкость, но по умолчанию мало контроля по сравнению с ручной расстановкой или кистью фолиажа. Для продакшн‑окружения это критично: нужно управлять композицией, читаемостью пути игрока и сторителлингом.
Автор ставит задачу сделать PCG одновременно процедурным и управляемым. Важный приём — использование узла Actor Data с настройками All World Actors, By Tag и Get Single Point. Это делает PCG‑граф «осведомлённым» о контексте уровня. В статье пример — рассеивание обломков вокруг разрушенной архитектуры, но подход можно расширять на другие задачи.
Выводы
- Процедурные инструменты должны снижать трение и время ожидания, иначе художники их избегают.
- Максимальный ручной контроль — обязательное требование для AAA‑окружения и точного фидбека.
- Отказ от внешних тулчейнов (Houdini) упрощает пайплайн, но требует продуманной логики в Blender и UE.
- Фрактурирование с последующим управлением фрагментами в UE возможно на Blueprints, но упирается в производительность и менеджмент инстансов.
- PCG в UE можно сделать «осмысленным» и управляемым через Actor Data и работу с данными уровня.
- Утверждение: «Procedural solutions are undoubtedly powerful and common in productions, but they are also a source of frustration for artists» — подаётся как универсальный факт. На практике отношение к процедурным пайплайнам сильно зависит от конкретной команды, качества UX инструментов и уровня подготовки художников. Это скорее распространённое мнение части специалистов, чем общепринятая истина.
- Утверждение: «If a tool feels complex or unintuitive, artists will avoid using it. That can lead to unoptimized or destructive environments» — причинно‑следственная связь сформулирована слишком жёстко. Да, сложные и неудобные инструменты действительно снижают вероятность их использования (это подтверждается общими принципами UX и исследованиями по принятию инструментов), но переход именно к «неоптимизированным или деструктивным окружениям» не является строго установленным следствием и зависит от множества факторов (процессы ревью, требования продакшена, наличие альтернативных инструментов).
- Утверждение: «When a tool requires 5 minutes of waiting for the output, the artist may have forgotten which changes led to this result» — выглядит как обобщение без опоры на конкретные данные. В когнитивной психологии действительно есть эффекты, связанные с забыванием деталей действий по мере увеличения задержки, но конкретный порог «5 минут» не подтверждён исследованиями в контексте DCC/геймдев‑инструментов и является скорее субъективной оценкой автора.
- Утверждение: «In AAA productions, every detail matters» — чрезмерное обобщение. В AAA‑проектах действительно высокие требования к качеству и детализации, но «каждая деталь» в буквальном смысле не имеет одинаковый вес; приоритизация всегда присутствует (важность зависит от видимости, геймплейной значимости, сроков и т.д.). Это скорее риторическая гипербола, чем точное описание индустриальной практики.
- Утверждение: «If the tool lacks sufficient manual control, it will not meet their demands» (про AAA‑продакшены) — слишком категоричное причинно‑следственное утверждение. На практике часть пайплайна может быть более автоматизированной, а часть — с ручным контролем; иногда ограничения инструмента компенсируются другими стадиями или ролями. Нельзя однозначно утверждать, что любой инструмент без «достаточного» ручного контроля обязательно не удовлетворит требования продакшена.
- Утверждение: «PCG … by default … lacks control for the artist» — спорное обобщение. Многие современные PCG‑системы (включая инструменты в Unreal, Houdini и др.) как раз развиваются в сторону богатых средств художественного контроля (маски, гайды, правила, ручные оверрайды). Проблема недостатка контроля действительно часто возникает в плохо спроектированных графах или при «чистой» рандомизации, но говорить, что PCG «по умолчанию» лишён контроля художника, некорректно как общее правило.
