Китайский домик.

[Ruslan]

Нет, нету, я скачивал, но у меня что то не получилось с импортом, и я убил демку..
Ден, только ты кроме 10 Станфордских Драконов не оптимизированных, для чистоты эксперимента, попробуй вменяемые по количеству фейсов объекты закинуть.

[→|๖ۣۜDen|←]

хорошо
Драконы) это я уж так..

[Alteste]

о каких драконах идет речь?
Что то вы ушли далеко от темы

[→|๖ۣۜDen|←]

о каких драконах идет речь?
Что то вы ушли далеко от темы

http://en.wikipedia.org/wiki/Stanford_Dragon

[Sqwer]

А может вам проще поступить:   перхудом проверить,  я сделать не могу  т.к. нет худа на 7.

[Ruslan]

я тоже на 7 ке

[→|๖ۣۜDen|←]

1 модель = 11155 вершин (20432 фесйов). URE: 30-31 fps.   0.0333 сек/фрейм
10 моделей = 111550 вершин (204320 фесйов). URE: 15 fps.  0.0666 сек/фрейм
50 моделей = 557750 вершин (1021600 фесйов). URE: 5-6 fps. 0,16 сек/фрейм

[Ruslan]

Intel® Core™ i5-750
ОЗУ 4.00 ГБ
ATI Radeon HD 5850

1920 x 1080
_________________________

  204 320 фейсов - 45 фпс
1 021 600 фейсов - 10 фпс
_________________________

На мой взгляд, исходя из грубых тестов, у Юаней не deferred shading, а forward shading, скорее всего поэтому такое проседание фпс.
С другой стороны, сцена в 200 000 фейсов (45 фпс) - вполне приличная, это из расчета, что если при всем этом, используются лоды и системы оптимизации.

[Macro]

Информации к размышлению более чем достаточно. Вывод - учиться, учиться и еще раз учиться.

[dfx]

Ruslan и Sqwer
Вы так восторгаетесь deffered shading. Можно поинтересоваться? А вы используете этот подход в реальных проектах? Такое безапиляционное утверждение  Sqwer'а
как,

преимущественно во всех сценах будет выруливать диферед

Наводит на мысль, что Sqwer его использует. Тогда, мне интересно, как была решена проблема с использованием сложных материалов, имеющих 6-12 управляющих параметров в комплексе с 2-3х канальными масками.
Или когда в сцене большое количество полупрозрачных объектов, например?

Как передаете параметры, в случае использования таких техник, как MRT или Radiance Normal Maps? Мне, например, SSAO не подходит, по причине низкого качества, кроме того этот алгоритм по своей природе не может считать притенения от объетов, которые не попали в камеру - что тоже не подходит. Алгоритмы SSAO, где в расчетах учавствуют несколько позиций камеры или слои - можно отсеивать, т.к. это уже не один вызов геометрии. Кроме того притенение SSAO нельзя ввести в зависимость от положения ИС.(В случае с RNM это делается без проблем). Есть, конечно, HBAO алгоритм, но он работает с dx10 и сильно грузит GPU. Поэтому приходиться использовать Precalculaed-техники.

100 источников света (направленных , затухание по квадрату растояния) в сцене без просатки ФПС  !!! 

Это, безусловно круто! А вызов лайт-объемов вообще никак не сказывается на производительности?Или в квесте их всетаки можно инстансить?

в отличии от форварда стадия освещения не восприимчива к количиству вершин.

Так освещение в форвард тоже идет после растеризации. До 10 ИС можно спокойно юзать, так же, порезав им дистанцию(для поинт-ИС точно), ведь когда доходит дело до освещения, ввершины то уже не нужны! Или в дефферед даже создание G-буффера не зависит от количества вертекстов?

все постэффекты SSAO / Sushaft/ Blur/ мягкие частицы  и т.д.  используют G буфер, в случае диферда он достаётся БЕСПЛАТНО!!!

Ну с этим я не согласиться просто не могу! Что правда- то правда. Если уж посчитали G-buffer, то почему бы его не использовать?

современные видяхи обладают быстрими ROP, большим количеством памяти, т.е. для них отрисовать фулскрин лейн - плёвое дело, (не то что старенькие карточки) т.е. не стоит обращать внимание на казалось бы большой объём перегоняймой памяти.

