Как хранятся объекты в Unity на сцене? Как проиходит отсечение видимых объектов?
Интересует пару технических вопросов, Вообще не конкретно Unity, достаточно вообще любого движка
1. Какая структура данных используется для размещения объектов на сцене по дефолту? Bsp Kd R Octo деревья Или еще что? Где она находится, на Cpu или Gpu, или и там и там одновременно, тогда след вопрос
2. Есть ли разделение на динамические и статические объекты, для разные наверное структуры используются, какие к примеру.
3. Где происходят вычисления получения списка видимых объектов, culling. На cpu или gpu?
4. Где происходят вычисления при изменении положений объектов? Допустим куб повернули, он пересек другой узел, и таких запросов много, для каждого вычисляется удаление добавления вставка разделение узла? Или полностью допустим все дерево по новой перестраивают, хотя обычно на сценах мало динамических объектов
5. На каждой отрисовки кадра происходит новое вычисление? допустим камеру на 1 градус повернули, то происходит новый обход? или как-то можно использовать отсечь тот 1 градус, или допустим, такой вариант, можно вернуть тот же список + объекты с того сектора в 1 градус. 1 градус сектора те что как бы не видны, пускай, попадут на рендеринг, там уже просто не будут отрисовываться, а каждый n фрейм полностью обновление. или там при отрисовки если не попадает, но попал, выставить бит запроса на удаление и после удалить их структурой данных массива с удалением в конец, из конца объект в место удаления перенести, так как порядок списка не важен.
1. Руты дерева хранятся на сцене, каждый обьект имеет цепочку вложенных обьектов. Обход осуществляется с рута по веткам рекурсивно.
Считает Цпу.
Флюструм куллинг считается на цпу по баунд боксу обьекта. Берется из Трансформа. Самый простой ААВВ тест.
2. Есть разделение на статик батчинг и динамик батчинг. Статик работает только для сцен. Он комбинируем меша обьектов в один по Материал Проперти Блоку. Динамик батчинг работает в рантайме по тому же принципу, но есть ряд ограничений, не более чем 64к вершин на один бачь, и не более 300 атрибутов вершин на один обьект. В Рендер пайплане есть свой динамик батчинг, он работает по принципу оптимизации перегрузки стейта ГПУ с одинаковыми шейдерами, но разными Статик Блоками, жрет батарейку мобилльника, по этому актуален для стендалоне игр. Накладывает ряд ограничений на конфигурацию шейдера.
3. Флюструм каллинг на СПУ. См п.1.
4.дерево не перестраивается. Каждый кадр происходит обход баунд-боксов на попадание в флюструм. Если изменить положение обьекта в иерархии происходит тол ко пересчет его очереди рендера.
5. Каждый кадр вне зависимости от того поменялось ли что на сцене. Нет никакого массива. Рекурсивный перебор для построения Дравколов.
a3dline, спасибо за ответ.
Еще пару вопросов, а как хранятся на gpu данные сцены, к примеру есть такое что все вершины сцены хранятся(или попадают) в одном буфере. Что бы был один буфер индексов возможно полностью скрытый от фронтенда, Или у каждого gameobject свой буфер вершин, буфер индексов в разных местах памяти, а объекты тогда через двойной указатель должны находится в ядрах gpu.
Еще на счет RayTracing, Это полностью другой конввер рендеринга? Типа там нету ни какого отсечения, растеризации, рисования, типа просто идут лучи, по числу пикселей экрана, и проверяются пересечения с объектами в BVH дереве. И типа так просто, или мне только кажется.
SergeySerge11,
У гейм- обьекта как такового нет вершин. Гей обьект, это обьект который описывает структуру с компонентами и может быть добавлен на сцену в ее дерево обьектов.
Вотвремя загрузки гейм-обьекта или сцены в память, все зависимые ресурсы, такие как текстуры, меша, шейдера и так далее загружаются на ГПУ через Async Uploader - отдельный модуль юнити позволяющий разворачивать обьекты в видеопамяти. На мобильных устройствах - в обычной памяти, но отданной под нужды ГПУ.
Далее, во время рендеринга, ЦПУ готовить Драв-Кол - это структура данных которая устнавливает ГПУ на работу в определенное состояние: какой буфер вершин, атрибутов. Какой шейдер. Параметры шейдера, текстуры.
Так же если у нас есть кастомный код, который, например, генерирует мешь или это динамический дравкол, то изменения заливаются в память ГПУ перед следующим кадром рендера.
Сам рендеренг всегда отстает на один кадр от работы ЦПУ. Пока мы изменем сцену, формируем дравколы доя кадра, устанавливаем веса анимации, ГПУ попорядку обрабатывает дравколы с предыдущего кадра.
a3dline, а не подскажите еще, все не могу понять, как происходит конкретная отрисовка примитивов треугольников, есть 2 варианта,
Как в учебниках по линиям слева на право.
По фрагментам, для каждого пикселя все фрагменты проверяются через уравнение принадлежности точки треугольнику
Еще непонятно что приходит на вход фрагментного шейдера(если 1 способ верен, он вообще там есть).
Допустим есть сцена, после этапа кулинга поступает далее(куда то же не понятно?) миллион(миллиард что бы на гипер параметре лучше понять) треугольников.
Тогда в среднем на 1 пиксель будет конкурировать где-то допустим 10 тысяч треугольников.
Есть ли тут какие-то дальнейшие действия. В зависимости от 1 вопроса.
Например я обнаружил, что если сортировать треугольники то они отрисовываются намного быстрее по 1. методу.
А по второму методу, к примеру нужна какая-то дополнительная группировка, допустим разбиение плоскости на клетки по 32*32 пикселя. И проверкой только тех которые принадлежат тайлу.
Есть ли вообще такое
