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

[=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

[Scav]

Цитата(Scav @ 01.02.2020, 19:17)
идея GSC
Нет

Давайте не будем уж до такой степени докапываться, а то в поисках исторической справедливости придется разыскивать основоположника этого метода, а он нам сейчас на фиг не сдался. Мы тут, вроде как, непосредственно про "Сталкер" речь ведем, если я не ошибаюсь? И, раз уж на то пошло, конкретно у ПЫС никакого алгоритма не было, там явно ручная заливка фона одним цветом "на глаз", причем не всегда адекватно (встречаются коричневые кустики с зеленым фоном). А в ЧН и ЗП они и на это забили, оставили черноту.

[Zagolski]

Нет, любая вменяемая игровая контора решает эту проблему стандартно - посредством т.н. "colour dilation" - т.е. это алгоритм, при котором мы дублируем пикселы на границе прозрачности в неком радиусе. Чаще всего этот радиус 4 пиксела, ибо тогда мы гарантированно перекроем блок.
Альфа канал при этом, естественно, не трогается.

Это тут вряд ли причем. У нас же по-любому альфа 1-битная, т.е. черный и белый. Клип происходит по ней с неким коэффициентом на границе, которая фильтрацией выборки в серый мешается. Важно точно срезать под этот коэф. Так вот при неправильной фильтрации мипов при создании текстуры, более высокие мипы криво создаются, то в min, то в max уходят в зависимости от выбранной фильтрации. Посему в игре клип начинает происходить либо раньше захватывая основной цвет (там он черный, соотв. на дальней траве имеем черный ободок, а с твоим вариантом он хоть и будет зеленый, но трава все равно станет толще нужного), либо позже - дальняя трава становится тонкая или вообще исчезает срезаясь полностью. Оригинальный алгоритм создает весь набор мипов так как нужно, чтобы они с этим фиксированным коэф. правильно клипились по всей высоте мипов.

В любом случае спасибо за разъяснение, нужно будет попробовать с заливкой. Может и правда все гладко станет.

Но Шталкер где-то подножку делает. Не могу вспомнить где, но четко вбил в память, что никаких DXT5 ARGB

Теоретически можно сохранять траву в DXT5 (сам я не пробовал, поэтому точно не могу сказать), главное, чтобы альфа была 1-битная, т.е. только черный и белый цвет без каких-либо серых оттенков. Сохранять в DXT1 - это с защитой от дурака, чтобы у тебя принудительно альфа 1-битная образовалась (если она больше). Правда неясно, что у тебя фильтрация мипов в DXT5 натворит. Может испортить.

Сообщение отредактировал Zagolski - 02.02.2020, 03:14

[iOrange]

У нас же по-любому альфа 1-битная

Зачем?

главное, чтобы альфа была 1-битная

Зачем?

Сохранять в DXT1 - это с защитой от дурака

От какого дурака? "Альфа" в DXT1 - это хак, который натянули через одно место на S3TC компрессию цветового блока, и которая отбирает биты у цвета, убивая качество еще сильнее.
Юзайте DXT5 и не сношайте мозги себе - повысится как качество текстуры (ибо цветоблок будет жаться отдельно от альфы), и будет вам счастье.

[Zagolski]

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

Сообщение отредактировал Zagolski - 02.02.2020, 04:33

[Zagolski]

Тут наткнулся на материал по рендереру Deus Ex: Mankind Divided: https://www.eidosmontreal.com/en/news/defer...for-dawn-engine
Думал, они до сих пор сидят на отложенном освещении, ан нет, смотрю еще в 2016 перешли на visibility buffer вместо g-buffer. Мне казалось, эта техника только на бумаге хороша, до этого момента не встречал ее реализации в продакшне. Или я опоздал на вечеринку, неужели действительно next-gen?

[iOrange]

Думал, они до сих пор сидят на отложенном освещении, ан нет, смотрю еще в 2016 перешли на visibility buffer вместо g-buffer

Звучит так же стремно как "Думал, они на форвард рендеринге сидят, ан нет, смотрю перешли на occlusion culling вместо отрисовки".

Там "обычный" deferred, но со всем современными плюшками - gpu culling, indirect draw, bindless textures и т.д.
Благодаря этому в gbuffer можно держать только основную инфу (текстурные производные и TBN как база) и фетчить материалы уже в фазе шейдинга. (единственные фетчи на этапе первичной растеризации - это альфа для клипа).

По текстурам травы отвечу чуть позже.

[Zagolski]

Благодаря этому в gbuffer можно держать только основную инфу (текстурные производные и TBN как база) и фетчить материалы уже в фазе шейдинга.

Я только про это. Т.е. держим в буфере uv и некоторое еще, а выборку текстур делаем уже на этапе освещения, тем самым устраняя главную проблему в виде толстого g-buffer. Но если это так идеально, почему все не переходят на нее и продолжают сидеть на стандартном g-buffer, порой толстенном? Тут явно какие-то скрытые камни.

Сообщение отредактировал Zagolski - 02.02.2020, 06:28

[ed_rez]

Правда неясно, что у тебя фильтрация мипов в DXT5 натворит. Может испортить.

Давай проще. Я думаю, что у тебя есть ФШ. Возьми любую исходную текстуру DXT1 ARGB 4bit и пересохрани в DXT5 ARGB 8bit. А затем открой и сравни мипмапы. Но только не бери с исходника мипмапы, а автогенерируй. Вот тебе быстрое сравнение:
Исходник (DXT1 ARGB 4bit) vs DXT5 ARGB 8bit
vs
Мне в СДК делать сравнение?

[Zagolski]

Исходник (DXT1 ARGB 4bit) vs DXT5 ARGB 8bit

Лучше заливай скрины на фотохостинг этого сайта. Вверху есть ссылка. Иначе куча рекламы, вирусов и еще вдобавок скрины не грузятся.

[ed_rez]

iOrange,
на всякий, чтобы было понимание, алгоритм сжатия на каналах RGB до 8 бит, DXT1~=DXT3=DXT5. Это факт! Причем, как сам вижу, так и специалисты это рассказывали. Далее идет канал альфа, вот тут уже пошла разница в сжатии- от 1 бит до 8 бит.
На кой мне мягкие края на текстурах, где ее не должно быть? Фильтр берет подгрешность +-1 пиксель при сжатии и смягчает края, т.е. делает 128х128х128 цветом. Мне это не нужно.
Про DXT5 c 1 битной альфой не слышал.

Сохранять в DXT1 - это с защитой от дурака

Ага, когда размер в 2 раза меньше. И полностью выполняет свои предназначения. Ты еще предложи сохранять в 8.8.8.8 ARGB. Если что, то Шталкер съедает на раз их. Лично извращался. Но правда размерчик душевный. И да, тут будет все то, что было в исходнике, глаз в общем, не увидит разницы.
Ты же бьешься за оптимизацию? Вот и ответ.

Сообщение отредактировал ed_rez - 02.02.2020, 08:16

[iOrange]

перешли на visibility buffer вместо g-buffer

Извини, но вот этот кусок дает мне возможность предполагать, что ты путаешь понятия. Visibility buffer - это просто таргет, куда мы рисуем коробки кластеров треугольников с форсированным Early_DS_Z.
Этот буффер затем юзается чтоб собрать дроуколлы для индирект дроу.
В Юбиках вместо него юзают хитрый мердж из HZB и репроджекта депса прошлого кадра.

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

Как видишь - Visibility Buffer ни в коем случае не может быть заменой G-Buffer'у.

устраняя главную проблему в виде толстого g-buffer

Нет, они не эту проблему решают. 4 таргета по 32 бита - считай стандарт для современного деферра, у них буфер такой же по толщине остался.
Главная задача - убрать точки соприкосновения GPU и CPU. Вот тут он и нужен.

Но если это так идеально, почему все не переходят на нее

На нее это на что? Если ты про GPU culling - то юзают практически все, в том или ином виде. Кто-то мешлеты, кто-то просто бъет геометрию на чанки. DICE, Ubisoft, id Software и прочие.
Если ты про отложенное текстурирование - то все упирается в то, что нужно сапортить Dx11. К сожалению.

[ed_rez]

Иначе куча рекламы

Этот ФХ без рекламы. Я забываю про внутренний ФХ.

[DRKIP]

Используйте вместо него DXT5 и будет вам счастье и наложницы в загробной жизни.

Я с этим провел много экспериментов. Если взять готовую траву и сохранить ее через ФШ. в DXT5 то она будит по любому с 8bit альфой.
В результате мы получим.
1-Если не использовать вот этот метод https://xray-engine.org/index.php?title=%D7...%EB%E0%F2%FC%3F
то трава на границе где-то в 50 метров начнет чернеть.
2-Если мы используем этот метод, то частично от полной черноты избавиться получится, но тогда трава на дальних расстояниях будит менее густая и пропадать по факту из за 8bit альфы.
3-

Да "весить" текстура будет ровно в 2 раза больше, но и качество будет в разы лучше.

Оно будит выше только в просмоторщике картинок и все!! И это 100% факт.
В игре же по факту разницы нету.
По этому. Сохранять строго с 1bit альфой. Да если была бы возможность сохранить в DXT5 c 1bit альфой то почему бы и нет. Но я такого способа я не знаю и думаю ни кто тут не знает.
Да и вообще Сталкер с травой работает именно с 1bit альфой.
И тогда при правильном сохранении мипмапов и альфы мы будим иметь четкую траву на любом расстояние от ГГ. в игре.

Думается мне, что DRKIP применяет именно этот метод.

Совершенно верно

Сообщение отредактировал DRKIP - 02.02.2020, 08:01

[Zagolski]

Про DXT5 c 1 битной альфой не слышал.

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

Сообщение отредактировал Zagolski - 02.02.2020, 07:59

[iOrange]

DXT1=DXT3=DXT5. Это факт!

Прости, но не факт.
В режиме "DXT1 просто цвет" - да, утверждение выше правдиво.
В DXT3 и DXT5, по сути, 2 плоскости - цвет и отдельно альфа, которые жмутся независимо, и цветовая плоскость жмется так же, как и DXT1 без альфы.

Но не зря я писал что "альфа в DXT1 это галимый хак" - ибо в случае наличии "альфы", вместо таблицы из 4 цветов, у нас остается лишь 3 цвета для интерполяции по блоку, и 4-й "цвет" резервируется для обозначения прозрачности.
Как сам понимаешь - цвет при этом сильно деградирует.

[ed_rez]

RGB до 8 бит, DXT1=DXT3=DXT5

vs

[DRKIP]

Вот если интересно то моя работа. Там четко видно как ведет себя травка да и не только
Сдесь ссылка на скрины из моей работы.
https://ibb.co/album/bY3Tqa

Сообщение отредактировал DRKIP - 02.02.2020, 08:07

[ed_rez]

не про формат DXT с 1-битной альфой толкую, а про битность цвета альфа-канала текстуры

Фильтр берет подгрешность +-1 пиксель при сжатии и смягчает края, т.е. делает 128х128х128 цветом.

Была 1 битная альфа, стала с твоим DXT5 8 битная. Оно нужно? Мне точно нет.

DXT5 c 1bit альфой то почему бы и нет.

Сохрани, как DXT1 c 1 битной альфой и перенеси альфа канал на DXT5. Ничего так, забавно.

[iOrange]

Простите, но я удаляюсь из этого бтреда. Когда люди начинают спорить со спецификацией формата - это уже слишком. Удачи.

[Zagolski]

Как видишь - Visibility Buffer ни в коем случае не может быть заменой G-Buffer'у.

Вот тут говорят, что может: http://diaryofagraphicsprogrammer.blogspot...ity-buffer.html

Если ты про отложенное текстурирование - то все упирается в то, что нужно сапортить Dx11. К сожалению.

Да-да, именно про него.

Сообщение отредактировал Zagolski - 02.02.2020, 08:26