Шейдеры

[macron 1 823]

SOC_reshade_mini_v23 - в общем, сборка reshade-эффектов, адаптированная под stalker (в теории может работать и с другими играми). Разрабатывалась под конкретный проект, на разных модах может выглядеть по разному и требовать дополнительной настройки.

 

https://disk.yandex.ru/d/ox5eEJKBvUQw1g

Изменено 25 Августа 2021 пользователем macron

[змей13 9]

Ребят, есть у кого-нибудь шейдеры дшя динамичес4их марок коллиматоров для Зов Припяти?

[Lagrange 0]

Значит, вопрос такой, есть ли у кого - нибудь готовый PBR типа metall/roughness для сталкача, желательно ЗП, но, на крайний, можно и ЧН. На обычное предоставление не рассчитываю, так что могу договориться за плату, в разумных пределах, конечно, не 150$(~11000 рублей) как Lvutner. У самого пока знаний не хватает для такой работы, так что решил обратиться. 

[FozeSt 1]

@Lagrange https://github.com/Xerxes1138/X-Ray-PBR бесплатно без регистрации и смс. Но на ТЧ и dx9

[_ХоЗаР_ 47]

02.09.2021 в 14:09, Lagrange сказал:

metall/roughness

 

13 часов назад, FozeSt сказал:

Xerxes1138

Если правильно помню у ксеркса спекглосс, но при желании переписать возможно.

[Cornholio 58]

02.09.2021 в 12:09, Lagrange сказал:

Значит, вопрос такой, есть ли у кого - нибудь готовый PBR типа metall/roughness для сталкача, желательно ЗП, но, на крайний, можно и ЧН. На обычное предоставление не рассчитываю, так что могу договориться за плату, в разумных пределах, конечно, не 150$(~11000 рублей) как Lvutner. У самого пока знаний не хватает для такой работы, так что решил обратиться. 

 

к сожалению это немного расплывчатая формулировка.

В рендере ЗП в общем-то есть система материалов и некое приближение к физическому отображению свойств света на них - считай уже готово)))

 

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

 

Готового пакета у меня нет, к сожалению. А самое плохое - что для честного PBR надо перерисовывать все текстуры и менять некоторые моменты связанные с кол-вом "технических" текстур.

 

Так-то все формулы для приближения к PBR есть в открытом доступе - читай статьи или просто выдирай код из Unreal, Unity, Filament

Изменено 4 Сентября 2021 пользователем Cornholio

[_ХоЗаР_ 47]

05.09.2021 в 04:47, Cornholio сказал:

А самое плохое - что для честного PBR надо перерисовывать все текстуры

