Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 7
Как говорится, критикуешь - предлагай. Мне кажется вы тут путаете тёплое с мягким. Основная причина и пользования дерева не в том, что это хорошо ложится на рендер пайплайн а в том, что это банально удобно для менеджмента сцены. Те же самые префабы, сокеты и т.п. Это просто универсальный метод представления сложных структур, который имеет “логарифмическую сложность восприятия” человеком. Не было бы в этой схеме левел дизайнеров, художников, и прочих людей, которым сложно работать со списками на несколько сотен одинаковых объектов, не было бы проблем. Ну и стек трансформаций ни кто не отменял, с кешированием матриц, и транзитивными трансформациями.
Проблема, как вы сами пишете решается разными уровнями абстракции, и слава богу. Это как http и кадры ethernet. Когда вам нужно сходить по API за мегабайтным JSON’ом, вы точно не захотите думать о пакетах, маршрутизации, чексуммах, диф-парах, модуляции и прочих деталях нижних уровней OSI. Так и в движках, Сцена - протокол прикладного уровня, RHI - транспортного, а D3D - сетевого, образно выражаясь. И нет в этом ни чего плохого. Оно просто напросто эргономично.
На курсе компьютерной графики ИТМО эту модель давали уже на втором месяце и объясняли её полгода, а остальные пять или шесть техник давали всего месяц и в конце года.
Стало интересно, сходу не смог столько вспомнить/придумать. Можете, пожалуйста, перечислить эти шесть других техник?
Как мне кажется, причина появления и популяризации Scene Graph в трехмерных играх иная. Это просто логичное развитие уже существующего подхода с организацией игрового мира как дерева, без которого любая игра того периода на железе того же периода будет просто слайдшоу. Кроме того, это удобно для организации ресурсов и процесса наполнения игры контентом геймдизайнерами.
В далёком 2003 это емнип были предвестники ECS, на объект вешались флаги по которым из разных контейнеров они разбирались по разным системам. Второй это flat-driven сцена, где все объекты лежат в одном или нескольких массивах, считайте это инвертнутыми флагами. Spatial Structuring - это тоже фактически обычный массив, но объекты выбираются кластерами (квадро дерево, октодерево) внутри уже отдельные сортировки. Было еще пару лекций по render graph, не путать со scene graph, когда мы описываем не связь родитель-ребенок, а зависимость машина-колеса. Tile-based - рендер разбивается на мелкие задачи, каждая из которых заполняет кадр независимыми данными (подход в Doom3) и некоторые игры Sony.
Может еще чтото есть, но я забыл
Ну камон. Рендеринг отдельно, сцена отдельно. Для отрисовки объекты сортируются по-своему, для взаимодействия друг с другом -- по-своему. Зачем Scene Graph пытаться приделать туда, где ему не место?
всё что нужно делать это обходить это дерево сверху вниз, рисуя или обрабатывая каждый узел по очереди.
Никто и никогда так не делает, и не делал на моей памяти, граф сцены является абстракцией, которая отправляется в разные системы, рендер, в физический движок, в игровую логику. Каждая из этих систем обычно всегда имеет под собой свою копию сценны с теми или иными оптимизациями, рендер строит октодерево или bvh физ движки свои деревья с кластерами, логика свою очередь выполнения. Напрямую использовать дерево созданное для геймдизов глупо и нееэффективно
Первая проблема называется батчинг, и суть её в том, что GPU работает эффективно когда получает однородные команды подряд.
Нет такой проблемы, потому что повторяю рендер сначала собирает в свои структуры что он может отрендерить, потом соберёт что ему надо отрендерить, а потом разбивает на батчинг, лоды и прочее, и только после всего этого он начинает рендерить.
Второе это кеширование, которое важно для статических объектов мира, потому что если стена никуда не движется и её материал не меняется, то нет смысла пересчитывать команды для неё каждый кадр, и движки вроде Unreal Engine создают отдельные буферы команд для статических объектов один раз при загрузке уровня, а потом просто копируют их в финальный список, чтобы разгрузить CPU от выполнения ненужной работы.
Не делает Unreal так, сам объект не движется, но вот камера движется и из-за того что необходимо делать кулинк (Фруструм, оклюжен) объекты которые должны отрисовыватся каждый раз меняются. статик месш в анриле это не меш который один раз записался в командную очередь и каждый раз отрисовывается, это мешь которой после загрузки не меняется.
Первое и самое очевидное что дает список команд - это сортировка.
Никогда списки команд не использовались для сортировки, и после заполнения списка команд его нельзя менять, только добавлять новые команды, откуда вы вообще взяли что команды можно сортировать? Сами списки ещё да, но смысла в этом особо нет, но вот команды в списках нет. Или вы придумываете какую-то свою терминологию.
а потом объединять в один финальный список перед отправкой на GPU.
Нет такого, списки объединять нельзя. Опять же если вы говорите про ID3D12GraphicsCommandList
Кружка на столе не является дочерним объектом стола, соседом других кружек, частью дома или родителем кофе внутри неё, она просто стоит на столе и ничего не вложено ни во что другое.
Да но если двигать стол, кружка также двигается вместе со столом а не остаётся на месте. И одна из возможностей графа сцены выразить эту зависимость.
но я так до сих пор так и не нашёл причин, которые делали бы его хорошим выбором для чего-то кроме скелета и анимаций
Значит вам не попадали сложные задачи, Scene Graph облегчает разборку в самом проекте, в котором могут быть миллионы объектов, группировка по смыслу, ограничении области применимости, рекурсивные применения, префабы, подуровни и много много другого. Если вам это не приходило в голову значит у вас не было сложных задач
Scene Graph при этом никуда не исчезает, он продолжает управлять трансформом, анимациями и логикой сцены, но он больше не управляет рендерингом напрямую
Он никогда и не управлял, не понимаю откуда вы это взяли
Очень странная статья, в начале много критики не по существу, потом опровержение собственной критики, а потом возврат к критике в выводе, хотя становится очевидно что она не состоятельна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scene not Graph