Войти
Urho3DФорумЗАДАВАЙТЕ ВОПРОСЫ

[АРХИВ] Шейдеры, техники, rendering path'ы (3 стр)

Страницы: 1 2 3 4 524 Следующая »
#30
0:12, 2 дек. 2015

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


#31
12:30, 2 дек. 2015

>Какое оно когда вкл.-выкл. делаете?
В редакторе нет FPS счётчика, но думаю порядочно садит FPS не смотря даже на то что размывка лучами идет в RT - который в двое меньше размера фрейма.
Это самая простая техника для подобного эффекта.
Есть более сложные и производительные:
http://www.slideshare.net/BenjaminGlatzel/volumetric-lighting-for… of-the-fallen
https://software.intel.com/en-us/articles/ivb-atmospheric-light-scattering

По первой ссылке есть интересная оптимизация - разбивка RT на Grid 8x8 пикселей, но я так до конца и не понял как она работает (

>Может в этом причина?
сомневаюсь, вероятно просто эффект достаточно "дешёвый" в плане вычислений

Edit:
Допилил пример: https://github.com/MonkeyFirst/urho3d-light-scattering (есть собранный exe'шник)
Сделал два разных RenderPath'a c лоурезными и сильно лоурезными RT циклически переключаются на - F3
F4 - включает стандартный форвард для сравнения фпс
У меня с включением LS падает с 360фпс до 278фпс.

 

#32
3:29, 3 дек. 2015

Когда своими руками шевелишь это - еще круче, чем на видео :)

p.s. ForwardSUNFast.xml мало того, что быстрее, так еще и выглядит лучше - нет радиальных разводов

#33
11:28, 3 дек. 2015

>ForwardSUNFast.xml мало того, что быстрее, так еще и выглядит лучше - нет радиальных разводов
У тебя сильно падает фпс?
У меня в общем в прошлый раз походу на встроенном Интеле запустилось сейчас перемерял
forward - 760 fps
forwardSUN - 436 fps
forwardSUNFast - 460 fps

Остальные параметры я не вывел для настройки, но их можно прямо в RenderPath'е менять. Вес(Weight) к примеру сильно увеличивает эффект.
В качестве оптимизации можно поднимать вес(Weight) и уменьшать это значение в шейдере const int NUM_SAMPLES = 70;

#34
15:10, 3 дек. 2015

> У тебя сильно падает фпс?
Сильно, фпс на треть падает

#35
15:15, 3 дек. 2015

Я вот еще вариант реализации нашел http://www.geeks3d.com/20140204/glsl-volumetric-light-post-proces… webcam-video/
Тут я, как понял, источник света радиально размывается. Или это тот же самый вариант реализации?

#36
15:49, 3 дек. 2015

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

копать нужно в эту сторону:
http://www.slideshare.net/BenjaminGlatzel/volumetric-lighting-for… of-the-fallen
41й - 52й слайд: аккумулятор пасс, тайловое разбиение, блюр... 

#37
23:39, 3 дек. 2015

>Куда копать? Чего погрызть?
Это ты что пытаешься сделать? Судя по vScreenPos пост-процесс шейдер препарируешь.

>Куда копать? Чего погрызть?
вообще наверное нужна более развернутая инфа: что рисуется и техника рисования, как выглядит твой RеnderPath :
а если в небо пальцем то:
- для пост процессов использовать RT меньшего размера чем фрейм буфер
- рисовать шейдером чтобы срабатывало отсечение по Z-equal (необходим z-препасс проход для непрозрачных)
- использовать MRT (дополнительные данные писать в них чтобы уменьшить количество переключений пассов в RеnderPath в целом, а в пост процессах собирать что-то "годное" из этих MRT )

#38
10:12, 4 дек. 2015

>а результат одинаков -20 кадров (+- 1-5 кадров)
А порядок цифр какой? падение с 1000фпс до 600 или с 40фпс до 20 ?
Я не знаю что это за эффект такой, (наверное как в silent hill 2 noise?) но если его можно аддитивно смешивать то я бы нарисовал его в текстуру меньшего размера в RT и потом в quad команде смешал бы его с основным кадром.

