Извините, ничего не найдено.

Samodelkin · 17.05.2014, 22:51

Сообщение от mr.DIMAS

Лайтмапы хороши - но блин уже 2014 год на дворе - хочется разнообразия.

http://www.gamedev.ru/code/articles/...agationVolumes
http://the-witness.net/news/2010/03/...uted-lighting/
и вообще весь раздел engine-tech посмотри.

mr.DIMAS · 17.05.2014, 23:26

дефер не совместим с ничем полупрозрачным =P

ахахах, совсем забыл, а ведь читал об этом и все равно забыл.

сделал отдельным проходом, как сказал pax

Mr_F_ · 17.05.2014, 23:50

LightPropagationVolumes

это годная тема, но:
- стоит дважды (а лучше и ещё несколько раз) подумать, прежде, чем приступать к этому, т.к. реализация непростая, и лайтмапы запечь тупо и быстрее и качественнее может выйти. нужно точно понять, насколько тебе нужно действительно динамическое ги.
- тени от индиректа добавляют нехилой нагрузки - насколько я помню, в релизе крайзиса 2 они отключены, а без них индирект светит сквозь всё.
- всего 4 РГБ коэфициента сферических гармоник юзают крайтеки - это маловато для точного описания дифуза - получается менее выраженная направленность отражённого света, он более со всех сторон лезёт. печь 9 ргб коэфов - непрактично.

http://the-witness.net/news/2010/03/...uted-lighting/

дак тут тупо чуваки рендерят радиосити игровым рендером - из каждой точки лайтмапа камеры ставят и фигак.
вариант весёлый конечно, и я так пробовал: http://ndotl.files.wordpress.com/201...5-13-04-37.jpg
но работало оно не быстрее офлайновых запекателей, а то и медленее)
офлайновые запекатели умеют всякие хитрости делать, вроде адаптивности, или ноизом раскидать семплы а потом интерполировать, в упомянутом же случае мы просто херачим регулярной сеткой.
плюс надо учитывать всякие швы на развертке и. т. п... это куда больший гемор, чем кажется.

Samodelkin · 18.05.2014, 00:36

Сообщение от Mr_F_

это годная тема, но:
- стоит дважды (а лучше и ещё несколько раз) подумать, прежде, чем приступать к этому, т.к. реализация непростая, и лайтмапы запечь тупо и быстрее и качественнее может выйти. нужно точно понять, насколько тебе нужно действительно динамическое ги.
- тени от индиректа добавляют нехилой нагрузки - насколько я помню, в релизе крайзиса 2 они отключены, а без них индирект светит сквозь всё.
- всего 4 РГБ коэфициента сферических гармоник юзают крайтеки - это маловато для точного описания дифуза - получается менее выраженная направленность отражённого света, он более со всех сторон лезёт. печь 9 ргб коэфов - непрактично.

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

Сообщение от Mr_F_

дак тут тупо чуваки рендерят радиосити игровым рендером - из каждой точки лайтмапа камеры ставят и фигак.
вариант весёлый конечно, и я так пробовал: http://ndotl.files.wordpress.com/201...5-13-04-37.jpg
но работало оно не быстрее офлайновых запекателей, а то и медленее)
офлайновые запекатели умеют всякие хитрости делать, вроде адаптивности, или ноизом раскидать семплы а потом интерполировать, в упомянутом же случае мы просто херачим регулярной сеткой.
плюс надо учитывать всякие швы на развертке и. т. п... это куда больший гемор, чем кажется.

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

Вообще это проект Джоната Блоу, который всем известный Braid сделал.
Мне больше их дизайн нравится нежели программирование, но они подробно всё расписывают, что радует.

Mr_F_ · 18.05.2014, 01:25

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

повторюсь, это лайтмапы. такие же можно запечь и Beastом и чем-то ещё. они просто выбрали особо черезжопный способ их рендера с помощью игрового рендера.

Samodelkin · 18.05.2014, 01:54

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

Mr_F_ · 18.05.2014, 02:11

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

mr.DIMAS · 18.05.2014, 12:09

Решил запилить мягкие частицы так как после дефереда есть текстура с данными о глубине. И вот тут затык: как в пиксельном шейдере отрисовки частиц получить координаты текущего фрагмента для выборки из карты глубины? Ведь в D3D9 нет SV_Position - пищаль

Ах, да. Я знаю про семантику VPOS, но мне нужно уложиться в ps_2_0

Mr_F_ · 18.05.2014, 13:30

Ах, да. Я знаю про семантику VPOS, но мне нужно уложиться в ps_2_0

VPOS норм, зачем тебе 2_0? о_0

в любом случае, не забывай, что то, что ты выводишь из вертексного шейдера в POSITION - это не что иное, как позиция точки на экране в диапазоне [-1, 1].
Так что ты легко получаешь экранные текскоорды из них:
ScreenSpaceUV = OUT.Position.xy*0.5+0.5;

-----
также, смещение на пол-пикселя не забудь: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

mr.DIMAS · 18.05.2014, 18:19

Сделал. Не уверен что самым лучшим образом, но оно работает.

Вот код:
http://pastebin.com/CKABUej7

Скриншоты - обычные частицы и мягкие.

Mr_F_ · 18.05.2014, 18:33

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

mr.DIMAS · 18.05.2014, 20:54

объясните мне пожалуйста: почему, если не запаковать нормали в отрезок [0;1]( при записи в текстуру ) и не распаковать их впоследствии( второй проход ), свет считается отстойно? это как-то связано с тем что мы пишем в D3DFMT_A8B8G8R8 где на каждую компоненту приходится по 1 байту?

Mr_F_ · 18.05.2014, 22:20

если не запаковать нормали в отрезок [0;1]

и не распаковать их впоследствии

потому что ты тупо выбрасываешь все значения < 0?
в ргба8 хранится по байту на канал (0-255) (в шейдерах выглядит как флоаты 0-1)

mr.DIMAS · 18.05.2014, 23:28

тоесть в подобных форматах хранится беззнаковое целое? Всегда думал что со знаком хранится.

и еще - тени ( шадоумапы ) рисовать отдельным проходом получается( тест трафарета мешает использовать в одном проходе)? использовать значения глубины для сравнения с глубиной шадоумапы из г-буфера?

Samodelkin · 18.05.2014, 23:36

Сообщение от mr.DIMAS

тоесть в подобных форматах хранится беззнаковое целое? Всегда думал что со знаком хранится.

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
Там внизу расписано по категориям signed, unsigned и ieee (то бишь float) форматы.

Например аналог D3DFMT_A8R8G8B8 со знаком будет D3DFMT_Q8W8V8U8.
Однако не все из них поддерживает устройство - нужно проверять.