Только для теней, всех что есть в игре. И всего одна эта текстура создает все тени (тут нужно отдать должное отложенному рендеру). Только они туда не все сразу записываются, а по очереди, под сотню раз разных теней за кадр (в зависимости от кол-ва источников света и их типа + тени от солнца).

На сколько сложно реализовать на р1 под динамическими объектами (шкаф, стул...) декали, имитирующие тени, как в старых играх, типа Макса Пэйна или автосимуляторов?
Нюанс таких декалей в том, что чем дальше объект от поверхности, тем они прозрачнее, и например на расстоянии в пол метра, полностью исчезают.
Были и такий которые повторяли и изменяли форму объекта, как тень от "солнца" в зените.

Хватит насиловать труп, закопай обратно. Проще уж р2а пилить если хочется запеченных теней и освещения.

Лолшто? Можно скрины с примерами?

Скорее всего имелись ввиду shadow blob

В настройках игр на разных движках, это называлось именно "decals" и на русский переводилось, как "тени".
Хорошая замена невозможной (невозможной ли?) на р1 SSAO, HBAO и так далее.
Декали даже были в ранних билдах, правда только под неписями и ГГ.

Это я должен спрашивать.
Твой вопрос из разряда "есть ли жизнь за мкадом".
Не знать одну из самых распространённых фишек игростроя, даже со стороны простого игрока, это надо суметь!

Это вопрос из разряда "сержи на форуме опять спросил какую-то херь, попробуй расшифруй"
RT

Возможно. Токма без накладывания его на траву и листву, а иначе дикий филрейт будет из-за связки альфа-тест + форвард p1.

http://xray-oxygen.org/index.php/Константы

Оффтоп или нет, решайте сами.

Начал немного документацию шейдеров. Начал с констант. Если есть у кого желание подсобить, то редактирование/добавление страниц доступно после регистрации.

cjayho, топикбан за флуд

Тут занимался отложенным рендером и кое-что оптимизировал. Может кому пригодится. Сам g-buffer. В сталке он слишком жирный, особенно в ТЧ. Для диффуза 8 бит на канал, а для нормали и для позиции по 16 бит. Это жесть.
Начнем с того, что нормаль можно тоже в 8 битах хранить (16 для нее не нужно), этим мы выиграем 10% фпс. Только нужно при упаковке в g-buffer нормаль перевести в 0...1 (она там сразу в -1...1 кодируется), а при распаковке обратно в -1...1.
Теперь насчет позиции. Достаточно иметь только глубину, которую вообще можно получить из буфера глубины (на дх10/11 запросто, но и на дх9 тоже возможно), а позицию xy во view space восстановить из z. Кстати, в ЗП так и происходит, если g_buff_opt включить. Правда, там все равно z в g-buffer пишется в 16 бит, а можно и не писать. И еще при этом можно убрать из вершинных шейдеров умножение на матрицу для позиции, т.е. вырезать (+1% фпс). И как еще один бонус, у нас будет более точная 32 бит глубина, а не 16 бит.
Наконец, нормаль тоже можно упаковать в xy. Если правильно это делать, косяков с освещением не будет (в ЗП с g_buff_opt она кодируется).
В общем, я у себя до +50% выигрыша перфоманса получил (тут еще от железа зависит), загнав все в две DXGI_FORMAT_R8G8B8A8_UNORM поверхности, т.е. всего 64 бит (было 160 бит).

Добавлю. Если будем жать нормаль, лучше использовать формат DXGI_FORMAT_R10G10B10A2_UNORM, иначе возможны слабые артефакты на бампе. С 10 бит артефактов нет - проверено и поставлен знак качества. И снижения фпс нет.
В этом случае пишем материал в альфу: для 4 материалов в игре как раз 2 бита. А хеми в B канал (можно туда что-нибудь еще закодить).

Данные сталкерских материалов разве не интерполированы? Для материалов этого мало будет, получится лишь хранить его id, но не weight, который отвечает за переход от одного материала к другому. Ну а так, в целом, правильно в таком формате хранить нормаль. Просто для этого надо грамотно распределить остальные данные GBuffer'а.

В АЕ имеется выбор из четырех материалов. В шейдер из них передаются значения: 0.0625, 0.3125, 0.5625, 0.8125. В 2-бит текстуре значения будут чуть отличаться, но их можно подкорректировать к этим значениям. А вес - это да, я не учел. Но его можно кодить в хеми (раз все равно стало 10 бит), а в шейдер его вывести отдельно в L_material (там все равно xyz не используются).

Небольшое исправление отражение неба в воде (R2)
В gamedata\shaders\r2\water.ps перед строкой:
Написать:

А что оно делает и что правит? Судя по коду, ранее в векторе отражения использовалось приведение Y к -1...+1, а теперь стала выбираться наибольшая из сторон. Скрин бы не помешал, посмотреть отличия отражения неба. Интересно глянуть.

Вечером выложу.

Вот скриншоты:


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

На небе у тебя какая-то рожа злая. Хорошая правка, исправляющее кривое отражение неба. Надо забирать! Да и ресурсов там всего-то с гулькин нос...
Еще бы убрать отражение скайбокса в воде под крышей.

?

Ну, ты стоишь под крышей, а в воде у тебя отражается небо

На болотах внутри церкви вода, в ней отражается небо, а над водой имеется крыша. Откуда в воде небо?


Это просто мысли вслух.

Zagolski, а при чем тутxrModder.
Беги к KD за помощью.

Тут простая правка шейдера не поможет

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