и еще: зачем у тебя включен alphamask="true" если ты пишешь постоянно 1.0 в альфа канал на выходе? по идее блендинг задейсвован, хотя тип блендинга явно не указан
попробуй указать явно replace: <command type="quad" vs="Noise" ps="Noise" blend="replace" output="viewport">

#39
12:35, 4 дек. 2015

>Как писал выше даже если 2 строчки в шейдере которые ничего особо не вычисляют.

Я не знаю насколько это отвечает действительности, но я попробую тебе объяснить так:

допустим 1 raster operations pipeline(ROP) за такт GPU может записать 1 пиксель.
допустим видео карта имеет 16ROP частота её 1100Mhz

16ROP * 1100mhz = 17600mpix/s = 17.6Gpix/s (пик ее возможностей по филлрейту, ну вот просто 17лярдов пикселей может в секунду нарисовать и все, не больше)

запись 1920*1080 = 2073600pixels 0.2Gpix

17.6 / 0.2 = 88 FPS если каждый пиксель будет проходить тесты: глубины, стенсиля, альфа теста и в шейдере будет просто писаться белый цвет. (Полная заливка кадров в пике должен где-то получить 88 фпс может еще меньше)

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

#40
14:35, 4 дек. 2015

>В чем взаимосвязь?
Мне кажется тут нет какого-то определенного места куда можно ткнуть пальцем и сказать что вот тут у тебя вся разница "съедается" это все-таки комплексная нагрузка.
Тебе как-то нужно более точно локализовать затраты на пост процесс вычисления чтобы быть уверенным что эта разница не возникает где-то раньше.
В одном случае "перс в зоне видимости" в другом нету его - нагрузка на филлрейт разная еще до пост процесса.

В добавок разница в:
+ в разном кол-ве проходов и шейдеров (сравни сколько pass'ов делает блум и сколько шейдеров юзает)
+ в разной нагрузке шейдеров (у тебя одно чтение и запись у блюма 5 чтений +1 запись на V и H проход + 2 чтения и запись на combine проход  )
+ в разном фактическом размере фрейм буфера на момент того или иного просчета (блум использует два RT которые в 4(2) раза меньше размера фрейма, у тебя вроде полноразмерный )

+ в разном количестве пикселей на экране которые попали туда после Z-теста (площадь закраски разная - "перс в зоне видимости") (но этот пункт в большей степени относится к фазе до пост-процесс эффектов)
...

#41
17:35, 4 дек. 2015

по последним картинкам все очень логично и укладывается в мысль о том что прогоняя фуллскрин эффекты - садиться филлрейт (скорость закраски)

#42
18:15, 4 дек. 2015

radio
Ты ведь понимаешь, что снижение фпс на N кадров с 60 и с 1000 - это не одно и тоже?
Лучше измерять время затрачиваемое на рендеринг кадра.

#43
19:56, 4 дек. 2015

Нет, просто, как мне показалось, тебя(давай на ты, ладно?) удивляет, что фпс после добавления эффекта в одном случае падает на 30, а в другом на 9. Так это нормально. Если перевести расчеты в секунды/миллисекунды то все становится на свои места.
в фпс-ах:
> 120-90 -30 кадров (камера смотрит в землю)
> 59-50 -9 кадров (камера смотрит прямо)

в миллисекундах:
1000/120 - 1000/90 = -2.78 мс
1000/59 - 1000/50 = -3 мс

то есть в обоих случаях на эффект тратится ~3 миллисекунды.

в третьем случае получается не то
> 190-193 -3 кадра (камера видит только небо)
1000/193 - 1000/190 = -0.08 мс

не знаю как это объяснить, возможно измерения были сделаны не точно

#44
20:11, 4 дек. 2015

по-моему, первые два результата(что на эффект требуется 3 мс) правдоподобнее.
у меня появилось предположение почему в 3-м случае это не так - движок ограничивает фпс в пределах 200.
без этого бы получились те же 3 миллисекунды.

Страницы: 1 2 3 4 524 Следующая »
Urho3DФорумЗАДАВАЙТЕ ВОПРОСЫ

Тема в архиве.