Quest3D - Русскоязычное сообщество

Всем привет.
 
Нужны глосси-отражения, в условиях статичной сцены и освещения.
Достаточно в GrayScale и приличным размытием. Я так понимаю, что можно обойтись двумя RGBA текстурами, но запечь отражения в тектуру vray не может, т.к. просто не существует такого рендер-элемента для RTT.

Делать материалы полностью отражающими - не выход, т.к. они примамают тени. А сделать так, что бы объект не приниал тени если виден в камеру, но принимал, если в отражении нельзя.)

Есть у кого какие-нибудь идеи?

Привет!
не совсем понял о чем речь, особенно про тени
может стоит сделать дополнительную нормалку (шумовую), делать из нее выборку вектора, умножать на коэффициент и учитывать дополнительно этот вектор при выборке из кубмапы, возможно, что таким образом можно будет добиться эффекта глосси

Юзай имэйдж спэйс  рефлекены

и вокруг детерминированной точки делай   гаус выборку.


естественно  у тебя должен быть полный G-буффер.



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

Ruslan
Для блура кубамапы в реалтайм я делал выборки по скринспэйс нормалке, т.к. локальная работала совсем не так - при включенном мипмапинге весь шум терялся и разблуренность пропадала. При отключенном - жуткая каша пикселей. Но реалтайм-блур алгоритм очень тяжелый, использовался только потому, что нужны были размытия для анизотропных материалов.
Кроме всего некий шум таки остается. Чем больше пассов, тем глаже, но тормознее. :(

Кстати, видел ролик, где чел демонстривал такие размытия, но у него они были очень гладенькие и работало все шутро. Если в курсе его магии, намекни, кде копать. ;)

Кубамапу я не хочу применять в силу отсутствия локализации отражающихся элементов и отсутствия самоотражения.

Sqwer

При том, что я в эффектах далеко не начинающий, после такой фразы так и хочется сказать: "Вот ты сейчас с кем разговаривал?" ;D
Можно ссылочку? Если есть что то, что считает отражение на криволинейных поверхностях в реалтайме, то я первый в очереди! :)

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

Пока есть мысль хранить 2-3 предпросчитанных текстур с отражением. Т.е. 8-12 каналов для полусферы в тангентспэйс и интерполировать их взависимости от вектора камеры. Это, конечно, не сферические функции, но типа того. Другое дело, что нарендерить это в врей нельзя. Я хотел подменять нормали для каждого канала, но тогда и в отражениях они будут тоже изменены, а значит не корректно освещенный объект в своем отражении. Видимо, поможет, либо смена технологии, либо врей-сдк. :(

Спасибо Вам, за помощь.

на мой взгляд, запечение глосси лишено смысла, так как они зависят от вектора взгляда, то-есть, я вообще сомневаюсь, что их можно запечь.
по поводу IBR, о которых говорил Sqwer, можно посмотреть здесь:
http://www.gamedev.ru/code/forum/?id=147202&page=36
там Che@ter и Chaos_Optima их реализовали в своих демках.

Тогда тем более слова: имэйдж, спэйс, рефлекшнс  должны в крови сидеть!

да и  сочетания  (имэйдж спэйс и  скрин спэйс   в пост эффектах означают одно и то же)

Пжста.  
http://www.gamedev.ru/code/forum/?id=147202&page=26

пэйперов не встречал, но  код и так не хитрый. Там трассеры  нужно делать в 1ом направлении. как узнать направление - не беда  если есть Г буффер с нормалями.

постепенно трассируя лучами мы приближемся к исходной точки отражания.
на этом можно и остановиться , если нужны чёткие отражения, но если нужно именно глосс отражения, то рядом  с этой  искомой точкой можно сделать выборки  и блюрить по гаусу.
Чем дальше  точка обработки от целевой точки  отражения   - тем больше радиус выборок блюра.

Поскольку это всё таки  скрин спэйс, то проблема перекрытых (за кадровых)   объектов  остаётся.

Мы эксперементировали  с примерно подобным алгоритмом,   получилось примерно как в клипе:
http://www.youtube.com/watch?v=CuMjeiDSCOY&feature=BFa&list=PLDA11CB4D56624B23

Sqwer
;D Да, у меня тоже подобное было с тремя коэффициентами в тангентспейс. Вы сколько коэффициентов использовали? Если больше 16 на полусферу, то придется отказаться, наверное. - дороговато будет по ресурсам и по выборкам.
Теоритически, с 8-12 должно быть намного лучше. Я видел PRT глосси отражения, вертексные. Непомню, сколько они коэффициентов использовали, но смотрелось более или менее. Кроме того, в таких алгоритмах используется полная сфера в ворлдспейс. Непонравилось только то, что сетка все же прослеживалась по отражениям.
 
За ссылку на ветку спасибо! Смутило требование дх11. Попробую в алгоритм вникнуть. Но 45 фпс на дх11 картах..  ::)