Если вода всего уровня представлена единым объектом, то не выйдет. Надо будет кусок в церкви вырезать в каком-нибудь 3D-редакторе как отдельный объект (для назначения отдельного шейдера). Либо считерив наложить поверх воды в церкви отдельную плоскость (с отдельным шейдером) чуть выше уровня общей воды, а для надежности между ними проложить еще черную плоскость. А потом перекомпиляция...

а еще можно сделать фековую геометрию, как на болотах 1935

Тут сейчас бленды на XML переписывал, как раз с водными шейдаками запаривался. Почему бы просто не убрать s_env0/1?

А еще замутить сразу же parallax corrected cubemap, чтобы смещения камеры отображать. Кароче способ какой-то геморный

Если бы я был пыс, я бы просто убрал воду из церкви да и всё.

Вариант с env probes (с коррекцией) - самый вменяемый и не затратный, имхо.
Можно в один проход с SSLR + заодно будет для металов (cmft сворачивать в мипы и будет красиво).

Вы это на дх9 замутите, тогда будет круто)

В некоторых шейдерах есть комментарии 1 (0) - full_env и 0 (1) - no_env - может это и есть настройки полного отражения игрового мира в воде?

Наверное, будет правильнее проверять, находится ли вода под небом или под потолком, а в шейдере воды сделать условие, считывать ли кубамапу неба или другую кубомапу типа потолка (или вообще не учитывать).
Тут на ум приходит несколько вариантов. Поможет карта высоты. Это как бы то же самое, что и буфер глубины, только снята сверху, как сделана в ЧН/ЗП карта дождя (можно и ее юзать). Но это потеря фпс, потому как карту придется рендерить каждый кадр (хотя можно и не каждый).
Либо попробовать считывать данные из маски террейна (там вода под небом отмечена другим цветом).
Еще как вариант попробовать читать данные из лайтмапов, хеми для помещений. Если затемнено, значит помещение и кубамапу не учитывать.
А можно в движке пускать луч в небо (например, с позиции камеры) и выявлять препятствие, а затем отправлять в шейдер константу, есть ли крыша или нет.
Нужно опробовать эти варианты и выбрать наиболее грамотный.

Интересно, почему разработчики не реализовали полное отражение игрового мира в R2, емнип Direct3D 9 вроде как поддерживает full reflection.

xrModder, я прям не напрягаясь (в течении полу года ломал голову как это работает) в R2 шейдеры ОГСЕ внедрил, ну и в R3 тоже.

Или full reflection - это не то?

DX9 NeoAxis - отражения так же камерой сделаны.

Зачем?

Потому что речь изначально шла о стк ТЧ, а в нём максимум дх9

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

А что если на первых кадрах рассчитать глобальное освещение для всей локации? Тогда по идее, можно будет избавиться вообще от статики и лайтмапов, заодно получить нормальные затенения в помещениях. Пересчитывать там вряд ли что-то нужно, ведь почти вся геометрия статична.

А чем это в контексте будет отличаться от запекаемых лайтмапов или запекаемого GI?

Тем что не надо будет по 20 часов конпелировать локации и терять в производительности динамического GI.

RayTwitty, мы думали использовать результаты adaptive ht для получение первого лайтмапа, который юзается в шейдерах. Только руки так и не дошли.

Какой шейдер в ОГСЕ выводит отражения на асфальте (при намокании)?
Вода у меня отражается, а вот грунты чего то не хотят.

================================================================================



Прям 20 часов - это много? 240 часов - это много.
Если поменять default настройки материала, на def_shaders\def_vertex - то лайтмапов не будет. А нафига на всей локации лайтмапы?

Судя по исходникам в файле level шейдеры хранятся так:
default/prop\prop_mus_kont_01a,lmap#3_1,lmap#3_2
'\' - разделитель
'prop_mus_kont_01a,lmap#3_1,lmap#3_2' - лист текстур
'default/prop' - должен быть шейдер, но его не в библиотеке(shaders.xr) нет и не в shaders/[r1|r2]/*.s
Вопрос такой - что это за ерунда и как так получилось?

buffy, default - имя шейдера, prop\prop_mus_kont_01a,lmap#3_1,lmap#3_2 - три текстуры для этого шейдера.

возможно это шейдер default - который куда то в движок ныряет. У меня визуалки сейчас нет, посмотреть не могу.

Спасибо, что закрыл предыдущую страницу. Теперь я хрен дождусь ответа.


Повтор:

Какой шейдер в ОГСЕ выводит отражения на асфальте (при намокании)?

Круто, но как?


АА, стоп '\' =/= '/'

Ну вот кто так разделяет?



Скай, пока не ушёл, тут ещё вопрос возник:

lmap* это простая развертка всей статичной геометрии? Если так, то как её элементы сортируется? Т.е. в какой зависимости lmap*_1 приобретает индекс. До последнего времени думал, что по материалам в сцене, а не по площади


ЗЫ: сорян за сумбурный вопрос)

buffy, в распаке моделей конвертером Бардака, видна последовательность геометрии - там строчность на лицо.

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

А что мешает делать? Это не запрещено, если у тебя один рендер. Вот на dx9 будет не так не работать.

Дизель,
хорошо, попробую это сделать. Не помню уже причин, но что-то мне подсказывает, что где-то заковырка. Иначе давно ввели эту схему.
Одна текстура деталей для многих моделей и с десяток различных расцветок, но маленьких бесшовных текстур для умножения их на основную. Есть основная 2К, значит 64*(256х256). И эти 64х будут считать в памяти, как 1х. Я не придумываю "ноу-хау", все это уже есть, когда "ходил под стол пешком".
Статика мне даром не нужна без параллакса и бампов.