всё что нужно делать это обходить это дерево сверху вниз, рисуя или обрабатывая каждый узел по очереди.
Никто и никогда так не делает, и не делал на моей памяти, граф сцены является абстракцией, которая отправляется в разные системы, рендер, в физический движок, в игровую логику. Каждая из этих систем обычно всегда имеет под собой свою копию сценны с теми или иными оптимизациями, рендер строит октодерево или bvh физ движки свои деревья с кластерами, логика свою очередь выполнения. Напрямую использовать дерево созданное для геймдизов глупо и нееэффективно
Первая проблема называется батчинг, и суть её в том, что GPU работает эффективно когда получает однородные команды подряд.
Нет такой проблемы, потому что повторяю рендер сначала собирает в свои структуры что он может отрендерить, потом соберёт что ему надо отрендерить, а потом разбивает на батчинг, лоды и прочее, и только после всего этого он начинает рендерить.
Второе это кеширование, которое важно для статических объектов мира, потому что если стена никуда не движется и её материал не меняется, то нет смысла пересчитывать команды для неё каждый кадр, и движки вроде Unreal Engine создают отдельные буферы команд для статических объектов один раз при загрузке уровня, а потом просто копируют их в финальный список, чтобы разгрузить CPU от выполнения ненужной работы.
Не делает Unreal так, сам объект не движется, но вот камера движется и из-за того что необходимо делать кулинк (Фруструм, оклюжен) объекты которые должны отрисовыватся каждый раз меняются. статик месш в анриле это не меш который один раз записался в командную очередь и каждый раз отрисовывается, это мешь которой после загрузки не меняется.
Первое и самое очевидное что дает список команд - это сортировка.
Никогда списки команд не использовались для сортировки, и после заполнения списка команд его нельзя менять, только добавлять новые команды, откуда вы вообще взяли что команды можно сортировать? Сами списки ещё да, но смысла в этом особо нет, но вот команды в списках нет. Или вы придумываете какую-то свою терминологию.
а потом объединять в один финальный список перед отправкой на GPU.
Нет такого, списки объединять нельзя. Опять же если вы говорите про ID3D12GraphicsCommandList
Кружка на столе не является дочерним объектом стола, соседом других кружек, частью дома или родителем кофе внутри неё, она просто стоит на столе и ничего не вложено ни во что другое.
Да но если двигать стол, кружка также двигается вместе со столом а не остаётся на месте. И одна из возможностей графа сцены выразить эту зависимость.
но я так до сих пор так и не нашёл причин, которые делали бы его хорошим выбором для чего-то кроме скелета и анимаций
Значит вам не попадали сложные задачи, Scene Graph облегчает разборку в самом проекте, в котором могут быть миллионы объектов, группировка по смыслу, ограничении области применимости, рекурсивные применения, префабы, подуровни и много много другого. Если вам это не приходило в голову значит у вас не было сложных задач
Scene Graph при этом никуда не исчезает, он продолжает управлять трансформом, анимациями и логикой сцены, но он больше не управляет рендерингом напрямую
Он никогда и не управлял, не понимаю откуда вы это взяли
Очень странная статья, в начале много критики не по существу, потом опровержение собственной критики, а потом возврат к критике в выводе, хотя становится очевидно что она не состоятельна.
А ещё шейдеры (это прям целый мир), организовать саму отрисовку (инстансы, батчинг, прозрачность, тени, отложенное освещение, куча оптимизаций и ещё миллион других нюансов), управление памятью, дескрипторы, многопоточность (командные листы, очереди, фэнсы). Короче статья вообще никаких образом не даёт понять 3D графику, лишь немного по то как работает перспектива.
Все эти принципы и идеи нужно просто использовать так же как код от нейросети или с SO, не бездумно применять а простаивать под свои требования и виденье. Тоже относится ко всяким скрамам и прочим методологиям.
Извините но у меня созрел вопрос, вы случаем не наркоман ли?
Если вы применяете синглтон, то обычно это многопоточный код
wat?! Как у вас в мозгу вообще образовалась такая ассоциация?
Я могу предположить, что внутри себя синглтон использует thread_local
wat?! wat?! Ещё одно чудное предположение, которое мало того что взялось из воздуха так ещё и во многом противоречит идеи синглтона (синглтон - одиночка, значит 1, один, one экземпляр, а thread_local создаёт по экземпляру на каждый поток).
А по поводу вашего гениального решения избавится от оператора присваивания и оставить только конструктор копирования, подскажите как тогда реализовать хотя бы указатели с подсчётом? Не говоря уже о чём-то более сложном.
Извините но ваша экспертность в знании С++ совершенно не бьётся с тем что вы пишите.
Да да, классические отмазки кривокодеров, времени нет, бизнес бла бла бла. Метод на тысячу строк это говнокод и нет этому оправдания, методы на 9 аргументов также плохо пахнут.
В смысле зачем? Если делать по нормальному а не фигачить по 100500 методов то всё будет в порядке, а так говнокодить можно в любой парадигме и не любом языке
Это замечательно когда проект небольшой, например микро сервис какой-нибудь, а когда проект становится здоровым, добавляется вариация с плагинами у кучей всего остального. Критичными становятся грамотно построенные интерфейсы, и ооп тут помогает несколько больше нежели функциональное программирование.
Ну и в конце концов, зачем обязательно упираться во что-то одно, можно ведь смешивать подходы, там где это выгодно. Бери плюсы из обоих миров.
Лучше иметь несколько структур данных и несколько сотен постоянных функций над ними. Постоянных - т.е. они не будут меняться из класса в класс, из объекта в объект. Нужно только разобраться один раз.
И получаем 100500 функций * на 100500 объектов, и весёленький интелесенс. Может всё таки проблема не в ооп а в ручках?
Зевсология - это например принцип суперпозиции. Она не фальсифицируема, потому что проверить суперпозицию нельзя, ведь она разрушается тут же, как происходит проверка. Но вот в этом и кроется ее "зевсологичность". Она сразу создала такие условия, по которым она сама же не проверяема. То-есть логика говорит что в теории нет смысла.
Ну начнём с того что принцип суперпозиции это не научная теория а научный принцип. А научные принципы опираются либо на вычисления либо на результаты экспериментов, в данном случае принцип суперпозиции опирается на двухщелевой эксперимент. То есть в данном случае вы также путаете причину и следствие. Суперпозиция является наблюдаемым фактом (результат двухщелевого эксперимента) а теории которые опираются на этот принцип уже пытаются объяснить механизмы работы или использования данного принципа. Так что тут вы мимо.
Будучи тесно связанной с такими понятиями механики, как «энергия» и «импульс», масса проявляется в природе двумя качественно разными способами, что даёт основания для подразделения её на две разновидности:
инертная масса характеризует инертность тел и фигурирует в выражении второго закона Ньютона: если заданная сила в инерциальной системе отсчёта одинаково ускоряет различные тела, им приписывают одинаковую инертную массу;
гравитационная масса (пассивная и активная) показывает, с какой силой тело взаимодействует с внешними полями тяготения[3] и какое гравитационное поле создаёт само это тело[4], она входит в закон всемирного тяготения и положена в основу измерения массы взвешиванием.
С чего вы решили что наша вселенная это вызвавшие? Теория мультивселенной подразумевает что может существовать бесконечное число вселенных где существование жизни более вероятно. Наша вселенная вполне может быть из разряда неудачных.
Лол, это всего что сказать что рыбка живущая в аквариуме должна расширится если расширить стенки аквариума. Атомы держатся вместе не за счёт пространства, а за счёт разных сил, и если пространство расширится это не значит что атомы должны разлететься в следствии расширения пространства, другие силы компенсируют это расширение.
Я лично для себя вывел очень простой критерий. Если теория может быть опровергнута в логическом поле - она зевсология.
Я правильно понимаю, вы только что взяли один из критериев Поппера (критерии научности теории) и сказали что если теория подходит под этот критерии то она не научная, забавно. Ведь именно возможность того что можно поставить такой эксперимент который мог бы опровергнуть теорию и разделяет научные теории от зевсологии.
Никто и никогда так не делает, и не делал на моей памяти, граф сцены является абстракцией, которая отправляется в разные системы, рендер, в физический движок, в игровую логику. Каждая из этих систем обычно всегда имеет под собой свою копию сценны с теми или иными оптимизациями, рендер строит октодерево или bvh физ движки свои деревья с кластерами, логика свою очередь выполнения. Напрямую использовать дерево созданное для геймдизов глупо и нееэффективно
Нет такой проблемы, потому что повторяю рендер сначала собирает в свои структуры что он может отрендерить, потом соберёт что ему надо отрендерить, а потом разбивает на батчинг, лоды и прочее, и только после всего этого он начинает рендерить.
Не делает Unreal так, сам объект не движется, но вот камера движется и из-за того что необходимо делать кулинк (Фруструм, оклюжен) объекты которые должны отрисовыватся каждый раз меняются. статик месш в анриле это не меш который один раз записался в командную очередь и каждый раз отрисовывается, это мешь которой после загрузки не меняется.
Никогда списки команд не использовались для сортировки, и после заполнения списка команд его нельзя менять, только добавлять новые команды, откуда вы вообще взяли что команды можно сортировать? Сами списки ещё да, но смысла в этом особо нет, но вот команды в списках нет. Или вы придумываете какую-то свою терминологию.
Нет такого, списки объединять нельзя. Опять же если вы говорите про ID3D12GraphicsCommandList
Да но если двигать стол, кружка также двигается вместе со столом а не остаётся на месте. И одна из возможностей графа сцены выразить эту зависимость.
Значит вам не попадали сложные задачи, Scene Graph облегчает разборку в самом проекте, в котором могут быть миллионы объектов, группировка по смыслу, ограничении области применимости, рекурсивные применения, префабы, подуровни и много много другого. Если вам это не приходило в голову значит у вас не было сложных задач
Он никогда и не управлял, не понимаю откуда вы это взяли
Очень странная статья, в начале много критики не по существу, потом опровержение собственной критики, а потом возврат к критике в выводе, хотя становится очевидно что она не состоятельна.
Ну не правда, есть cppfront ну или как его ещё называют cpp2 от Саттера. Компилируется в С++ и его можно смешивать с существующим С++.
Проще же взять либу DirectXTex и вызвать LoadFromWICFile, не совсем понятно для чего мучать низкий уровень?
А ещё шейдеры (это прям целый мир), организовать саму отрисовку (инстансы, батчинг, прозрачность, тени, отложенное освещение, куча оптимизаций и ещё миллион других нюансов), управление памятью, дескрипторы, многопоточность (командные листы, очереди, фэнсы). Короче статья вообще никаких образом не даёт понять 3D графику, лишь немного по то как работает перспектива.
Все эти принципы и идеи нужно просто использовать так же как код от нейросети или с SO, не бездумно применять а простаивать под свои требования и виденье. Тоже относится ко всяким скрамам и прочим методологиям.
Может тогда проблема не в человечестве а в священных книгах?
Извините но у меня созрел вопрос, вы случаем не наркоман ли?
wat?! Как у вас в мозгу вообще образовалась такая ассоциация?
wat?! wat?! Ещё одно чудное предположение, которое мало того что взялось из воздуха так ещё и во многом противоречит идеи синглтона (синглтон - одиночка, значит 1, один, one экземпляр, а thread_local создаёт по экземпляру на каждый поток).
А по поводу вашего гениального решения избавится от оператора присваивания и оставить только конструктор копирования, подскажите как тогда реализовать хотя бы указатели с подсчётом? Не говоря уже о чём-то более сложном.
Извините но ваша экспертность в знании С++ совершенно не бьётся с тем что вы пишите.
Да да, классические отмазки кривокодеров, времени нет, бизнес бла бла бла. Метод на тысячу строк это говнокод и нет этому оправдания, методы на 9 аргументов также плохо пахнут.
Там можно подкинуть свой алокатор, пишите алокатор на стеке (это не сложно) и будет у вас корутина на стеке
Но cpp2 или по другому cppfront и правда хорош, он как TS для JS и его можно встроить в существующий код
С любой)
В смысле зачем? Если делать по нормальному а не фигачить по 100500 методов то всё будет в порядке, а так говнокодить можно в любой парадигме и не любом языке
Это замечательно когда проект небольшой, например микро сервис какой-нибудь, а когда проект становится здоровым, добавляется вариация с плагинами у кучей всего остального. Критичными становятся грамотно построенные интерфейсы, и ооп тут помогает несколько больше нежели функциональное программирование.
Ну и в конце концов, зачем обязательно упираться во что-то одно, можно ведь смешивать подходы, там где это выгодно. Бери плюсы из обоих миров.
И получаем 100500 функций * на 100500 объектов, и весёленький интелесенс. Может всё таки проблема не в ооп а в ручках?
Ну начнём с того что принцип суперпозиции это не научная теория а научный принцип. А научные принципы опираются либо на вычисления либо на результаты экспериментов, в данном случае принцип суперпозиции опирается на двухщелевой эксперимент. То есть в данном случае вы также путаете причину и следствие. Суперпозиция является наблюдаемым фактом (результат двухщелевого эксперимента) а теории которые опираются на этот принцип уже пытаются объяснить механизмы работы или использования данного принципа. Так что тут вы мимо.
Quest 3 лучше чем индекс и дешевле
Даже Вики с вами не согласна
Вы упускайте один не мало важный факт, у частиц нет массы покоя
С чего вы решили что наша вселенная это вызвавшие? Теория мультивселенной подразумевает что может существовать бесконечное число вселенных где существование жизни более вероятно. Наша вселенная вполне может быть из разряда неудачных.
Лол, это всего что сказать что рыбка живущая в аквариуме должна расширится если расширить стенки аквариума. Атомы держатся вместе не за счёт пространства, а за счёт разных сил, и если пространство расширится это не значит что атомы должны разлететься в следствии расширения пространства, другие силы компенсируют это расширение.
Я правильно понимаю, вы только что взяли один из критериев Поппера (критерии научности теории) и сказали что если теория подходит под этот критерии то она не научная, забавно. Ведь именно возможность того что можно поставить такой эксперимент который мог бы опровергнуть теорию и разделяет научные теории от зевсологии.