А вот это спорно - на объем памяти обращать внимание все же надо. Кроме того шина не ризиновая. А еще есть такое понятие, как средняя системная конфигурация целевой аудитории. У каждого своя современная видяха.
   

Прокатит при чёрно-белой сцене.в иных ситуациях - фейк, при том очень палевный.

А еще в сцене, где можно динамически менять диффузные текстуры. И в Out-door сценах, где можно использовать схему "Желтое солнце/Синее небо". И вообще цвет в ЛМ можно заменить на SSII - от него пользы явно будет больше, чем от SSAO. А насчет палева... Ну это смотря как реализовать - у кого-то палевный, а у кого-то и нет.

Печально что разработчики запаздывают за технологиями.

В случае, если разраб ориентируется на массы, то исследуется средняя кофигурация какой либо группы, проводится анализ и т.д. Если один заказчик, то он сам может задать планку - ему виднее, где он это приложение будет использоваться. А как насчет 3д-блоков на веб-страницах? Даже если у Вас все клиенты с HiEnd видяхами, то все равно читать такое, по меньшей мере, странно.

С уважением, Юрий.

[Ruslan]

Тогда, мне интересно, как была решена проблема с использованием сложных материалов, имеющих 6-12 управляющих параметров в комплексе с 2-3х канальными масками.

Для примера, приведу цитату из статьи:
Перевод:
http://ru.ziggyware.com/readarticle.php?article_id=16&rowstart=0
Оригинал:
http://www.catalinzima.com/?page_id=14

VI. Несколько материалов
Одним из недостатков отложенного затенения является ограниченное количество типов материалов. Модель Фонга, которую мы используем в данный момент, позволяет выполнять настройку через интенсивность отражения и мощность отражения. Используя их мы можем получать поверхности с разной степенью блеска, как было показано в предыдущих главах. Однако, световая модель не может моделировать любой тип поверхности, чего нам может хотеться. Например, бархатная поверхность, на которой появляются мягкие блики при малом угле зрения не может быть нарисована с использованием модели Фонга. К счастью, есть решение.

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

Другим решением может стать хранение идентификатора материала. Затем, на основании этого идентификатора к различным типам поверхности модели будут применяться различные шейдеры освещения. Это похоже на обычную визуализацию с многочисленными шейдерами для каждого типа объектов в мире. Однако, что будет критерием, позволяющим определить, какой шейдер использовать для каждого источника света? Рисовать каждый источник света несколько раз с каждым возможным шейдером очень медленно. Базируясь на данном решении, мы можем переместить все шейдеры в единый сверх-шейдер, и определять, какую формулу применять, используя множество ветвлений. В таком случае последовательность ветвлений может быть весьма приемлемой, поскольку пиксели, которые заключены на экране, имеют тенденцию относиться к одному и тому же материалу. Но для объектов с большим количеством моделей освещения может потребоваться достаточно много ветвлений. На сегодняшнем оборудовании это не слишком хорошая идея, но метод можно держать в уме для использования в будущем. По мере усовершенствования видеокарт ветвления будут становиться все менее и менее дорогостоящими, а данное решение будет выглядеть все более и более привлекательным. Но сейчас нужно другое решение, которое будет дешевым и обладать достаточной гибкостью.

Идея состоит в хранении реакции на освещение в текстуре. Затем мы можем прочитать данные из этой текстуры, использовать параметры, такие как N*L и N*H (H – это половинный вектор, являющийся заменой для вектора отражения в модели освещения Блина), и вернуть интенсивность освещения. NVIDIA предлагает пример реализации такого подхода на своем сайте.

Как видите, это приводит к интересному световому эффекту, который недостижим при использовании одной только модели Фонга. Если у нас есть текстура реакции на освещение для каждой модели освещения, которую мы хотим реализовать, то мы просто выбираем между этими текстурами, используя идентификатор материала. Более того, если мы храним эти текстуры в трехмерной текстуре, можно использовать идентификатор материала в качестве третьей координаты текстуры. Итак, для получения реакции на освещение конкретной поверхности мы можем осуществлять выборку из трехмерной текстуры, используя координаты (N*L, N*H, ID), где N – это нормаль поверхности, H – половинный вектор, а ID – идентификатор материала. К сожалению, я не могу привести пример использования этой техники, поскольку сам только начал экспериментировать с ней в коде еще все наперекосяк. Кроме того, эта тема заслуживает собственной отдельной статьи и выходит за рамки данного урока.