dx11 для этого алгоритма не обязателен, на dx9 реализуется

dfx
раз ты в теме   OpenCL  , не мог бы подсказать,  как долго биндинг 1024*1024  текстуры    из ОЗУшки в  текстуру ДХ   и обратно  идёт?

и можно ли прям  с видяхи минуя ОЗУ это сделать.


Есть идеи как сделать не фэйковый  ГИ, но нужны выч шейдеры или GPUориентированная реализация  для трассировки лучей.

Встретилась ссылочка http://www.clockworkcoders.com/oglsl/rt/gpurt1.htm,  может подойдет?

нет ,это вьюв  спэйс реализация.

Суть ГИ -  это моделирование отскока. прямой  ортогональный  световой поток  сделать простоЮ но после встречи с препятствием (например чайник)   лучи  света   хаотично распространяются во всех направлениях.  Вью спэйс - это одно направление. Хоть и можно сделать конечное число однопиксельных рендеров вью спейса по направлению лучей отскока, но вот на DIP ах  вся производительность загнётся.


Вторая причина: -  в примере  разберается простейший случай 1 объект.  а если их 20  и каждый перекрывает друг друга, а соответсвенно затирает Z.

Обычный рендер не приемлем.

Sqwer
К сожалению, я не настолько в теме, что бы ответить.

Оффлан рендеры сильно отличаются от реалтайм. То, что они теперь могут использовать гпу, не значит, что они работают полностью на гпу. ЦПУ выступает неким менеджером, который формирует задачи и отправляет их гпу. Т.е. гпу уже получает все необходимые данные для того, что бы сделать вычисления и после возвращает результат. При построении одного кадра таких задач, формируется, огромное количество.
 
В теории,если на дх10 картах, можно копировать, создавать и удалять геометрию, то ничего не мешает в цикле проводить махинации с позициями вершин в геометрическом жейдере и можно посчитать ГИ на уровне одного объекта только в шейдере за один вызов. Только всеравно это будет дорогим удовольствием.

Во вьюспейс полноценный ГИ сделать проблематично. Рендер несколько слоев вьюспейс тоже не поможет, а только займет ресурсы. Как ты верно заметил, надо делать множество вызовов геометрии что превратит реалтайм рендер в офлайн, с реалтайм подходом) Можно сделать некий встроенный предпросчет в 3д текстуры при загрузке, а в процессе делать выборки из нее. Но в этом случае динамики не получится.

Проблема всех вьюспейс техник - недостаток информации, что остается за пределами кадра. С другой стороны, информацию в радиусе камеры получить можно за вызов. Вроде, ты сам говорил, что в дх10 можно считать кубамап за один проход. Если принимать во внимание то, что для ГИ не нужно высокого разрешения, то можно считать кубомапу - G-буфер в небольшом разрешении и таскать данные еще и из нее. Конечно, добавится еще один проход, но все зависит от цели. Информацию за перекрытыми объетами так не получить, но отскоки в зоне сферы камеры посчитать уже можно.

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

Я бы сам не против реализовать ГИ, используя один Г-буфер.
 Пока ничего не придумал. :-[

можно , но на уровне примитивов.  т.е.  склить меши там никак не получится.

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

Дороговато делать проход, что бы убрать этот артифакт) Проще кропить картинку, наверное...
Народ в ветке, куда вы ссылку дали, юзают такую кубамапу для скринспейс рефлектов. Так, что не только, что бы убарть ореол она может пригодиться.
Значит пробовали считать ГИ с кубомапой? Чем результат не устроил? А то вот меня заинтриговали, хотел попробовать реализовать. Теперь сомневаюсь.

Не решает всех проблем.
особенно в случаях, если одна комнота была  одного цвета , а другая -  контрастного по отношению к вервой.

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