Подробный разбор static mesh, instant static mesh и hierarchical instant static mesh в Unreal Engine для оптимизации сцен.
Key Takeaways
- Static mesh лучше подходит для уникальных объектов и интерактивных элементов.
- Instant static mesh значительно снижает количество дроуколов при большом числе одинаковых объектов.
- Dynamic instancing работает ограниченно и не заменяет полноценное инстанцирование.
- LOD и кулинг уменьшают нагрузку на GPU, но не всегда снижают дроуколы.
- Hierarchical instant static mesh полезен для оптимизации больших и сложных сцен.
What the video covers
- Объяснение различий между static mesh (SM), instant static mesh (ISM) и hierarchical instant static mesh (HISM).
- Разбор влияния типов мешей на производительность: FPS, дроуколы, использование памяти.
- Описание процесса передачи данных от CPU к GPU и рендеринга мешей.
- Анализ количества дроуколов в зависимости от числа материалов и экземпляров мешей.
- Пояснение динамического инстансинга и его ограничений.
- Рекомендации по использованию static mesh для уникальных объектов и интерактивных пропсов.
- Преимущества и недостатки instant static mesh при большом количестве одинаковых объектов.
- Обсуждение кулинга, LOD и влияния на производительность.
- Советы по применению hierarchical instant static mesh для больших сцен и оптимизации.
- Разбор типичных ошибок и практических кейсов использования разных типов мешей.
Chapters
- 00:00Введение и обзор static mesh, instant static mesh и hierarchical instant static mesh
- 03:54Влияние материалов на количество дроуколов
- 07:13Когда использовать static mesh: уникальные объекты и интерактивные пропсы
- 11:09Принцип работы инстанцирования и GPU вызовов
- 14:08Преимущества instant static mesh для плотных групп объектов
- 17:48Проблемы с рассеянными объектами и оптимизация
- 22:14Вопросы и ответы по выбору типа мешей
- 25:53Особенности освещения и влияние на производительность
Full Transcript — Download SRT & Markdown
Speaker A
Привет всем. Хочу максимально подробно рассказать про instant static меши, static меши и ierarical instant static меши. И мне кажется, эта информация должна быть крайне полезна всем, кто работает с движком или делает уровни. Думал, с чего начать, а решил просто взять чужое видео и как пример
Speaker A
показать. Здесь, э, две сцены. Это Sample C и из матрицы. Тут видно очевидное различие по FPS, по дроуколам, по присам, по всем параметрам. И да, здесь есть ключевое отличие в том, что в одной сцене используется static меш, а в другой instant static меш. И далее я хочу пройти
Speaker A
по вот этому ключевому отличию, как оно влияет на сцену, как оно работает с памятью, что такое static меши, что такое instant static, когда лучше использовать то, когда лучше использовать это, в чём частые ошибки, частые ошибки и тому подобное. В принципе, постараюсь захватить абсолютно всё.
Speaker A
В каждом блоке про instant static меши, в static меши будет небольшой душный кусочек, но он важен для того, чтобы понять, в чём разница и как с этим работать. Что такое static MH? Это в нём хранится набор неизменяемых вершин, индексов, EV и данные о коллизии, которые отображаются здесь
Speaker A
в панели Details. SMK static mesh component. Далее SMK компонент static меша. И на уровне он хранит трансформ с локацией, ротацией и скейлом. Это понятно. Также какие материалы он использует, какие настройки лот применяются, если актуально и тому подобное. Пути данных ЦПУ в GPU - это
Speaker A
то кусочек, который я сказал будет душный в каждом фрагменте, но он важен. Сначала идёт, а я включу визуализацию. Сначала идёт Gamead. Он хранит компонент и ловит данные о трансформе каждого static mesh'а. Затем render tradт примитив proxy. Это инкапсуляция данных, которые зеркально
Speaker A
отражаются для визуализации параллельно игровому потоку. Затем генерирует FMш batch для каждой секции материала. Сложны, возможны для кого-то слова, но главное запомнить, что здесь создаётся FM batch для каждой секции материала. Секция - это количество материалов на объекте. Далее RHI trad.
Speaker A
Он пакует FMH Draw Commands в командный список и подключается низкоуровневый графический API. DX12, Vulkan. А в случае с DX11 RHI не создаётся, он происходит на render thread. Далее GPU.
Speaker A
Он читает вертекс, индекс буфер и константные буферы материалов, текстур, запускает вершины, пиксельный, глубинный шейдеры освещения. На этом всё. К этому моменту мы будем возвращаться, и далее я подробно буду говорить, что есть что. Вот это всё попадает в GPU сцен. На каждый примитив
Speaker A
заводится слот instance data. На это выделяется 16 млн ID. ID - это примитив ID или instance ID, целое число, которым шейдеры на GPU обращаются к данным примитива в буфере GPU сцены. То есть это максимальное число, которое Unreal Engine может закодировать в одном кадре. Объясню. То есть
Speaker A
сейчас у нас 322 актора, это 322 уникальных ID. В случае с каким-то большим открытым миром, возможно, перевалится это ограничение в 16 млн, что довольно-таки сложно сделать. Но помимо количества их количество на сцене, есть ещё вес и то, сколько дроу вызывает каждый, так как
Speaker A
каждый static mesh компонент с одной секции вызывает один дроукол. То есть данный куб на сцене вызывает всего лишь один дроукол. Это условно. Далее скажу, почему условно. По факту это не один дроукол.
Speaker A
Один меш с одним материалом вызывает один дроукол, но один меш с тремя материалами вызывает три дроукола, а 100 одинаковых мешей с тремя разными материалами дают 300 дроуколов. То есть, если на сцене будет 300 таких кубиков с тремя разными материалами, это будет 300, а 100 кубиков с тремя
Speaker A
материалами, это будет 300 дроуколов. И опять же, это не так, а не будет намного больше. Возможно меньше, если они расположены рядом, они одинаковая форма, один материал. А об этом тоже немножечко дальше скажу. Представить сцену, например, машина, где, ну, всё разделено на раздельно материалы:
Speaker A
стёкла, металлик, кожа, десятки разных материалов. И даже маленький кусочек, если маленький кусочек этой машины попадёт в кадр, движок должен сделать вызов и просчитать отрисовку всей геометрии со всеми её текстурами. А если стоит учитывать, что имеется Depth pass, Base, shadow depth, Virtual
Speaker A
Shadow Map, если используется Motion Blur, это всё добавляет по одному дроуколу, то есть суммарно пять-шесть на вызов одного объекта с одним материалом. И тут есть одно эмпирическое правило, что количество базовых вызовов умножается на 4,6. А если ещё добавлены светильники, ну, допустим,
Speaker A
directional light добавляет ещё один дроукол на один объект, а если point light, то шесть дроуколов для shadow depth passа прохода. И о чём сказал, к чему вернусь? Dynamic instancing. Если материал, лот, vertex factory совпадают, копии близко, то движок может их сливать вместе, уменьшая дроуколы. Но на
Speaker A
это не стоит прямо сильно надеяться. Это работает только в форвардрендере или на шейдер модели 5.
Speaker A
И он не объединяет разные секции. То есть, э, в данном случае, если я размещу размещу так 100 кубов друг с другом рядом, то dynamic instancing сработает, но он не будет работать, если между ними большая дистанция, если разный материал применяется, если разная форма и тому
Speaker A
подобное. На dynamic instancing не стоит надеяться. Поэтому, если используется большое количество одинаковых объектов, то лучше приходить к инстанцированию. Это будет немножечко дальше.
Speaker A
Также имеется кулинг и лот. Движок отбрасывает невидимые примитивы до стадии RHI, но расчёт списка всё равно идёт на ЦПУ. Лоды уменьшают нагрузку на GPU, и она тратит меньше времени на вершинный шейдер. Также кэш себя чувствует лучше, и вертекс буфер становится короче, но лоды
Speaker A
не уменьшают дроукол. А с transition, когда есть в материале свойства плавного перехода одного, ну, как одного лода в другой, то это на пару кадров может увеличивать дроуколы в два раза. Так когда, если они столь плохи, лучше использовать статик-меши? Static меши
Speaker A
лучше использовать, если это уникальный объект на уровне, а какая-то достопримечательность, геометрическая иллюстрация в зоне интереса или что-то тому подобное. Интерактивные пропсы с логикой. Включаемые лампы, двери, окна открываемые. Если объекты, то с часто изменяемыми параметрами. Цвет, материал, размер,
Speaker A
позиция. Маленькая сцена примерно с 500 объектами разница особо не почувствуется, будь то инстансы или нет. То есть движок переработает и ту, и ту сцену. Если вот сейчас здесь 337 акторов, здесь можно было бы и не использовать совершенно инстансы. Ну, хоть они здесь и используются.
Speaker A
То есть на маленькой сцене можно не использовать, если уникальные нанит объекты единожды встречаются в сцене. Тоже могут быть static мешами. Временные пропсы вроде заспавненного оружия, патронов, падающих коробок, ну, подбираемых в смысле, тоже могут быть static мешами. Так,
Speaker A
немножечко назад уточню про заспавненное оружие, патроны. Это то, что мы подняли и всё. Это не патроны, которые там гильзы вылетают, а оружия для этого инстанцирования, негары и тому подобное. Объекты, где требуются разные коллизии или render custom depth. А, ну последнее с инстансами тоже возможно. И, разумеется, элементы прототипирования и блокаута. Это очевидно, тут нет смысла
Speaker A
инстанцировать. А если инстанцировать, то особо ни на что это не влияет. Просто удобнее работать со static мешами в данном случае. В чём основные минусы и когда лучше не использовать? Минусы. А
Speaker A
минусы станут понятнее, если разобрать лучше, как работают инстанцированные сетки. Static меши
Speaker A
вызывают много дроуколов. То есть, например, модульное здание на 500 кусочков с одним или двумя материалами вызовет 500 000 дроуколов плюс-минус с учётом динамического инстанцирования, плюс prepass, shadow pass, включен motion blur, источники освещения намного-намного больше. Они дают большой CPU overhead. Один static mesh компонент - это 6-8 КБ управленческих данных UC + сцен proxy, а десятки
Speaker A
или даже сотни тысяч копий забивают память и сборщик мусора. Возможно достижение лимита GPU сцены. Это навряд ли, так как лимит 16 млн, но всё же возможно его как бы достичь. Дополнительные расходы на тени, depth pass, Virtual S
Speaker A
Call, когда точно не нужно использовать статикши. Если это фольge, трава, лес, это тысячи копий одного, одних и тех же мышей, дроукол губят ЦПУ и перегружает GPU. Модульные стены, плитка пола, кирпичи, неинтерактивные окна, заборы, дороги, камни, почти 70-80% окружения. В общем,
Speaker A
это идентичные элементы, которые можно перевдить в инстанции. Процедурные элементы или процедурный мусор, осколки пули, отваливающиеся части чего-то. При спавне большого количества в кадре ЦПУ ловят бутылочное горлышко. Лучше тут неагара или инстансы. Опять же открытые миры, уже несколько раз сказал, с большим количеством а инстансов, где о стаticмеши, где возможно достичь
Speaker A
лимит в 16 млн primмиitive ID. эффекты, которые можно было бы собрать в один материал. Например, дорожные столбы со светом. Разные статикмеш компоненты с разной эмиссией, светом увеличивают вызовы. Желательно унифицировать материал и инстанцировать его. И, конечно, минимум стак МШ
Speaker A
компонентов в проектах рассчитаны на виртуальную реальность, автономную или мобильные устройства. Далее про instant static Mh. Что это такое? Instant static mesh component - один компонент, который может хранить тысячи копий одного и того же меша. Каждая копия называется instance и
Speaker A
состоит из fтрансф и до восьми флот кастомных данных. Геометрия, вертексы, индексбуферы, материалы у всех копий а одинаковые, точнее одни и те же копии. И возможно их изменение только внутри материалов путём изменения флот данных на каждом интенсе до восьми. Самое главное, движок
Speaker A
подготавливает одну GPU команду на всю пачку. То есть, если у нас есть, а, не знаю, представить, что это, стены, дома, машины и тому подобное. Сейчас это всё статикши, но если их перевести в instстаtic проерхил будет позже, будет дальше одна пачка, что подразумевается, то есть все они хранят
Speaker A
информацию, точнее один, грубо говоря, передаёт информацию всем остальным копиям. Это называется одна пачка. Поэтому GPU вызов на кадр равен количеству секций, материалов, а не количеству копий, как это происходит со статикшами. Если бы со статикшами это было бы четыре вызова, то
Speaker A
сейчас это один вызов на на количество секции, в данном случае один. Пути данных CPU в GPU. Gamead добавляет, убирает инстансы в массив P instance data хранит UC плюс компактный массив Perceata.
Speaker A
64 байта на копию. Ранее я говорил, запомни цифру, то есть она меньше. Render tradет данные в fst static mesh instance data формирует один fm mesh баch на секцию loot и всё уходит одним куском.
Speaker A
Разница была разница с предыдущим вариантом в том, что там каждый отправляет информацию на коли на количество материалов, а здесь один на всю пачку. RHI tradет F mesh draw command в командный список и подключается низкого уровня в графические IP. также DX12 вулкан и просто шагает по instance
Speaker A
ID и читает трансформы структурбуфер, то есть по каждому. GPU читает vertex index buфер выполняет один дроукол, в котором шейдер обращается к нужному instance ID и запускает вершины, пиксельные глубины и шейдеры освещения. Почему это важно? Один из ключевых моментов в последнем
Speaker A
пункте с GPU, где происходит только одно обращение ко всем инстансам, а не каждый мэш сам его делает.
Speaker A
Экономия порядка X10 метадаты и Draw call. Для сравнения static Mhent - это 672 байта на объект.
Speaker A
Свой вертекс и индекс буфер у каждой копии с 1.000 объектов - это 672 Кб. Instant static Mh 64 байта с 1.000 копией примерно 600 байтов. На сам компонент получается 64 Кб, что в 10 раз меньше.
Speaker A
То есть instant static Mage на те же 1.000 копий экономит порядка 10 раз памяти по метадате и даёт всего один друкол вместо тысячи. Ключевое важное отличие. ЦУ - одно из главных узких мест цены.
Speaker A
Инстанцирование снимает сотни тысяч вызовов и освобождает общий гейм и рендертре. Сотни тысяч static Mh компонентов - это сотни мегабайт метадаты. Дорогой Mark и Sweep Instant static Mhдит это к десятка мегабйт и одному Uжекту. Существует лимит платформ мобилок, квестов,
Speaker A
свечей, стимдеков и бюджет на дроуколы пара сотен, а не тысячи, как на ПКХ. Instant static Mh делают такие сцены реальными. Баланс нанит. Нанит помогает с GPU. Нанит подбирает плотность так, чтобы один трикластер был равен одному пикселю, тем самым разгружая вершины. Но
Speaker A
Draw call он не убирает. Ну и более того, при неправильном использовании увеличивает оверхad с пересечением на нитной геометрии. А Instatic Mh и Ararchical Insatic Mhмколов.
Speaker A
Когда лучше использовать Instant Static MH? Сотни тысяч одинаковых, стоящих плотным пакетом: кирпичная кладка, модульные стены, ряды кресел, лестничных ступеней, заборы, горстри камней, один дроукол на секцию активного лот. Вместо эндого количества вызовов процессоргружается в 10-100 раз. Все копии делят один материал и лот. С версией Unreal Engine 5 и4 лот включен
Speaker A
на каждый instance. Ранее было один лот на весь компонент. Процедурно спавнящийся мусор, осколки, куски пули. Если это не не Агара, ad instance быстрее и дешевле, чем пологить 1.000 U static Mh Component. Метаданные 64 байта на штуку вместо 672 байт. То есть, а, ну,
Speaker A
плохой пример, но вот эти вот искорки могли были бы быть, ну, это сейчас не Агара, но могли бы быть спавнящимися элементами, и они спокойно могли бы, о, отскакивают, да, и они могли были быть спокойно instantн такмешами, где происходит ad instance, где всего лишь 64 байта на копию. Ну,
Speaker A
кто-то мог бы сделать подобное спавнищимися статикмешами, что абсолютно бессмысленно. Навряд ли бы кто-то так сделал. Плохой пример. Эффекты Неагара, где геометрия повторяется. Неагары умеют писать трансформ напрямую в instanceбфер, и дроукол остаётся один. Пробсы внутри зданий: лампы, выключатели, трубы, мебель. Если это не интерактивные, юзабельные переносимые пробсы,
Speaker A
если имеется сильная разрозненность в пространстве, то лучше разделять на несколько instant staticше или перейти креar instant static мешам. Нанит меши, которые повторяются десятки и сотни раз. Нанит экономит полигоны, а instстакши убирает дроукол. Но нужен один материал на повторяющихся объектов, иначе будет дубль компонента. Ну и, соответственно,
Speaker A
геометрия и сам должны быть тоже одинаковыми. Проекты под слабое железо, мобильные проекты VR, Nintendo Switch в виду ограничного бюджета данных платформ на количество draw. Если нужно загружать через data layer или стриминг-левелы, будет работать десятки быстрее, чем static Mh. То есть,
Speaker A
если я через стриминг мне нужно загрузить целую гигантскую сцену с 1.000 объектов, то, конечно же, а не спать не отвлёкся. Да, проекты под слабое железо, типа Nintendo Switch, VR и тому подобное.
Speaker A
Там ограничен бюджет, поэтому нужно, ну, чтобы в него попасть, очень сильно уменьшает дроуколы. Если нужно загружать сцену через data layer или то сцена с тысячей пропсов, даже будет они, будь они одинаковые, она загрузится намного-намного быстрее. А могу показать пример. У меня зависнет
Speaker A
всё, если я покажу пример. В целом я сделал небольшой блюпринт, который заспавнит мне нужное количество предметов любого статикша, хоть сотни тысяч. И я просто не смогу это записать, потому что когда я загружаю и выгружаю, очень сильно нагружается система. Я не могу записать
Speaker A
момент, насколько это тяжело. Но в целом загрузка статикшей, не знаю, в сотни, наверное, в десятки, сотни раз тяжелее, чем загрузка инстансов, потому что инстансы загружаются просто за доли секунды.
Speaker A
Это очень важно для тех, кто разделяет логику на деталей или стриминг уровни. А загружать уровни с statтикшами, повторюсь десятый раз, намного тяжелее. Если хотите, чтобы сцена загружалась намного быстрее, там должно быть как можно можно больше инстансов. В чём основные минусы и когда
Speaker A
лучше не использовать instстаticши? А минусы в том, что они подвержены грубому олюнкулингу. Если хотя бы один экземпляр попадает в кадр, GPU рендерит всю пачку. А это лишняя растеризация и лишняя затрата на пиксели. То есть вот у меня здесь есть инстансы, будь их десятки тысяч. Вот
Speaker A
так вот туда вдаль уходящих. И если один попадает, это дорога. Представь, что это длинная длинная дорога. Если один кусочек этой дороги попадёт мне в кадр, то вся пачка сразу загружается. Да, из-за этого получается, что это плохо в рассеянных ценах, когда пробс разбросаны на большом
Speaker A
расстоянии вне кадра. Один материал плюс общий набор лот. Свойства задаются на уровне компонента, а не на уровне экземпляра. Компонент, в данном случае вот компонент. Экземпляр - это каждый его instance ID. И материал мы можем задавать только для компонента, а не для всей пачки. Но мы можем
Speaker A
регулировать материал через custмдату. В материале есть специальные ноды для того, чтобы для каждого инстанса можно было регулировать материал, но это немножечко усложняет работу, в принципе. Далее, возможно, покажу а сделаю в конце раздел с лайфхаками. [ __ ] я, кажется,
Speaker A
пенсионер. Проблемы за печкой. Нет уникальной лайтмапы. Лайтмапа будет одна для всех копий. Вот это да, действительно проблема, потому что если мы используем запека запечённое освещение и один пробс находится на свету, другие в тени, то при запекании здесь появится лай
Speaker A
ну определённая лаймапа, которая будет распространяться на все копии, что, ну, будет некрасиво выглядеть, то есть там будет какие-то точки, плюс наложение ймапа. Возможно, в целом очень будет плохо выглядеть, но если использовать Lightmask, то такой проблемы не будет. Колзии,
Speaker A
тени общие, а нельзя отключить коллизии только одного экземпляра. Ну, я имею в виду, что каждый экземпляр имеет свою коллизию, такую как было у исходного объекта. Данные на экземпляр ограничены.
Speaker A
Это то, что я говорил про восемь флот и четыре вектор для каждого инстанса. В целом, это снижает вариабельность, если нужно большое количество различно выглядящих материалов в одном компоненте.
Speaker A
Ну и сложность или невозможность даже создания гейм-логики, потому что с ними, как я сказал, достаточно сложно работать. Гейм-логики, в смысле сделать его каким-то уникальным, подбираемым, и тому подобное, когда точно их не нужно использовать, когда копии разбросаны на километры
Speaker A
и видна лишь малая часть. Ну, как я привёл пример про дорогу. Для этого будет альтернативал instatic Mh. Тогда BVH bowing volume отсечёт невидимые кластеры. Про это скажу дальше. В чём плюс, когда буду говорить проекat Mion? Если каждой копии нужен свой материал или уникальные коллизии,
Speaker A
альтернатива разбивать на разные секции instant static Mion с разными материалами. То есть, допустим, здесь у нас такой будет, а в каком-то другом месте будет вот такой. По сути, это одно и то же, только с разными материалами. Ну и рендерится, если этот попадает в кадр,
Speaker A
рендерится эта пачка. Если этот, то рендерится эта пачка. подобным образом можно разделять, когда нужна высокоточная оклюзия, потому что если только часть пачки попадёт, ну, как бы в кадр, а другая будет скрыта стеной. И таких моментов достаточно много, когда у нас там сменяющиеся
Speaker A
постоянно ракурсы и попадают вот эти вот кусочки инстансов, они постоянно рендерят всю пачку, что достаточно неэффективно, поэтому лучше разделять подобное на разные пачки. Ну, то есть создавать много разных instant staticшей по зонам видимости. Ну или переходить на иерархил
Speaker A
static в виду плюсов, которые я назвал, и далее подробней про них скажу. Если нужно больше восьми флот кастом даты на экземпляр. И разумеется, если количество приближается к 16 млн, то нужно разбивать цену на уровне или использовать на сауровне или использовать иерархил instant
Speaker A
staticмши. Далее про hierarchical instant static. Что это такое? Также плюсы, минусы. Это для наглядности. Если ранее я использовал и static MH, то сейчас это будет hierarchрical, instant static mesh hierarchical. И что же это такое? Один компонент, который может хранить
Speaker A
тысячи копий одного и того же Мэша, является расширенной версией Instant static Шкомпонента. Точно также один Мэш - один материал, но тысячи экземпляров дополнительно строится по сравнению с instanticкмешами. BVH, bounding, volume, иерархия. Это дерево кластер 3, которое группирует инстансы
Speaker A
в пространственные кластеры, узлы и хранит AA, BB и индексы. То есть мы можем простыми словами, имея тысячи также длинную длинную длинную дорогу с тысяче копий, если мы видим только один, а строит bowing volume и отсекает то, что мы не видим, и эта пачка не рендерится. Ну то есть элементы этой
Speaker A
пачки. И благодаря этой иерархии движок быстро отбрасывает целые кластеры, если они вне кадра или не видны, или перекрыты другими объектами. Также выбирает лот по кластеру, что важно, если не используется на нит. Самое главное, движок подготавливает одну GPU команду на всю пачку,
Speaker A
поэтому ЦПУ вызовов на кадр равно количеству секций материалов, точно так же, как у instant static Mшей. Но добавляется точная работа кулинга, чего нет у instн staticм. Поэтому как бы тут и плюс есть, и минус в том, что есть отбраковка, но эта отбраковка чего-то стоит. Пути данных cpu,
Speaker A
GPU Gamread, а, добавляет, убирает инстансы в массив PER instance SMA хранит один и U, то же самое, как у instanceкмша. Потом появляется cluster builder JT и RT. При спавне большого числа инстансов или после массовых изменений вызывается F cluster builder build 3 и строится обновление
Speaker A
BVH. Render tradт F primitive stand proxy, ссылается на кластер 3 формирует один FMШ на каждый видимый кластер секцию. Примерно как у instant staticшей, только здесь на кластер секцию. Часть отбракована, часть видима. RHI пакует FM draw command в командный список.
Speaker A
И каждый дрокол получает индекс кластера в реange экземпляре. Мм, наверное, всё же покажу. Вот где мой спавнер. Просто для примера решил сделать 10 де степени в десятой степени на расстоянии 500 для того, чтобы заспавнить очень-очень много кубов и далее перевести их просто 1.300. Я
Speaker A
всё это упаковываю в раal Instста static Mh и удаляю оригиналы. Теперь здесь 1.000 с лишним экземпляров в одном компонентера и static mesh. И что происходит, когда мы смотрим на вот эту, например, секцию? Примерно генерируется кластер того, что мы видим, и посылается один draw-кол
Speaker A
на эту пачку. Вот в данном случае FRIADE пакует FM draw command в командный список. Каждый draw call получает индекс, кластер и range экземпляров. То есть они имеют определённую последовательность.
Speaker A
у себя в компоненте от одного до там сколько тыся от нуля до 1.000 с лишним сколько их здесь. Далее GPU читает Vertex индексбуфер выполняет один дроукол на кластер ну и запускает вершины, пиксельные глубины и шейдеры. Освещение для нужных instance ID в кластере уже не для всей пачки,
Speaker A
как это было с инстанцами. И почему это важно? Потому что ЦПУ экономия вместо энного количества вызовов staticм компонентов или грубого кулинга. Я говорю про instant staticши, потому что в случество вызовов равное количество копий, а в случае с инстанцами было бы количество компонентов
Speaker A
плюс количество экземпляров. Ну также один плюс сколько-то, ну, всего один дроукол. Здесь же всего лишь один дроукол на видимый кластер, не на всю пачку. И GPU экономия, дальние закрытые кластеры даже не попадают в пайплайн. видимый получает корректный лот, уменьшая количество обрабатываемых
Speaker A
вершин и трафик VRAM. Пометка: при плотных кластерах аерархил и staticшей почти такой же дешёвый, как instant staticши, а при разбросанных намного эффективнее, чем instant staticмши. И но всё равно на порядок дешевле, чем 1.000 static Mh компонентов. То есть подобное расположение,
Speaker A
ну, практически ничем не будет отличаться от instстаticше ввиду их близкого расположения, потому что так или иначе затраты, которые уходят на формирование BVH, bounding volume, иерархии, не компенсируют то, что происходит с рендером всей пачки Prinstance static Mion. Но в любом случае
Speaker A
и тот, и тот вариант намного-намного дешевле, чем использование static Mh-компонентов. Просто static Mш компонентов без инстанцирования. Но это немножечко неподходящий пример вот вот эта вот картинка, потому что они ра находятся очень близко. И здесь, если перейти в режим видимости
Speaker A
там подобный, то да, это было сообщение из моего плагина. Кстати, у меня плагин есть.
Speaker A
Потом потом скажу, прорекламирую, что ли, что я записывают просто так, что ли, инфу такое высокое научно-технологическую. Ох, раздразил себя. А, не очень хороший пример, потому что в данном случае d динаic instancing сработает и количество FPS будет примерно одинаковое, что у инстансов staticшей,
Speaker A
у иерархии гонса static Mши, что просто устакший будет примерно одинаковые показатели и того, и того. Но это не относится уже к реальной сцене. Реальные сцены не так делаются. Поэтому мы увидели большую разницу на вот примере, который я показал из матрицы, из чужого видео в случае
Speaker A
разрозненности. То есть здесь кусок здоровенный, там кусок здоровенный, там тут дом, там дом, везде дома, везде дороги, везде заборы. А в данном случае будет разрозненность и будет, конечно, профит большой от иерархил instant static Mhy, но их важно использовать с умом ввиду вот того, что я
Speaker A
говорил, где и когда лучше использовать то или то, потому что если использовать iarical instстаticши, там где лучше были бы и instстаticши, мы теряем возможно доли миллисекунд. Но когда мы говорим о всей сцене, гигантской сцене с большим количеством объектов, ну, пусть там 30.000, 100-200.000,
Speaker A
Эти цифры становятся уже критичными. А у нас бюджет красивой, хорошей картинки - это всего лишь 8 мсекунд. Ну, 16 мсекунд с ориентиром на 60 FPS. Так, когда лучше использовать hierarchical Instant static Mesh? Это если большие открытые уровни с широко раскиданными копиями, то есть какая-то
Speaker A
городская местность, большие города, парки, а, леса и тому подобное. Это скалы, руины, обширные каменные нагромождения, контейнеры в доках. BVH баундин волюм иерархия отсечёт кластеры вне поля зрения или полностью перекрытый другими объектами. ЦПУ не посылает лишние дроуколы, а GPU не тратит
Speaker A
время на невидимые пиксели. Foliage и трава. Инструмент Foliage сам создаёт instance static Mh и Rapical Instant static Mhды. фонари вдоль длинной дороги, дорожные знаки, барьеры, кабели на столбах. Instant static рендерил бы всю пачку, даже то, что находится как бы далеко на десятки
Speaker A
километров. Масштабные архитектурные сцены, много однотипных объектов: колонны, балконы, плитки. Если они размещены по всему комплексу, кластеры дадут правильный лот и кулинг там на каком-то архитектурном состоянии, конечно, было бы лучше использовать иерархил ввиду того, что мы получим отбрасывание большой части того, что мы не видим. Insticмеши тоже применимы, но я уже
Speaker A
сказал ранее, когда именно. И точно также лучше использовать для VR, мобильных платформ, свечи и слабым железом. Если нужно разгрузить через data layer или стриминг-левелы, будет работать десятки быстрее. Вот я монтирую видео и замечаю, в который раз я говорю: "В десятки быстрее, в 100
Speaker A
быстрее". Нечто сложно раз произнести, в десятки раз быстрее. Что важно учесть для максимальной выгоды и rarical, и instant static meh? Добавление удаления происходит редко. Частая перестройка, bуддинг, волюм и иерархия. Тыся операций в тик съедает ЦПУ. Для динамического мусора
Speaker A
лучше использовать Инстатикмши или неагару. Важно учесть также разрозненность объектов, потому что на открытой большой территории с учётом видов, чтобы не было частой перестройки BOing Volume, лучше располагать и использовать instant static Mh и Archical Instant stat Static Mши вот с
Speaker A
учётом bunding volume, то есть мы добавляем дополнительные операции на перестройку static mesh, хотя могли бы сэкономить, используя просто интенсы разными пачками. В чём основные минусы и когда их лучше не использовать? Минусы: а дорогие массовые добавления удаления инстансов. При тысячах операций могут быть фрезы. Плавающие индексы: дерево сортирует инстансы после
Speaker A
их перестройки. Порядковые номера меняются. Логика завязана на индексах поломается. Это важно учитывать обязательно, если по индексам какая-то логика происходит, вроде назначение материалов или добавление каких-то эффектов наше и тому подобное. Аналогичные проблемы, как с инстатикмешами, связанные с запечкой. Нет уникальной лайтмапы. Лаймапа будет одна
Speaker A
на всех. А создаст визуальные артефакты, но сMas можно включить per instance, то есть на каждый instance будет уникальна лаймапа. Коллизии тени также общий, как у instн static Mший. Нельзя отключить только у одного экземпляра. Чуть больше расход памяти, чем у instant static Mши, порядка
Speaker A
20-50% в зависимости от настроек, так как 64 байта умножены на количество инстанса плюс баудинг, волю иерархия. перестройка вот этих вот кластеров в зоне видимости, что может стать критично на мобильных и VR проектах. Мы можем отключать для всей пачки коллизию, динамические статические
Speaker A
тени, делать мобильными или подвижными, включать coлдиist и тому подобное, но мы можем это делать только для всей пачки. Ой, вам бы пришлось вот тут вот крутить вот сюда куда-то прописывать, а у меня вот так вот можно просто в плагине кнопочку нажать и применится настройки ко всему. То есть отключим
Speaker A
тени, включим коллизию и проделаем подобные какие-то полезные для оптимизации манипуляции, когда точно не надо использовать и instant static. С мелкими кластерами будет больше дрокол. Видимый кластер- свой вызов. При сотнях тысячах кластеров счётчик может превысить то, что было бы с instant
Speaker A
stтикмеationми. А нет на чем показать, например, кусочки какой-нибудь, там тот кусочек травки, там кусочек травки, включите воображение. Тут и Ricalтивмеши были бы плохим решением, потому что большая о частая перестройка Bundдинing Volume. Также когда ещё не нужно использовать, когда почти все объекты собраны плотным ковром и могут быть полностью в кадре. Bудum ничего не
Speaker A
отсекает, это лишняя память и дроуколы. Instant static Mши в данном вот в данном случае были бы лучше, если у нас вот такая пачка попадает в кадр. Если разрозненность гораздо больше, разрозненность, понятно, да, что это, то есть вот это вот, например, кусок находится где-нибудь там,
Speaker A
то, конечно же, иерархил намного дешевле стал бы, когда у копий должны быть свои материалы и текстуры, лучше тогда оставлять просто статик мыши, либо использовать атласы, маски, которые регулируются через P instance Custom. Покажу лучше сразу, потому что есть какой-то без неважно какой
Speaker A
материал. И у материала есть, а ноды instance, а неважно, instance data. Можно их добавить много.
Speaker A
На каждый индекс будет первый, это будет второй. И подобным образом это примерно будет выглядеть instance custom data. Мы можем регулировать параметры каждой копии, но это не очень удобно, хотя можно немножечко автоматизировать этот процесс. А-а, это также позволит сменять,
Speaker A
например, UV-развёртку, сменять какой-то атлас, сменять индекс для UV-развёртки на атласе, но это усложняет работу, когда ещё не стоит использовать. Мелкие детали разбросаны по пачкам по паре экземпляров. Например, в каждой комнате на столе по две кружки. Тогда кластеры размером
Speaker A
один дроукол почти то же самое, что static ноч компонент и bundдинг volume, не даёт особо толку.
Speaker A
Поэтому в данном случае, если, например, многоквартирный дом, в каждом есть кружки, лучше использовать просто instance static Шh мы сделали и разбросали эти пачки по уровню. Но не ставить в каждой квартире, ну, по две кружки и потом всё это упаковывать. Да, это упакуется
Speaker A
всего лишь в один рал instatic mesh compent, но мы получим дополнительную нагрузку за счёт отсечения.
Speaker A
А течение нескольких кружек, оно не целесообразно, поэтому было бы лучше использовать просто static или иста static m, повторяюсь по 10 раз. Зачем, не знаю. Теперь быстрый чек-лист. Что когда лучше? Лес, трава, камни по всей карте. Что лучше? Hierarchical instance static Mh. 1тыся
Speaker A
одинаковых ящиков в одном складе. Instance static. Нужно спавнить 20.000 пуль в секунду. Ниагара или instance static p instance один герой, ну какая-то ландмарка редкий проsiclot или нанит слот с лод группой. Есть ли интерактивный уникальный проснятно static Mh? Для размышления пару вопросов, комментарии, пожалуйста, важно, потому что это видео м несёт
Speaker A
какую-то информационную нагрузку, а такие видео обычно не очень популярны. А мне не хотелось бы делать простые видео, а хотелось бы делать подобные видео. А для этого нужен ваш ваши вы ваши руки на клавиатуре просто рандомно бьющие какие-то буквы и отправляешь мне в комментарии.
Speaker A
Вот что нужно, чтобы я продолжал что-то делать. Для размышления ответьте на эти вопросы. Что лучше для модульного пятидесятиэтажного дома? Что лучше для интерактивных дверей во всём доме? Что лучше для офисного пространства со столами, бумажками на них, настольными лампами на каждом столе в
Speaker A
каком-то офисе? Что лучше для уникальной лестницы, где каждая ступенька отдельно и таких лестниц в доме сотни? Далее блок будет, который составлен на основании вопросов-ответов. А эти вопросы я нашёл на форумах. В принципе, вот этой информации как бы нету суммарной где-то собранной воедино. это
Speaker A
пришлось собирать по кусочкам. Данные вопросы нашёл на форумах, плюс какие-то от знакомых поступили. И, соответственно, у вас тоже могут возникнуть подобные вопросы, и я надеюсь ответить.
Speaker A
Если я на что-то не отвечу, то опять же побейте по клавиатуре для того, чтобы написать какой-то комментарий. Первый вопрос: почему нельзя просто использовать всегда hierarchical instance static mesh вместо instance static mesh или static, если они так хороши? Очень много здесь instance словов.
Speaker A
Почему в общем нельзя использовать хизм вместо изм и вместо см? Потому что overhead иерархии вом иерархия. Хизм строит иерархическую структуру bundдинing volum иерархии для фрустрации, оклюзий и лодов. Это требует дополнительной памяти и цпу особенно при добавлении удалений инстансов
Speaker A
во время игры, ну, во время запуска плеймода. Если все инстансы близко друг к другу и всё видно на экране, эта иерархия абсолютно бесполезна или даже вредна. медленнее при частом обновлении, если добавлять удалять инстансы в рантайме. И rical instance static mesh работает медленней,
Speaker A
потому что перестраивает BVH. Instant static Mh ism будет работать быстрее при динамическом спавне большого количества объектов. Также лот не всегда нужен. Хизм нужен, когда есть лоды и распространённые инстанции. Но если используется простой ш без лот и без оклюзии,
Speaker A
а смысла хизм нет. Потом вопрос: а если просто переместить static MH на сцену и дублировать его, будет ли это инстансом? А, нет. Хоть на панели Details написано instance, в данном случае это означает, что это просто копия этого, что это просто копия одного компонента. Ну,
Speaker A
в любом случае каждый static MШ - это static Mh- компонент, который даёт один draw call. Если он будет продублирован очень много раз, сотню, он даст как бы сотню дополнительных дроуколов. Но если его конвертировать взм или, то это станет, да, просто инстансо инстанцированным объектом.
Speaker A
Но также стоит отметить, что если это одинаковые пробсы, находящиеся близко друг к другу, и они статикши, то, да, может сработать dynнаic instancing, который объединит их, э, геометрию, проведёт по одному пути ЦПУ, GPU, но на это, как я говорил, не стоит надеяться ввиду ввиду того,
Speaker A
что это не всегда работает. Следующий вопрос. Почему просто нельзя сделать один большой мэш дома? Например, как делают пещеры с окружением и энроментом на 200-300.000 треугольников или вообще просто включить нанит на таком объекте. А это плохо по ряду причин. Кулинг и отражение. Движок
Speaker A
смотрит только на габаритный AABB. То, что я говорил про cluster 3. Если камера видит крошечный угол дома, в кадр всё равно попадает весь Мэш. Ну не в сам кадр, а в путь рендеринга. А Lumin Reflection и Distance Field Ambientusion. также считает его целиком, даже если он не попал весь
Speaker A
в кадр. Стриминг Lot World Partition загружает актёры, а не треугольники. Один актёр, гигант, будет подгружаться и выгружаться целиком, а это даёт микрофрезы вместо плавного стриминга. То есть, если у вас большая карта ворпоршена и используются такие объекты, то, да,
Speaker A
его намного тяжелее загрузить, нежели это были бы разделённые на маленькие объекты. Освещение. Light йap для такого ша требует огромного UV атласа 4,8К или даже больше, и даёт мыльные тени. Люмен создаёт крупный surfaceй casш, съедая память, а hit lightgh тяжелее. А если требуется пояснение,
Speaker A
то в случае, допустим, вот этот вот объект был бы очень-очень большим, с сложной геометрией, с входом, с окнами и тому подобное, то в случае запекания освещения нам бы потребовалась карта освещения на весь вот этот вот дом. Но это было бы просто оченьоченьочень тяжёлой картой. материалы и
Speaker A
дроукол. Стом - это десятки разных материалов. Каждый слот - это всё равно отдельный дроукол, даже при Нани. Поэтому счётчик вызовов растёт как у обычной сцены. Нанит помогает только с полигонами. Он снижает нагрузку на GPУ, но все проблемы ABB, материалов, навигации и стриминга
Speaker A
остаются, поэтому один большой Мэш - это плохой способ. Возможна ли анимация у инстансов? Да, но только трансформам или материалом с VP и или вертексами. скелет морфы и разрушение требуют Skeletal Mh geometry Collection. Следующий вопрос. В режиме GPU overdraw очень высокий,
Speaker A
хотя draw call низкий. Что не так? А режим GPU, а если кластер попадает в кадр краем, instant static Mh может рисовать целиком большой ABB и ABB. Итог: большие прозрачные прямоугольники поверх сцены.
Speaker A
VR FPS падает в два раза, хотя сцена мониторе держит 90. Instant static Mhт draw calls, а для Pass тот же Draw Call дублируется на каждый глаз. ЦУ экономия остаётся на ЦПУ экономия остаётся, но GPU overdraw удваивается. Нужно точнее настраивать лоды и кластеры с расположением и разрозненностью
Speaker A
объектов и также использовать меньше статик мышей. Следующий вопрос. Хотел обновлять material параметр через set scar paramet value on materials удивился. Изменилась только первая копия. Почему? Это то, что я показывал. Функция работает на компонент на уровне компонента, а материал один. То, что кажется первой копией, на самом деле instance 0. Material instance dynamic.
Speaker A
Параметр меняется на весь компонент. И кажется, что изменилась первая копия, потому что у всех одинаковый цвет. Это мой пример с здесь. Для того, чтобы было на каждом, нужно использовать per instance. Включил distance field ambient occusion, и память карты DF выросла вдвое.
Speaker A
Инстан же делят геометрию должно быть дешевле. Да, Distance field Ambient Declusion каждый уникальный transform увеличивает глобальный воксельный атлас. Для distance field Ambientusion каждый уникальный трансформ увеличивает глобальный воксельный атлас. Память растёт из-за объёма атласа. При 1.000х инстансов - это гигабайты. Если нужно меньше памяти, следует уменьшить ambient oclusion global
Speaker A
distance field atlas resolution через консольную команду или же отключить defoo для плотной листвы, например. В отражениях объекты с RAR и static Mhish становятся частично чёрными или в целом неправильно отражаются при использовании Lumen. А да, в Lumin Reflection движок решает, какие
Speaker A
части сцены нужно трассировать по AABB узлам. Для Arcttical Instant static Mh каждый кластер Uzal BVH имеет свой AABB. Если кластер признан невидимым для текущего кадра, он не записывается в sufix cage volume. Лучше отражения, пройдя через это место, видит пустоту, поэтому часть инстанца
Speaker A
выводится тёмной. Для того, чтобы этого не было, чтобы исправить, это действительно проблема есть. Да, Instant Static Mage делит экземпляр на кластеры и у него один AABB на весь компонент, поэтому таких ну как бы дырок, тёмных мест не появляется. Также решение включить нанит
Speaker A
на Мэше или увеличить размер кластеров. После включения нанит геометрия автоматом дробится на множество мелких нанит-кластеров 128 5123 с каждой. А примерно каждый такой кластер регистрируется в Surface Casш отдельно. Лучи отражения всегда находят нужные треугольники и чёрные вот эти вот штучки не появляются. И также пару моментов ещё дополнительно. Сейчас
Speaker A
скажу про работу с instнста statтикмешами. А то я всё говорю про разницу, но не сказал толком про их работу. У вас была постоянно статичная какая-то неинтересная картинка. Забыл сказать. Решил доснять для полноты представления картины, как ещё можно работать с инстанцами. Другая карта. И,
Speaker A
к примеру, вот есть дом. Очень хорошо, что в этом примере весь дом составлен из отдельных кусочков из Static. Не очень производительная сцена, как бы можно было её оптимизировать. Ну и в целом, как было бы правильно сделать. Это незаконченный асет. Есть некий дом. Выделяем все части.
Speaker A
Да, дом, состоящий из миллионов кусочков. Оказалось, не сильно легко его выделить. Ладно, представим, что я полностью выделил. И тут должны остаться только статик мыши. Потому что инстанцировать в данном случае совместно можно будет только статикмши. И далее actor. И
Speaker A
два варианта есть create level instance или create packet level. Если я сделаю create packet level, можно выбрать где будет гивод располагаться. В данном случае в центре всех этих мышей. О'кей. И нужно выбрать место, где он будет сохранён. Более правильно назвать какой-то левел. Теперь появился
Speaker A
BPP actor. BPP - это второй файл, который создаётся. Его подписывать не нужно, потому что приписка BPP сама появляется. Он сразу создал инстансы с количеством уникальных компонентов. В нём стены объединил, очень много всего. И подобным образом более правильно делать. Теперь этот файл
Speaker A
можно размещать на уровне, и он не будет требовать больше ресурсов, чем его исходный вариант, потому что это всё инстанцированы объекты одного и того же Мэша. Ну, группы, пачки мышей. Другой похожий вариант, как это можно сделать, просто выделив мыши, правый клик level create level.
Speaker A
Ещё один вариант создавать, а, instance static mesh hierarchical instance static mesh- это создав обычный blueprint actor, который можно добавить и instant static mesh и instant static mesh в качестве и instant static mesh указать то, что вам требуется или иal instant static указать,
Speaker A
что требуется. Такой вариант тоже приемлем, но, кажется, не очень удобен. Разве что для какого-то функционала с логикой, которая происходит по спавн класс должен быть разве что instant static mesh или instant static mash. Как-то так. Так что есть три пути для того, чтобы создавать instant
Speaker A
staticм меши или даже больше, так как можно ещё это делать через C++. И, вероятно, ещё какие-то способы есть для того, чтобы это можно было бы делать. И в целом, как создаются инстансы? У меня есть плагин. Сейчас не реклама, хотя может быть и реклама. Тут как посмотреть. У меня есть плагин,
Speaker A
который создаёт Иastic Mши работает с версией 5,3, но сначала скажу про то, что появилось в 5,6.
Speaker A
В режиме моделинга появился инструмент hardways instance, который позволяет создавать instance static mesh или nonarchical instant static mesh. Для этого просто нужно выделить требуемые мыши и нажать accept. Они превратятся. Будет название у актора такое, а при этом можно удалить исходные
Speaker A
варианты. Также, если здесь будет, например, ещё сфера, то нужно поставить галочку single actor. Тогда в этом рал static Mши в одном компоненте будут вот эти вот кубы плюс ещё один только, а, ну, сфера. В итоге в одном компоненте будет два разных экземпляра. Но есть минус в том, что здесь
Speaker A
больше делать-то ничего особо и нельзя. И для этого нужно использовать плагины. Их, в принципе, есть, наверное, несколько. У меня есть свой, который скоро будет в маркете. Не знаю, платный или бесплатный или вообще не будет в маркете. Буду просто так распространять. А в целом он мне нужен
Speaker A
для работы с инстанцами. Тогда когда вот этого инструментария ещё не было. Я могу создать икмеши инстансы, задать им имя, сразу уместить в какую-то папку, э, которая boxes, где они будут. Также могу произвести какую-то оптимизацию сразу над всеми компонентами. Установить мобильность, динамик,
Speaker A
static. э, damic shadow static включить коллизи отключить влияние намш и тому подобное. И также могу если я передумал, конвертировать их обратно в статикши, что является очень удобным. А ещё, если мы не задаём имя, то а он берёт имя, соответствующее последне выделенному объекту,
Speaker A
и создаёт из него instance. Ну и, соответственно, прописывает, что это instant static mesh или instant static Mh. Мой инструментарий удобней, но вы всё равно ничего не купите, а я, возможно, ничего не продам. Поэтому в любом случае просто напишите комментарий, насколько полезно,
Speaker A
стоит ли продолжать. И это душно много. Ой, сколько каши навалил в конце. Короче, напишите что-нибудь, важно, правда, лайкните там, куда-нибудь скиньте. Вообще идеале куда-нибудь скинуть. Вы уже, наверное, 90% скипнуло на этом моменте. Ещё раз всем подписка.
Topics:Unreal Enginestatic meshinstant static meshhierarchical instant static meshоптимизация сценыдроуколыинстанцированиеLODCPU GPUрендеринг











