Войти
ПрограммированиеФорумГрафика

G-Buffer (4 стр)

Страницы: 13 4 5 68 Следующая »
#45
(Правка: 21:06) 20:15, 14 июня 2021

Battle Angel Alita
> Форвард фечит все параметры материала(ака текстуры), обрабатывает и выводит
> результат сразу во фрэймбуффер. Деферред - кэширует парамеиры материала в
> g-buffer, и только потом фечит их и считает. Всё остальное - частности
> реализации. И в форварде можно сделать 100 источников света за проход, и в
> деферреде рисовать каждый меш по 100 раз.
(Прочитал повнимательнее)
Окей. Есть ссылки где описывается форвард рендеринг с обсчетом N источников в один пасс? (С упоминанием что это форвард)

Окей, спасибо за объяснение терминологии. Напомню, что Eugend говорил об "обычном форварде". Обычное ли это дело, когда форвардом эффективно обсчитывается сложная сцена с большим колв-вом источников за один проход?

MrShoor
> И в ней нет ничего в духе: "на каждый лайт отдельный проход рендера геометрии."
Есть, под заголовком "Lighting Performance"

MrShoor
> А как ты думаешь, какой тип освещения в тех двух статьях, которые я привел как пример?
Мое мнение на этот счет не имеет ценности) Да и какая разница? Они не помогают разрешить сложившийся терминологический конфликт его в ту или иную сторону.

PS:
Почитал статью что ты кидал выше (вторую). Ну да, там вроде нет никакого гбуффера. Это достаточное условие чтобы назывпть подход форвардом?
PPS: если промотать назад, с чего дискуссия началась - Eugene утверждал за "обычный форвард". Ну т.е. это не противоречит тому, что могут быть форварды и не такие. Статьи что ты кинул - с учетом определения данного Battle Angel Alita, аполне себе подходят под "необычные форварды" (по крайней мере вторая).

Тогда вопрос в том, насколько это жизненный подход? Есть ли примеры боевых реализаций форвард рендереров, сравнимых по производительности с деферредом на сложных сценах, где много источников света?


#46
(Правка: 21:10) 21:07, 14 июня 2021

kkolyan
> Есть, под заголовком "Lighting Performance"
Да, почитал, автор Brent Owner. А потом глянул что еще он пишет, и всё стало понятно, это юнитибой.

> Они не помогают разрешить сложившийся терминологический конфликт его в ту или
> иную сторону.
Если ты хочешь терминологии то надо смотреть откуда вообще возник Forward lignting.
Давным давно (юнити тогда этих ваших еще не было), когда еще deferred не стал какой-то популярной техникой - никто не называл forward форвардом. Но как только deferred стал распространяться - понадобилось как-то отличать deferred от forward-а. Т.е. существовало:
1. динамическое / запеченное освещение
2. повертексное / попиксельное
3. форвард / деферред
Вот как-то так и появился форвард. И он не накладывал никаких ограничений, как много проходный рендер или однопроходный. Просто был деферред, и был НЕ деферред который стали называть форвард.

> Почитал статью что ты кидал выше (вторую). Ну да, там вроде нет никакого
> гбуффера. Это достаточное условие чтобы назывпть подход форвардом?
В принципе да, достаточно. Но сейчас в довесок появились: Forward+ и Clustered Lighting, которые описывают уже конкретные реализации Forward рендеринга, и часто (но не всегда) когда упоминают Forward - имеют ввиду форвард который не Forward+ и не Clustered Lighting.

upd. Вот например в Unreal Engine говорят Forward, но у них это Clustered реализация форварда:
https://docs.unrealengine.com/4.26/en-US/TestingAndOptimization/P… wardRenderer/

The Forward Renderer works by culling lights and Reflection Captures to a frustum-space grid. Each pixel in the forward pass then iterates over the lights and Reflection Captures affecting it, sharing the material with them.

#47
22:42, 14 июня 2021

kkolyan
> Есть ли примеры боевых реализаций форвард рендереров, сравнимых по
> производительности с деферредом на сложных сценах, где много источников света?
Нет, если подразумевается обычный forward, он же forward-. Даже без юнитековской дичи с рендером одной геометрии несколько раз - форвард без дополнительных ухищрений чертовски медленный, на действительно серьёзном числе источников света (100+).

#48
(Правка: 23:56) 23:48, 14 июня 2021

MrShoor
Понятно, спасибо за объяснение. Почитал про clustered. Не, ну в принципе, если в самом уе есть поддержка такого, то монополия "форварда-" явно закончена.