Такая техника с использованием идентификатора материала для выборки реакции на освещение из трехмерной текстуры уже применялась в коммерческой игре (S.T.A.L.K.E.R.), и является замечательной областью для дальнейших экспериментов, если вы интересуетесь визуализацией с отложенным затенением. Кроме того, она может быть еще расширена путем использования BRDF, где выборка информации об освещении производится в двух и более текстурах. Больше примеров использования текстур BRDF можно найти в библиотеке шейдеров NVIDIA.

dfx
Или когда в сцене большое количество полупрозрачных объектов, например?

Прозрачность
Как мы увидели ранее, прозрачные объекты создают проблемы для визуализатора с отложенным затенением. Причина очевидна: поскольку освещение применяется в конце, после того, как все нарисовано, освещена будет только ближайшая к камере точка. Следовательно, если мы попытаемся нарисовать прозрачный объект, объекты за ним будут видимы, но не будут правильно освещены. Решением является визуализация всех прозрачных объектов после применения отложенного освещения. Они будут рисоваться обычным способом, с использованием передового визуализатора и смешиваться с изображением, полученным в результате работы отложенного визуализатора.

Как передаете параметры, в случае использования таких техник, как MRT или Radiance Normal Maps?

Думаю, что сами с этим разберетесь.. 

Алгоритмы SSAO, где в расчетах учавствуют несколько позиций камеры или слои - можно отсеивать, т.к. это уже не один вызов геометрии.

ага, не к чему, это делать лишний раз.

Цитировать
100 источников света (направленных , затухание по квадрату растояния) в сцене без просатки ФПС  !!! 
Это, безусловно круто! А вызов лайт-объемов вообще никак не сказывается на производительности?Или в квесте их всетаки можно инстансить?

На сколько мне известно, не нужно вызывать никакие лайт-объемы, в шейдер передаются положения и другие пораметры ИС.

Так освещение в форвард тоже идет после растеризации. До 10 ИС можно спокойно юзать, так же, порезав им дистанцию(для поинт-ИС точно), ведь когда доходит дело до освещения, ввершины то уже не нужны! Или в дефферед даже создание G-буффера не зависит от количества вертекстов?

Освещение в форворде, расчитывается, даже для тех пикселей, которые в дальнейшем могут перекрыватся другой геометрией (то есть впустую), а в деффереде расчет идет только по видимым.

Или в дефферед даже создание G-буффера не зависит от количества вертекстов?

G-буффер в деффереде строится простым шейдером, тоесть очень быстро, и без смены рендер стейтов, тоесть количество фейсов не кретично. Ну и конечно же, при создании G-буффера используется MRT.

А вот это спорно - на объем памяти обращать внимание все же надо. Кроме того шина не ризиновая. А еще есть такое понятие, как средняя системная конфигурация целевой аудитории. У каждого своя современная видяха.

Это уже философия 
Под крупные проекты, которые обычно демонстрируются богатым инвесторам, покупают топовые решения.

Кстате, на тему deffered shading под Квест:
http://forum.quest3d.com/index.php?topic=68471.0

[dfx]

Ruslan
Спасибо за ответ.
Хорошие статьи.
Да, я не написал об этом( Я в реализаци пробовал использовать идентификаторы, когда занимался этой техникой. При использовании идентификаторов на подобъект, такая схема работала хорошо. Но попытка использовать их совместно с масками не удалась - у масок пиксели на границах интерполируются, и значения получаются дробные. Например, первый слой - ид1, а второй - ид5. На переходе получаем любой ид от 1-5:). Что выглядет визуально, как рябящий контур на местах перехода.

На сколько мне известно, не нужно вызывать никакие лайт-объемы, в шейдер передаются положения и другие пораметры ИС.

В принципе можно все выводить и квадами, если использовать поинт-лайты. Если юзать конусы, пирамиды и т.д., то можно больше типов источников симулировать. Странно, что не слышали. У меня был поинт и таргет-директ (цилинр), до других дело не дошло.

Ну и конечно же, при создании G-буффера используется MRT.

Да, ждал 4.3 версию квеста из-за этого мрт, до этого тестил на мультипасе, а скорость не на столько выросла, как хотелось после подключения MRT. Наверное BRDF комбинированный все убил

Думаю, что сами с этим разберетесь..

