Графика, рендер, шейдеры Опции

[=Diablo=]

Разбор полётов

SSLR & Puddles | Lens Flares | Отложенный рендер ландшафта | Исправление паковки gbuffer'a | Шейдерные константы (Кто допилит - с меня печенька)

Работы участников

Шейдеры от Diablo

Шейдеры из билда 2232 под финалку.
До

После


Скачать

Наработки cjayho

ECB Shaderpack
Официальный репозиторий

Описание

ECB-Shaderpack
Улучшенный набор шейдеров для игры S.T.A.L.K.E.R.: Shadow of Chernobyl
_____________________________________________________________________________
Основные возможности:
_______________________
1) Непрозрачный туман на R2, возможность переключения
из файла конфигурации прозрачный/непрозрачный туман
2) Исправлена "синюшность" изображения на R2
3) Эффект компенсационного светового следа на R2
4) Статический и динамический Depth of field на R2,
Размытие объектов при прицеливании (требует дополнительного скрипта)
5) Билдовский блум с краснинкой на R2, возможность
переключения тонмаппинга в режим, который был в билде 2218
6) Screen space ambient occlusion на R2
7) Правильная отрисовка сияния ламп на R1
8) Правильная отрисовка солнечного градиента на обоих рендерах
9) Полноценная отрисовка occlusion-lightmaps на R2
10) Микроструктурный бамп
11) Правильная отрисовка бликов на блестящих поверхностях
12) Автосатурация - попиксельное уменьшение насышенности слабо
освещенных объектов
13) Мягкие тени на R2
14) Экспериментальная возможность - правильные тени от деревьев на R2
15) Улучшенный Motion blur, более похожий на билдовский
16) Исправлена "кислотность" (перенасыщенность) солнечного освещения объектов на R2
17) Отражабельная вода на R2
18) GodRays на R2 + эффект пылинок в лучах.
19) Мягкие партиклы на R2
20) Мягкая вода на R2

Плюс множество регулировок и исправлений мелких недостатков обоих рендеров
Условия использования
_______________________
Данный продукт предоставляется под соглашением Creative Commons CC-BY 3.0,
Подробнее описано по адресу http://creativecommons.org/licenses/by/3.0/deed.ru
Составитель данного набора шейдеров - cjayho
Свежие ревизии находятся по адресу http://code.google.com/p/ecb-shaderpack/downloads/list
Установка
___________
Данный продукт тестировался под версиями игры 1.0004 и 1.0006
Установка сводится к копированию файлов в папку gamedata мода,
изначальный набор файлов предназначается для чистой игры. В случае
установки погодных модов необходимо правильно совместить файл
config/weathers/flares.ltx

Для более полной настройки шейдеров R2 под свой мод можно править файл
shaders/r2/config.h.
Для корректной работы теней нужно установить следующие переменные
в игровой консоли:

r2_sun_near_border 1
r2_sun_near 20

Благодарности
_______________