А насчет N пассов в юньке, возможно рановато ее браковать за ее особенный форвард. Насколько я понимаю, имеется в виду генерация N "каскадов" шейдеров (они там как раз зовутся пассами в терминах языка обвязки шейдеров), но не отправка N раз всей геометрии и юниформов на GPU. Т.е. по сути это и есть цикл в шейдере, просто чуть более аккуратно в коде выглядит. Это впечатление, основанное на перекрестном чтении большого кол-ва страниц в доках, а не какой-то одной, так что ультимативный пруфлинк кинуть не могу.

HolyDel
По сути локальная дискуссия и была о том, что же понимать под форвардом) теперь я понимаю что считать форвардом по-умолчанию "форвард-" - не очень современно.

Насчет дичи в юньке - я ппредпологаю что, юньковские доки просто сбили всех с толку, перегрузив термин "пасс". Подробнее - в предыдущем посте

#49
0:19, 15 июня 2021

kkolyan
Хоспаде, что ты несешь? Какие каскады шейдеров? Какие термины языка обвязки шейдеров? Открой рендердок и посмотри, как Builtin RP рисует геометрию несколько раз на каждый влияющий на эту геометрию источник света. Нормальными отдельными дипами. Без всяких каскадов и терминов обвязок.

#50
0:27, 15 июня 2021

Dampire
Рот помой. Но за инфу спасибо, буду знать.

#51
(Правка: 4:30) 4:28, 15 июня 2021

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

#52
(Правка: 5:25) 5:25, 15 июня 2021

kkolyan
> Есть ли примеры боевых реализаций форвард рендереров, сравнимых по
> производительности с деферредом на сложных сценах, где много источников света?
Doom, Order 1886, колда

#53
5:35, 15 июня 2021

Suslik
> придётся делать switch или подобный костыль.
У меня сложилось впечатление, что все эти "if"-ы и "case"-ы в шейдерах не так страшны как принято считать. А вот каждый лишний рендерпасс - фпс как ножом по горлу.

#54
(Правка: 6:02) 5:49, 15 июня 2021

kkolyan
> Есть ли примеры боевых реализаций форвард рендереров, сравнимых по
> производительности с деферредом на сложных сценах, где много источников света?
Подозреваю, что неплохих результатов можно добиться (опять же до определенного количества огней) с помощью грамотного CPU-кулинга источников света. Но это будет дополнительная нагрузка на CPU.
Если чисто источников света меньше двадцати-тридцати, то всяко обычный форвард по-любому лучше что деффереда, что форвард-плюса, в этом у меня никаких сомнений. Так как G-буфер (из-за  необходимости дополнительных проходов и чтения из текстур) сильно тормозная вещь, как не крути.

#55
(Правка: 6:23) 6:20, 15 июня 2021

MikeNew
> У меня сложилось впечатление, что все эти "if"-ы и "case"-ы в шейдерах не так страшны как принято считать
да просто говнокод, делов-то. он вполне может работать и работает. разница лишь в том, что в нормальном коде чтобы отрендерить N+1 одних источников вместо N, нужно в одном месте константу поменять, а в таком говнокоде нужно в 3х местах дополнительный код дописывать на каждый новый источник (объявление ресурса, чтение и применение). ну и асимптотическая сложность кода переходит из линейной в квадратичную, но на фоне остальных недостатков этим можно просто пренебречь, лол.

#56
10:44, 15 июня 2021

kkolyan
> Рот помой.
После твоей терминологии не только рот мыть пришлось, но и клавиатуру с пальцами.

#57
(Правка: 11:42) 10:56, 15 июня 2021

Battle Angel Alita
Suslik
MikeNew
спасибо за инфу

***
а чем можно объяснить этот диковинный подход юнитеков? подозреваю что это как-то упрощает работу юзера с шейдерами. с другой стороны, работа со светом и так выведена там в отдельный "cginc". сомневаюсь размещение там цикла по лайтам усложнило бы юзерский код.

Suslik
Dampire

+ Показать
#58
12:12, 15 июня 2021

kkolyan
> а чем можно объяснить этот диковинный подход юнитеков?
> диковинный
Лол. Юнити уже лет 15, тогда все так делали. Анрил третий точно так-же меши по 10 раз рисовал.

#59
12:23, 15 июня 2021

kkolyan
> неумышленное использование корявой терминологии - не повод для хамства.
А умышленное придумывание фактов с целью показаться умнее повод?
> Это впечатление, основанное на перекрестном чтении большого кол-ва страниц в доках, а не какой-то одной, так что ультимативный пруфлинк кинуть не могу.
Интересно где это в доках написана подобная пурга про циклы, каскады шейдеров и языки обвязки?

Страницы: 13 4 5 68 Следующая »
ПрограммированиеФорумГрафика