Ну вот! Мне это интереснее всего было! Тут получается, что параметры придется передавать черед RTT в любом случае, а это пара-тройка MRT (4х3) - дорого. Коэффициенты то в вершинах

Спасибо еще раз.


Добавлено позже:

У нет... И все же не подойдет deffered для манипуляций с RNM. Похоже вы просто не работали с этим.
Для расчетов используются 3 базисных вектора и нормали - это 12 значений надо (9 - если восстанавливать третью компоненту, а это доп инструкции на каждый ИС)! Есть вариант чуть дешевле для G-буффера - передавать нормали, винормали и тангенты и считать вектора позже(тогда получится 9/6), но в этом случае базисные вектора надо считать для каждого ИС заново, а в форворд - 1 раз для всех(1-10), что может убить все приимущество деффереда в скорости! Я еще вернусь к этому вопросу позже.
Но смысл остается - не для всего дефферед подходит! Т.ч. ждем дх10 в квесте. А пока дефферед только для больших сцен, где не требуется высокого качества предпросчитанного AO в RNM. Про PRT вообще можно молчать.

[Sqwer]

&dfx

Похоже вы просто не работали с этим.
Для расчетов используются 3 базисных вектора и нормали - это 12 значений надо (9 - если восстанавливать третью компоненту, а это доп инструкции на каждый ИС)!

вопрос, зачем нам гнать в G буфер тангенты и бинормаль?


И зачем нам нужет этот древний RNM   если есть Диферред?!
вы хоть знаете как  они работают? в чём плюсы и минусы подходов?

В случае, если разраб ориентируется на массы, то исследуется средняя кофигурация какой либо группы, проводится анализ и т.д. Если один заказчик, то он сам может задать планку - ему виднее, где он это приложение будет использоваться. А как насчет 3д-блоков на веб-страницах? Даже если у Вас все клиенты с HiEnd видяхами, то все равно читать такое, по меньшей мере, странно.

мы делаем демки исключительно под конкретное железо.
фирмы специально приобретают ноуты по нашим рекомендациям.
предметная область - демонстрация архитектуры.

Наводит на мысль, что Sqwer его использует. Тогда, мне интересно, как была решена проблема с использованием сложных материалов, имеющих 6-12 управляющих параметров в комплексе с 2-3х канальными масками.

сложные материалы с большим кол-вом параметров не используют даже крутоделы с Крайтеха   (Край Энжин 3)
а все знают что их графике "позавидует и холивуд"
А если покапать учебники физики, то найдёте для себя то, что можно вообще любой непрозрачный материал представить всего 4мя векторами. т.е. 4 текстуры по 4 команенты

Или когда в сцене большое количество полупрозрачных объектов, например?

для прозрачки юзаем форвард , освещение кубамаповское
+ по вкусу  /ИС / хроматическая дисперсия /  блёр/

Так освещение в форвард тоже идет после растеризации.

поздравляю с большим овердравом

Прокатит при чёрно-белой сцене.в иных ситуациях - фейк, при том очень палевный.
А еще в сцене, где можно динамически менять диффузные текстуры. И в Out-door сценах, где можно использовать схему "Желтое солнце/Синее небо". И вообще цвет в ЛМ можно заменить на SSII - от него пользы явно будет больше, чем от SSAO. А насчет палева... Ну это смотря как реализовать - у кого-то палевный, а у кого-то и нет.

Ещё раз вдумайтесь в мои слова, проанализируйте ситуацию.
(отрендите её в голове).

100 источников света (направленных , затухание по квадрату растояния) в сцене без просатки ФПС  !!! 
Это, безусловно круто! А вызов лайт-объемов вообще никак не сказывается на производительности?

ИС и волюмы - разные вещи между собой не связаны

Есть, конечно, HBAO алгоритм, но он работает с dx10 и сильно грузит GPU.

тем более, я уж лучше выборок в ССАО побольше сделаю.

алгоритм по своей природе не может считать притенения от объетов, которые не попали в камеру

есть методы обойти такую беду. но зачем??? фейк не палевный

В принципе можно все выводить и квадами, если использовать поинт-лайты. Если юзать конусы, пирамиды и т.д., то можно больше типов источников симулировать. Странно, что не слышали. У меня был поинт и таргет-директ (цилинр), до других дело не дошло.

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

Зы конус передать оч просто   dot(направление луча ИС, направление конуса).