Инстансинг и куллинг на CPU (4 стр)

HolyDel
> то это суммарно 48 миллионов полигонов, которые пойдут по конвееру
Так по современным меркам это должно быть тьху! На какой-нибудь GTX780 можно было рисовать до 7-8 миллионов полигонов в кадре с приемлимым фпс. Нешто RTX4090 не потянет 100-200 миллионов полигонов в кадре? А как же, я извиняюсь, наниты-люмены? Там блоггеры на ютубе демонстрировали все преимущества этой технологии и с их слов выходило, что в кадре порядка 10 миллиардов полигонов. Пусть даже эти полигоны меньше пикселя и вообще их некорректно сравнивать с реальными, но как-то же современные видеокарты это тянут?

563
> Для того что бы позади камеры ёлок не оказалось, по заветам Кармака нужно
> использовать Quad Tree Culling.
Так яж не против использовать. Я как раз и пытаюсь понять - может не надо ничего куллить, и так будет неплохо.

MikeNew
> Не, никто же не станет рисовать 16к трехмерных елок
Вот любительский мод под сталкер: https://ap-pro.ru/stuff/zov_pripjati/alone-in-windstorm-r345/
Я ёлки конечно не считал, но по ощущениям их там тысяч 20 точно наберётся.

MrShoor
> Но инстансить надо после куллинга. Это из личного опыта.
Спасибо, именно это я и хотел услышать - про личный опыт.

MrShoor
> в чем проблема иметь личную матрицу?
Я имел в виду - зачем, если можно без этого обойтись.

MikeNew
> Я имел в виду - зачем, если можно без этого обойтись
А чем предлагаешь обходиться? Кватернион + позиция?

MrShoor
> А чем предлагаешь обходиться? Кватернион + позиция?
Я не то имел в виду.. а то что не надо передавать матрицы для того что не будет нарисовано. Как 16к трехмерных елок. На том скрине из Microsoft Flight Simulator (это оттуда же?)  я подозреваю что это все-таки биллборды (но сам не играл, потому утверждать не буду).

g-cont
> Нешто RTX4090 не потянет 100-200 миллионов полигонов в кадре? А как же, я
> извиняюсь, наниты-люмены?

Наниты, конечно же кулят данные

Вообще это не классический полигональный рендеринг. Он не использует ни вершинные шейдеры, ни мешлет шейдеры. Это полностью софтверная растеризация, которая реализуется на вычислительных шейдерах, поэтому плохое сравнение.