Sergy172 за идеи и тестирование экспериментальных веток.
-=Diablo=- за изначально портированные шейдеры из 2232
macron за отражабельную воду и наборы шейдеров из билдов 2217 и 2588
Билдоман за набор шейдеров из билда 2571
BAC9-FLCL, KamikaZZe за дельные замечания и критику
Shadows за неоценимую помощь в разработке и тестирование экспериментальных версий
Meltac <metzinger@gmx.net> (Его мод "Dynamic shaders" здесь: http://www.moddb.com/mods/dynamic-shaders)
за алгоритм Depth of Field. Код DoF используется с его разрешения.
Sky4CE за алгоритм SSAO
K.D. За алгоритмы мягкой воды, мягких партиклов, GodRays

Скриншоты

Скриншоты (Shadows Addon 0.6 Edition)

Скачать все наработки | Зеркало
Наработки ECB Team распространяются под условиями Creative Commons CC-BY.

Правки рендера от K.D.

Подходит как к чистой игре, так и к любым модам.

Изменения

- саншафты (команда r2_sun_shafts off/low/medium/high)
- мягкая вода (команда r2_soft_water on/off)
- мягкие партиклы (команда r2_soft_particles on/off)
- регулировка дальности отрисовки травы через консоль (r__detail_radius [49, 501])
- расширенная регулировка плотности травы (r__detail_density [0.02, 0.6])
- расширенная регулировка четкости текстур (r1_tf_mipbias/r2_tf_mipbias [-3.0, 3.0], только R1/R2)
- расширенная регулировка расстояния переключения на лоды (r__geometry_lod [0.1, 3.0])
- восстановлены тени от травы (r2_sun_details, R2)
- восстановлены блудмарки (r2_bloodmarks, R1/R2)
- правильные тени от солнца (R2)
- увеличенный видеобуфер (фикс ошибки "(bytes_need<=mSize) && vl_Count" на R2, связанной с перегрузками видеобуфера*)

* То есть теперь можно на полной динамике загрузить ресурсоёмкую карту типа болота из ЧН, поставить видимость в 4 километра и взрывать вокруг дымовые гранаты с ЧНовскими партиклами дыма (тоже жутко ресурсоёмкие).

Скриншоты

Мягкие партиклы (до и после)

Установка: закинуть содержимое в папку с установленным ТЧ (6 патч, более ранние патчи не поддерживаются и просить сделать под них аналогичное бессмысленно!)
Настройка: смотрите ogse_config.h
Нюансы:
- мягкая вода работает и без бинарников
- экзешник нужен для пыли в саншафтах и правки вылета перегрузки видеобуфера. Он основан на выложенным в свое время официальном экзешнике для 6го патча без защиты (отсутвие starforce).
- рендер-библиотека обеспечивает работу консольных команд, пыли в саншафтах и мягких партиклов.
Использование: где и как угодно. Не возбраняется указать автора.

Скачать
Часть наработок еще здесь

Сообщение отредактировал ForserX - 21.07.2020, 13:58

[ed_rez]

Надо делать бамп так, как сделан остальной сталкерский бамп, чтобы не было расхождений.

Золотые слова. А теперь глянь бамп НПС группировки ЧН и тут же бамп нейтралов. Я это поправил для проекта Дизеля, не забивая голову шейдерами, рендерами и фиг его знает еще чем. Я так понял, что это пытались исправить движково или как-то иначе, никак не на текстурном уровне. Удивлен. Примерно такое же удивление я внес, когда начал писать про простейшее решение на уровне граф. редактора.

Или спекуляр не будет правильно читаться. СДК как надо делает.

Спекуляр вообще ни при делах, когда происходит считывание нормали из бампа. Он считывается также отдельно от нормали. И тем более, СДК ничего не исправляет. Что закинул, то и вылетит в результате. Если правильная нормаль скормлена СДК + спекуляр, то СДК соберет бамп правильно. СДК в данном случае, автоматизация ручного труда, т.к. это обычная замена каналов + вносится какой-то код, чтобы игра понимала, что это бамп. В редакторе этого с 0 не сделаешь. Можно также брать любой бамп СДК и править до посинения каналы и бамп будет рабочим в игре, т.к. в этом файле есть какой-о код от СДК. Еще раз, чтобы не приводить к сарказму. Пишу на уровне любителя, как сам пришел к некоторым выводам.

ed_rez имел в виду диффуз - текстуру

Именно так. Приходится извращаться в словах. Слово текстура относится к очень многому- нормали, спекуляры, карты-высот и на результате текстуры бамп. Не серчайте, моему русскому не так много лет. Выучен с 0.

Это все верно с точки зрения 3Д-программера.
С точки зрения 3Д-артиста все выглядит ровно так, как пишет ed_rez. Для разных движков надо нажать разные кнопки "директх"/"опенгл" или поменять каналы местами или еще какой фильтр наложить. Даже не знаю, что с ed_rez`ом начали спорить.

Премного благодарен.
***
Но тут же вопрос. Хотя опять сарказм польется рекой. Как умею написать, так и напишу.
Почему на ИксРее нормаль переумножается в 2 раза и кто-нибудь решал этот вопрос на движковом уровне?
Объясняю свое недовольство. Нормаль делается, как для любой игры, лишь как выше написал про координаты. В Сталкере эти нормали очень насыщено выглядят, визуально оценивая своим глазом, высоты у нормали удваиваются. Это очень неудобно. Для ИксРея свои нормали, для других дел иные.

Сообщение отредактировал ed_rez - 06.11.2019, 18:44

[Modera]

Я думаю вот из за этого, но это не точно.

S.normal.z *= 0.5; //. make bump twice as contrast (fake, remove me if possible)

[Zagolski]

Спекуляр вообще ни при делах, когда происходит считывание нормали из бампа. Он считывается также отдельно от нормали. И тем более, СДК ничего не исправляет. Что закинул, то и вылетит в результате.

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

Почему на ИксРее нормаль переумножается в 2 раза и кто-нибудь решал этот вопрос на движковом уровне?

Для более выпуклого бампа. Да, из-за S.normal.z *= 0.5 в шейдере. Если это убрать, нормали базово будут смотреться. Но как по мне, более выпуклые красивее выглядят.

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

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

К фактам полагаются пруфы

Пруф выше на картинке от ed_rez, с кнопками для бампов. Для DirectX - левосторонняя, для OpenGL - правосторонняя. Соответственно разные Z по направлениям, на одной бамп выпуклый, на другой вогнутый на выходе получается. Тот кто писал эту программу, руководствовался именно такими системами координат. Ну а уж писал ее наверное не дурак.

Сообщение отредактировал Zagolski - 06.11.2019, 19:22

[ed_rez]

Modera,
хорошо, очень хорошо. Значит проблема вполне решаема. Благодарю!
***
Из-за насыщенности бампа, получается такая сверхмощная детализация:

Размер граф. информации в соотношении размера той или иной части модели, которая подхватывает ее, приводил к соотношению 1:1. Может местами слегка больше, чтобы заполнить маленькую пустоту на полотне текстуры.
Тут еще один вопрос. Я своим умом понимаю так. Чем насыщеннее нормаль, тем больше просчетов идет в движке. Я правильно мыслю?

[abramcumner]

Ну так это проблемы движков, а не GAPI. И я не спорю, а лишь уточняю, чтоб не плодились мифы далее.

Не-не, GAPI ты сам приплел и сам разоблачил миф. Изначально это были названия кнопок в редакторе. И наверное эти названия как-то помогают ориентироваться художникам, какую кнопку жать.

[ed_rez]

Если ты спекуляр не в тот канал положишь

Разговор идет о том, когда все сделано правильно.

[abramcumner]

Пруф выше на картинке от ed_rez, с кнопками для бампов. Для DirectX - левосторонняя, для OpenGL - правосторонняя. Соответственно разные Z по направлениям, на одной бамп выпуклый, на другой вогнутый на выходе получается. Тот кто писал эту программу, руководствовался именно такими системами координат. Ну а уж писал ее наверное не дурак.

Особенно прикольно когда это спрашивает Modera, у которого в редакторе на опенгл зеркалились директиксовские локации из метро. Стандарта нет, ага

[ed_rez]

Но как по мне, более выпуклые красивее выглядят.

Там, где нужно. А в реале все должно работать так, как оно сделано исходя из хай-поли моделей и запекания нормалей к лоу-поли. Перенасыщение не есть правдивая передача визуальной информации.
Изучая бампы ПЫС, мне то понятно зачем так было сделано. Ошибочно держаться за этот "костыль" нам далее.

привык альбедо эту текстуру называть

Неправильно привык. В Сталкере никак не могли они появится. Они позже появились, т.к. технология совсем другая. Кардинально другая. Про "позже" я со своих изучений игр взял. Албедо в играх увидел значительно позже Сталкера.

наверное эти названия как-то помогают ориентироваться художникам, какую кнопку жать.

Можно и иначе сделать, как я выше писал: Y- и Y+. И мне все будет ясно.

[Modera]

Особенно прикольно когда это спрашивает Modera, у которого в редакторе на опенгл зеркалились директиксовские локации из метро. Стандарта нет, ага

Ну ты объясни, почему метродвиг как и сталкеровский и многие другие используют именно леворучную систему? Ведь в директикс даже если ты ламер в математике и не умеешь строить матрицу можно использовать D3DXMatrixPerspectiveFovRH. Причём в седьмой версии праворучные функции были без суффикса RH, а леворучные уже с суффиксом, что как-бы намекает. А в OpenGL стандартной фукнкции для создания леворучной матрицы нет. Или все DirectX разработчики как один копипастят код из примеров где используется леворучная система и это потом закрепляется в виде привычки?

[Zagolski]

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

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

А может сами текстуры бампа более сглаженные по нормали сделаны? А в шейдере увеличивая их крутизну просто приводится все к нормальному виду? В общем, я бы не стал убирать эту *= 0.5, сам я предпочитаю крутой бамп и сильный параллакс. Но тут на любителя, кто-то вообще любит без бампов.

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

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

Сообщение отредактировал Zagolski - 06.11.2019, 20:29

[abramcumner]

Ну ты объясни, почему метродвиг как и сталкеровский и многие другие используют именно леворучную систему?

Потому что есть исторически сложившийся, общепринятый стандарт. Может из-за книжек и примеров, где были левосторонние системы. Может из-за 2Д, которая левосторонняя.

Но интересней другой вопрос. Если стандарта нет, значит разрабочик перед каждым проектом выбирает, какую систему координат ему использовать. В случае редактора логичней использовать систему из метро, чтобы все потом не зеркалить. Однако, нет.
Получается, стандарт все-таки есть по крайней мере в опенгл.

У нас тут есть настоящий 3д-разработчик(iOrange). Вот пусть и расскажет, какую систему координат использует и почему. А то все на Кормака кивает. Кормак кстати какую систему использует: правосторонню или левостороннюю

Сообщение отредактировал abramcumner - 06.11.2019, 20:45

[Modera]

В случае редактора логичней использовать систему из метро, чтобы все потом не зеркалить. Однако, нет.

С редактором всё просто; из соображений ленивости автора использовалось то что уже готово, а не то что нужно писать самому. В старых версиях даже матрицы умножались через OpenGL, потому что так приходилось писать меньше кода, чем при написании функции умножения матрицы на матрицу.

[Diesel]

Сутки потратил, что бы понять, что СДК гробит бампы.
Бампы из других игр нужно еще и дорабатывать напильником в Фотошопе.

[ed_rez]

снизить крутизну бампа к номиналу текстуры, земля и стены станут плосковатыми.

Ну вот опять полуправда. Ок. Объясняю. Для рельефных задач используется параллакс. В бампе от называется карта-высот. Затем параллакс подключается в СДК к текстуре, создается thm. Либо прописывается в textures.ltx, следующее:
grnd\grnd_dry_gr = bump_mode[use:grnd\grnd_dry_gr_bump], material[1.00], parallax[yes]
Еще раз, глянь нормаль у кирпича ПЫС. А я покажу, как должна выглядеть нормаль от нормального запекания хай-поли модели. Не забывай, что текстуры у ПЫС на основе фото, (!) не моделей хай-поли. Другими словами нормали делали топорными методами. По типу NormalMapFilter в ФШ или CrazyBump.
Тем самым я подвожу к тому, что 2*normal не нужен, если сделать нормаль достойного качества, а уже параллаксом завершить работу большого рельефа.

СДК гробит бампы.

Если ты про пережим в DXT5, то малость есть такое. Но есть бамп#, который ремонтирует все потери сжатия.

Сообщение отредактировал ed_rez - 06.11.2019, 21:52

[Diesel]

ed_rez, да я про dx5. И вообще про само запекание.
Я теперь запекание научился делать в Фотошопе, но правда после запекания в СДК (делаю доводку). Качество 5+

Сообщение отредактировал Дизель - 06.11.2019, 22:04

[ed_rez]

из других игр нужно еще и дорабатывать напильником в Фотошопе.

А как же друг мой. Но почему-то никто не делает этого. Хотя, вру, начали делать в оружейке. Я не смотрел крайнюю оружейку Газика, но знаю, что он собирался переделывать все бампы старых версий. И знаешь почему? Именно по той причине, что нормал*2.
Человек берет нормаль для модели, она есть истина хай-поли модели. А в Сталкере эта нормаль такая гадость. И как-то тут в одной теме, я заикнулся за это. Плавает текстура и все тут. А так как я знаю эту проблему, то сразу на нормаль грешить начал. Если она, как выше normal*2, то освещение, которое перекрывает те же тучи, которые двигаются, начинает влиять на текстуру бампа и та начинает играть высотами. Складывается ощущение сдвига. Так же работает и параллакс. Включил фонарь, как сразу часть текстуры ушло в сторону на том объекте, где есть параллакс, а также попал свет от фонаря.

запекание научился делать в Фотошопе

Я выше писал, как обойти СДК и обмануть игру.

настоящий 3д-разработчик(iOrange)

Тогда ему вопрос. Который затерялся в наших разговорах.
iOrange,
глянь пожалуйста мой вопрос - 37274
Это мне важно понимать.

[iOrange]

Пруф выше на картинке от ed_rez, с кнопками для бампов. Для DirectX - левосторонняя, для OpenGL - правосторонняя

Это просто надписи на кнопках в неизвестной мне программе.
Еще раз - все что позволяет делать OpenGL / Direct3D / Vulkan / Metal / GNM / NVN и куча других GAPI - это возможность тебе загрузить байтики, интерпретировать их как угодно в шейдере, и произвести вычисления.
Как ты их произведешь, что это будут за вычисления, куда у тебя будут смотреть базисные оси - GAPI (и уж тем более GPU) вообще знать не нужно.

Не-не, GAPI ты сам приплел и сам разоблачил миф

??? Выше народ постоянно пишет "нормали в OpenGL другие", не я. Я лишь пытаюсь уговорить не плодить вводящие в заблуждение мифы, а называть вещи своими именами.

Как по мне, левосторонняя правильнее и удобнее. А то что в опенгл наоборот

Ну вот опять, а abramcumner потом пишет что я выдумываю - в OpenGL не может быть "наоборот", он вообще не в курсе про ваши системы координат.

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

Бинго! И я тебе даже расскажу почему выбирают чаще левостороннюю - потому что в учебниках по математике именно она используется.

стандарт все-таки есть по крайней мере в опенгл.

И опять двадцать пать

Вот пусть и расскажет, какую систему координат использует и почему. А то все на Кормака кивает. Кормак кстати какую систему использует: правосторонню или левостороннюю

Использую ту, что уже используется в движке. Если пишу с ноля - то использую левостороннюю, ибо мне проще представлять как Z+ направлен от меня.
На Кармака я не "все кивает", а привел в качестве примера нестандартной системы координат - правосторонняя, но Z и Y поменяны местами. И это он юзал еще во времена FFP, что как бы намекает.


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

Можно и иначе сделать, как я выше писал: Y- и Y+. И мне все будет ясно.

[macron]

grnd\grnd_dry_gr = bump_mode[use:grnd\grnd_dry_gr_bump], material[1.00], parallax[yes]

А этот параметр , parallax[yes] в ванильном ТЧ точно работает? Ибо никогда раньше в textures.ltx не было.

[ed_rez]

Дизель,
пробуй обмануть игру. Сохраняй dds с сжатием RGB 8.8.8. 24bit. Точнее, почти без сжатия.
Я как-то PNG подсунул Сталкеру, только расширение переименовал. И он сожрал!
Но это ради смеха, не известно, чем может закончится, если подсовывать движку не пожатый формат.

[Diesel]

ed_rez, ты каво? Там 32 бита бамп. Альфа-...анал несёт инфу об одной из высот.