Честный PBR на пыс текстуры не нужен. Первое время глоссы можно использывать для расчета шероховатости. Для упаковки всех BW карт хватает и двух пыс текстур технических. Карты самосвечения и SSS используются, как правило, не так часто, и не в каждом движке вообще. С некоторыми упущениями правка рендера заключается лишь в передаче цвета (color) в шейдры освещения, и замену типа фильтрации у текстур окружения для просчета IBL (иначе не будет доступа к мип уровням (Для префильтрации можно использывать разные тулзы, я использую модификацию программы от АМД (CubeMapGen вроде)).

 

05.09.2021 в 04:47, Cornholio сказал:

выдирай код из Unreal, Unity, Filament

Ну или еще проще - просто взять и стянуть все с условного репо на гитхабе, там много реализаций PBS. Многие сделаны на статье от Learn OGL. (Самое главное при реализации IBL на рентгене - не забывать учитывать затенение от окружения (У GSC в GBuffer`e оно называется hemi), ну или реализовывать систему проб отражений (что тоже не сложно, на базовом уровне).

 

05.09.2021 в 04:47, Cornholio сказал:

некое приближение к физическому отображению свойств света

Да. Рекомендую почитать статейку Олеся о реализации рендера сталкера. Там есть несколько полезная информация.

[Cornholio 58]

вопрос

 

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

 

чисто, чтобы поиметь линейную глубину, вместо z/w ?

 

И опять же вопрос - насколько затратны эти render target?

 

Просто сжатые данные gbuffer это конечно здорово, но у меня подозрение, что запаковка и последующая распаковка в каждом пассе постпроцесса съедают больше производительности видеокарты.

 

если предположить, что для gbuffer использовать 3 64битных полноэкранных текстуры, то для fullHD это всего около 48Мбайт памяти на кадр. А вот перекодировать нормали каждый раз (особенно если хочется рейтрейсеры для АО/SSR/GI/FOG) занимает уже заметное кол-во операций на кадр.

 

Я не программист, я так - любитель, но вдруг кто-то разбирается - вчем подвох?

@_ХоЗаР_ вдруг знаешь ^

[_ХоЗаР_ 47]

@Cornholio Оптимизация GBufer`a делалась после переезда на DX10 (Вполне вероятно что разработчики забили на существование Z-buffera) Оптимизация проводится исходя из того что записать 2 RT намного проще (По производительности), чем 3 RT. Декодирование нормалей, применяемое ПЫС не ест много инструкций, и по факту оказывается дешевле чем просто загрузка еще одной текстуры (Но тут точно не скажу, ибо на встройке это действительно так у меня и было, но вот на видеокарте я разницы практически то и не чувствую). Вообще вопрос хороший. В свое время товарищ @Zagolski писал (Возможно это было не на АМК) что более производительной является распаковка позиции из Z-buffer`a. У него знаний, наверняка, побольше чем у меня.

12 часов назад, Cornholio сказал:

Я не программист

У меня все так же

[Cornholio 58]

@_ХоЗаР_ 

я, пожалуй верну "толстый gbuffer" заодно появится место под roughness ну и другие свойства материала (может даже светимость, чем чорт не шутит, места-то вагон теперь)

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

[_ХоЗаР_ 47]

13 часов назад, Cornholio сказал:

толстый gbuffer

Ну толстый Gbuffer тоже можно эффективно использовать. Рекомендую вот какую статейку про низкоуровневую оптимизацию шейдров под GCN. Может быть полезно в будущем.

[Cornholio 58]

портировал в аномаль GTAO ( по этой статье https://www.activision.com/cdn/research/Practical_Real_Time_Strategies_for_Accurate_Indirect_Occlusion_NEW VERSION_COLOR.pdf)

без АО (вообще без какого-либо)

 

GTAO

 

пока много багов, надо убрать гало, следы и добавить оптимизации (хотя уже при 16 семплах выполняется за 4-5мс в 1080р на видеокарте 1060)

[Cornholio 58]

 

ранний прототип screen space global illumination, пока сделан отдельно на основе GTAO, в планах попробовать его перенести в xray

[Ghilli 0]

Здравствуйте. Есть ли пример дин.коллиматоров на ЗП, сделанных без правки двигла? Где-то на предыдущих страницах видел совет в аномалиевском шейдере просто заменить "screen_res" на "pos_decompression_params", но, что более всего вероятно, я что-то сделал не так, либо самой игре такой метод не нравится, но оно не робит

Как upd к предыдущему посту: сейчас, ковыряясь в шейдерах оригинала, обнаружил шейдер hud_crosshair, в котором как раз и задействуются строки screen_res.x/y. Теперь неясно, почему при чистом переносе шейдера из аномальки - ЗП вылетает, жалуясь на этот параметр. 

Как upd к предыдущему посту: 

Все. Вылет исправлен. Надо в шейдере было дописать сверху float4 screen_res 

Изменено 3 Января 2022 пользователем Ghilli

[Cornholio 58]

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

@Ghilli 

[Ghilli 0]

@Cornholio хм, спасибо. Не знал,ибо в шейдерах - нуб полный.

 

Заодно вопросец у меня, касаемо эффекта паралакса в 3d линзах оптики. Как я понимаю - основа там та же, что и в коллиматоре, следующим за центром экрана? 

Но отрисовка темных "лун" в прицеле мне вовсе не ясна. Может, есть какие-то шейдеры с похожим механизмом действия, в которых можно код посмотреть? 

[Cornholio 58]

@Ghilli  не знаю - это скорее вопрос к автору мода. Если б мне надо было делать прицелы - я бы сделал иначе (имхо темные луны плохо для восприятия игрока) лучше всего копировать подход армы, старых call of duty и battlefield - там куча бывалых дизайнеров не просто так пришли к тому виду прицелов, что мы видим в их играх (уверен есть даже презентации и методички по этому процессу в интернете)

 

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

Изменено 5 Января 2022 пользователем Cornholio

[Ghilli 0]

1 час назад, Cornholio сказал:

 

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

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

 

В видео от I. W. P., в которых они демонстрировали снайперское оружие, был виден этот эффект лун. Я пытался реализовать залунение, используя шейдер models_lfo_light_dot_weapons из аномали, но получилось вовсе не то. Поковырял shader based 2d scopes для той же аномали, но там используются правки двигла. Вот и ищу шейдер, похожий по действию на то, что внутри объекта "отрисовывается" что-либо

[Cornholio 58]

@Ghilli к сожалению я не могу подсказать

[Cornholio 58]

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

 

Вот как выглядит "быстрое"

время на исполнение, в профайлере renderDoc:

 

Вот так выглядит идеал (не очень пригодно для игры в реальном времени, но все равно возможно - время на исполнение порядка 9мс)

 

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

 

Еще есть пути для оптимизации, т.е я ожидаю, что спустя какое время мы сможем за 1мс выдавать еще лучшее качество (ну или ускорить его еще раза в 2)

на скрине с счетчиками профайлера - время в милисекундах, а цена на исполнение всего алгоритма находится в строке AmbientOcclusion, он имеет 3 пасса: сам АО и 2 прохода фильтром (просто случайно забыл выделение снять со второго пасса фильтра)

 

Изменено 25 Января 2022 пользователем Cornholio