На самом деле это очевидно, так как GPU очень медленно шейдит полигоны размером с пиксель (https://www.programmersought.com/article/11749022021/).

Пайплайн в нанитах для приблизительного понимания не очень сложный:

1. Хитрым образом формируется и стримится кластер данных (с учетом расстояния от точки просмотра; это по сути этап куллинга) в вычислительный шейдер, таким образом, чтобы каждый "полигон" в итоге был примерно размером с итоговый 1 пиксель на экране (собственно поэтому в сцене может быть хоть триллион, 10-триллионов мелких полигонов; "на экране" каждый фрейм будет обрабатываться примерно одинаковое количество полигонов, утрированно -- width * height, ну т.е. не так много, как изначально казалось, ни триллион, а где-то 2-4 миллиона всего и не более). Собственно это и есть вишенка нанита.

2. затем вычислительный шейдер пишет глубину в пиксели depth buffer-а (и stensil), чтобы его потом можно было использовать на этапах классического (полигонального) рендеринга, например когда нужно будет полигонального персонажа отрисовать поверх нанитной сцены

3. там же формируется, что-то похожее на visibility buffer (http://filmicworlds.com/blog/visibility-buffer-rendering-with-material-graphs/).

4. а на этапе шейдинга (наложения анрил материалов) уже используется софтверно сформированный visibility buffer, который хранит информацию по трианглам и инстансам.

Техника visibility buffer похожа по сути своей на deffered rendering с gbuffer, с той только разницей, что мы вместо того, чтобы писать текстуры с данными материалов (альбедо, метал, нормали и прочего), мы пишем только данные о треугольниках и инстансах. И уже потом на этапе шейдинга, мы сами по triangleId и instanceId можем взять нужные данные для материалов, текстурных координат, нормалей и т.п.

Ну и собственно также понятно почему наниты не могут использоваться в forward rendering-е

g-cont
Меньше слов больше дела

А доки покурить ? :)

MikeNew
> а то что не надо передавать матрицы для того что не будет нарисовано
Так их и не получится передать - gl_instanceID не ремапится, текстуру с матрицами придётся забивать только актуальными данными, в случае предварительного куллинга на CPU.

ZeroCool++
> Это полностью софтверная растеризация, которая реализуется на вычислительных шейдерах
Назвать CUDA "софтварной растеризацией" у меня язык как-то не поворачивается.

ZeroCool++
> Собственно это и есть вишенка нанита.
Ну я понял, это что-то вроде древнего Unlimited Detail, только реально рабочий, в отличие от.

MikeNew
> На том скрине из Microsoft Flight Simulator (это оттуда же?) я подозреваю что
> это все-таки биллборды (но сам не играл, потому утверждать не буду).
Предположим, что это всё билборды (хотя с точки зрения результата рендерить куб будет покачественнее всё же). Что по твоему передается на отрисовку? Сами билборды, состоящие из 4-х вершин? Позиция билборда + ширина и высота? Что-то же в конце концов передается? Что именно по твоему должно передаваться в этом случае?

MrShoor
> Позиция билборда + ширина и высота?
Я это передаю, гораздо меньше чем матрица.
Биллборды можно рисовать как частицы, будет очень быстро.
Не надо матрицы в шейдере умножать.

Хотя конкретно в случае MFS может это и не биллборды, так как те при виде сверху ужасно будут выглядеть.. хотя если их менять на лету, в зависимости от угла взгляда на них.. хз..
Интересно все таки, как там сделано.

MikeNew
> Я это передаю, гораздо меньше чем матрица.
Только для этого надо считать размеры билборда на CPU перед передачей. А матрицы скорее всего уже итак есть, ведь при приближении дерево будет заменяться 3д моделью, а ей то уже нужна матрица.

> Не надо матрицы в шейдере умножать.
> Биллборды можно рисовать как частицы, будет очень быстро.
Поверь, с матрицами ты тоже особо не заметишь разницы. Т.к. ботлнек будет совсем не на вершинном шейдере.

> гораздо меньше чем матрица
Если передавать кватернион + позицию, то твой "подход" меньше всего на 2 флоата :) Экономия на спичках.

> так как те при виде сверху ужасно будут выглядеть.. хотя если их менять на
> лету, в зависимости от угла взгляда на них.. хз..
> Интересно все таки, как там сделано.
Типично - рендерят куб, и реймаршат в текстуре примерно как с parallax mapping-ом. Но есть разные подходы. Гугли по ключевым словам Impostor Rendering
Но как именно сделано в MFS - не скажу, т.к. не дебажил его.

MrShoor
> Только для этого надо считать размеры билборда на CPU перед передачей. А
> матрицы скорее всего уже итак есть, ведь при приближении дерево будет
> заменяться 3д моделью, а ей то уже нужна матрица.
> .........
> .........
> .........
Это было познавательно, спасибо.
И точно мне пригодится.

MrShoor
> Типично - рендерят куб, и реймаршат в текстуре примерно как с parallax
> mapping-ом
А это не слишком дорогой импостор?

MikeNew
> Интересно все таки, как там сделано.
Скорее всего, как тут https://evasion.inrialpes.fr/Membres/Eric.Bruneton/ (Forests)

g-cont
> А это не слишком дорогой импостор?
Дорогой по сравнению с чем?