Я и имел в виду не чистый ТЧ, а модифицированные шейдеры к нему.Там и skygraphics и Dynamic_Shaders_2.0CTP_by_Meltac и прочее. Вот например в движке OGSR x64 который там тоже такая же проблема. Но ее легко решить сменив SSAO на HBAO например.)))

По теме с полосами: предлагаю выключить SSAO и накатить ReShade со вкусным MXAO

Или просто прикрутить другое))) SSDO например.

У Дизеля двиг ЧН-ЗП, как я знаю, а там ванильное SSAO используется по идее. У меня на нем никогда трабл не было, как я его не крутил. В ТЧ - верно, там нет SSAO. А то что кто-то со стороны SSAO прикрутил и он глючит - так это как бы и не в тему...
А полосы у него на скрине все же больше на от теней похожи. Может какой-то глюк меж тенями и SSAO.

Повторю еще раз. У него переделанный движок. В OGSR движке такая же беда при использовании SSAO. Вот один в один. Ставишь HBAO все нет полос. Совпадение? Не думаю)))

Тогда сдаюсь. В любом случае поотключать бы весь этот сталкерский SSAO. Имхо, кушает много, толку мало, реалистичности ноль.


Не хватает до кучи XtremeAO.
Судя по скринам похож на заблюренный LiSSAO. Хотя как по мне такие типы AO более реалистичные, нет четких подчеркиваний контуров, затенение растекается плавно и мягко, только там, где это необходимо.

SSAO глючил в ванильном ЗП у меня (и не только) на карте нвидии. Это началось вроде после очередного обновления дров и/или директа. Я даже в одной из тем кидал видео с этими багами.

DRKIP, не ругайтесь. Поставил HBAO и полосы пропали.
У меня ЧН SSAO было. Теперь 100% ( ну, если точнее, то 99%) ЗП.

Мы дискусировали бро)) Рад что у тебя все получилось.

А можно ли как-то выключить (или хотя бы уменьшить) блум для скайбокса в р2 ТЧ, не затронув при этом весь остальной блум на картинке?

Попробовать перенести отрисовку неба на после combine_2, т.е. на после применения блума и сразу в HW.pBaseRT. Хотя тогда на нем HDR работать не будет (но оно и не надо).

Или в combine_2_naa.ps после строки

напиши:

Возможно поможет, точно не могу сказать, проверять надо.

Все-таки TAA классная штука. Сам по себе являясь по сути суперсемплингом он почти бесплатен, и кроме того, совсем бесплатен для дополнительных рендеров, таких как отражения или 3D прицелы. Одно плохо, правильный ТАА сделать очень сложно.

Вроде сработало, но с "моментами" (способ с depth).
До/после


Два момента:
1) засветка дальних объектов (подобный косяк обычно бывал раньше, когда коряво настроен туман)
2) светлые шлейфы mblur на небе

Всмысле так?

Твой вариант вылетал.

Впрочем, вышеописанные косяки это не исправило.

Скорее всего для ps_2 нужно на if else два return разветвлять. Иначе да, может вылетать.

return half4(img, 1) нужно делать до
img = mblur (center,tex2D(s_position,I.tc0),img.rgb);

Как-то так:

sky2.ps

перед return o; на 37 строке вставить такое:



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

Визуально, вроде не вижу разницы с вариантом

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

Пока что вариант

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


Разницы как с дефолтом, так и с комбинацией от Zagolski не увидел совершенно, игру перезагружал.

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

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

И тишина.

У нашому колхозі усі на морозі

Я у себя на ЗП проверил свой вариант первый, никаких проблем с туманом нет. Да их по идее и не должно быть. Туман накладывается при освещении, при этом небо заблокировано трафаретом. Глубина в районе неба всегда 0 (там идет очистка rt_Position нулями), в остальных местах она > 0. Откуда могут взяться глюки с туманом на дальних объектах, если отсекается от блума только небо? Возможно что-то из полупрозрачных объектов подмешивается... Вообще скрин бы посмотреть, чтоб хоть примерно оценить проблему.

Проверил на ЗП рендере на движке OGSR все работает на ура. Только изменить надо было кое что, что бы правильно работало, так как версия другая. Но суть та же. Просто изменил кое какие строчки. Эффект на лицо как говориться. Блума на небе вообще практически нет. И на горизонте с деревьями в тумане то же все норм. Хорошее решение.

Глюка нет и все работает, как написано. В этом и глюк
Вот скрины:
https://www.gameru.net/forum/index.php?show...t&p=1662125
Деревья на горизонте под дулом автоматом.
На мой взгляд на скрине с блумом деревья затуманены лучше, чем на том, где блума нет.

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


Какой вариант?


Еще не тестил. Как дойдут руки, отпишусь.

RayTwitty я тестировал вариант уважаемого Сjayho. Только подправил, так как у меня не R2, а R4.

Да, на скринах явно косяк. Но у меня такого нету. Я сейчас глянул, на ТЧ не очищается rt_Position. Нужно установить очистку в phase_scene_prepare()

Вместо:


сделать это:


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

Можно попробовать еще:


Перенести в самое начало phase_combine(), тогда помимо разблюривания неба мы еще отсечем от блюра полупрозрачные объекты (с ним они смотрятся ужасно в определенных ситуациях).

P.S. Вариант с sky2.ps вряд ли корректен. Там лишь HDR с неба убирается. Хотя конечно это и блум снизит, но HDR на небе не будет, возможно и привыкания глаз тоже. При этом на ярких участках блум все равно наверняка останется.

Выявил, что в рендере сталка значительно снизит нагрузку на проц, она в нем довольно высокая. Это перенос создания теней point light shadow и sun cascade shadow с CPU на GPU, т.е. на geometry shader. На скринах в кадре имеется 8 точечных теневых лайтов + 3 каскада от солнца. На первом скрине по дефолту, на втором на GPU перенесены только тени от источников света, на третьем также и от солнца.
См. кол-во Draw Call (DIP), ну и всего что с ними связано (перестановка текстур, шейдеров и прочего). Это блеск! Фпс разумеется немного снижается из-за увеличения нагрузки на видяху, зато какое мощное облегчение CPU, он примерно наполовину разгрузился. По ощущениям еще и плавность в игре возросла. Так что это тема. Железо: i7 2600K @ 4500 MHz и GTX 660.



P.S. Кто-нибудь в курсе, на современных видеокартах есть ли какие улучшения в плане ограничения скаляров на геометрическом шейдере? Как там дела на нынешнем фронте?

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

Да, R_DUMP сократился почти в 2 раза, но общее время рендера выросло, фпс упал. На твоей системе явно выгодней на проце считать. Смысл процессор жалеть в ущерб видеокарте. Процессор еще грузить и грузить, а видеокарта пусть что-нибудь полезное посчитает: рейтрейсинг там или физику


Ну так потому, что фпс стал определяться более тормозной рендер частью, а по дефолту фпс ограничивал остальной движок(Статистика в левом верхнем углу fps/rfps и реальный фпс в правом верхнем углу). По всей видимости рендер у тебя работает плавно в отличии от остального движка.

А где все НПЦ, локация пустая что ли? Наверное все-таки надо на заселенной замерять с мобами в кадре. Там у видеокарты и другие дела есть, чем гонять полигоны статики туда сюда. Оригинальная игра какая-нибудь запускается на твоем движке? Можешь замерить на той же базе ЧН или в деревне новичков ТЧ?

Что за серая муть под домиком?

Да нет, мобы на локации как обычно. В домах, справа у костра и т.д. Один и отсюда за стойкой виден. Но с другим ракурсом фпс высокий - 120-180, в т.ч. и с мобами в кадре, и нагрузка на проц меньше. Тут сцена самая жесткая, когда мои и CPU и GPU максимально загружены. Поэтому на ваниле ЧН на этой базе у всех такая сильная просадка фпс, все в проц упирается.
У меня сильный разгон проца до 4.5 ГГц. Если убрать разгон, фпс раза в полтора упадет. А в этой сцене на всем болоте на проц максимальная нагрузка из-за большого кол-ва точечного света в кадре (да и вообще геометрии) и даже при такой частоте фпс уже практически упирается в проц, сильнее на нем не погоняешь.

Кстати, рендер на скринах форвард+ с z-препассом, так что нагрузка в плане дипов тут больше из-за двойного прогона геометрии, по сравнению с ванильным деферред.
Думаю, на более мощной и современной видяхе просадка по фпс будет меньше, у меня-то довольно старенькая. К тому же тут главное, как сильно уменьшается нагрузка на CPU в рендере. Причем только на тенях.

Ресурсы CPU стоит беречь, имхо. Они для другого пригодятся (аи и пр.), к тому же производительность GPU с годами растет куда стремительнее CPU, не говоря уж о том, что можно воткнуть 2 или 4 карты в тот же SLI. Да и у сталка нормальной многопоточности нет, для него CPU на вес золота.


Оригинальная пока не запускается, я еще под нее не настраивал. Скрины с базы ЧН, кстати.
Побегаю еще по локациям, потестирую разные сцены, скрины сделаю.
Рендер-то еще в разработке, поэтому что-то не доделано, отключено. На воде я отражения и искажения отключил, вот там и муть. На это не стоит обращать внимание.

Все плохо и геометрических шейдеров все так же все избегают.

PS. 200 дроу-коллов это в наше время ниочем. Странно что так CPU разгрузился. Попахивает стейт-трешингом.

На скрине 8300 дроу-коллов в дефолте и 3300 на GS. Смотреть надо параметр DIP/DP в самом верху. Ты не то смотришь.


Жаль... Я надеялся, что ситуация на современном железе стала получше.
Если правильно с ними работать, они очень быстрые. Т.е. не давать на выход более 20-25 maxvertexcount * count float.

Ну он наверное мою таблицу смотрел. Выглядывать на скринах, то еще занятие. А я из DCL взял значения

Zagolski,
А можешь вывести загрузку GPU CPU?

Да, я глянул Абрама табличку, сорян.


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

Смотри в чем проблема - геометрические шейдеры плохо параллелятся. Ведь требование какое - примитивы должны рисоваться в том же порядке, в котором они выходят из GS. А это уже синк поинт.
Дальше - чтобы как можно меньше висеть на синках - надо буфферизировать выхлоп GS. Тут либо делать большой локальный кеш (привет Nvidia), либо писать в память (привет AMD).

Решение Nvidia чем плохо? Правильно - приходится резать число одновременно летающих потоков чтоб хватило on-chip памяти, а это боттлнек прямо в планировщике.

Чем плохо как AMD писать в память думаю сами понимаете.

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

В современных видеокартах GS - это такой себе копчик, который просто для совместимости с уже написанным софтом. Не более.

Hello. I got a really annoying problem in STALKER.
As you can see on screen, trees in distance are really dark. I don't know why.
In clean SHOC i didn't got a such problem.

What engine im using? OGSR (with KD graphics work aka old rendering). R2.


Привет. У меня есть действительно раздражающая проблема в STALKER.
Как вы можете видеть на экране, деревья на расстоянии действительно темные. Я не знаю почему.
В чистом магазине я не получил такой проблемы.

Какой двигатель я использую? OGSR (с графикой KD работает иначе старый рендеринг). R2.

Fizzed, я думаю проблема либо с лодами, либо с mip-map уровнями. В первом случае попробуй открыть текстуры лодов уровня и просто осветлить их в редакторе. Во втором случае, проблему можно попытаться решить как с детейлами, отредактировав текстуры листвы: https://xray-engine.org/index.php?title=Чер...._Что_делать%3F

Main issue seems to be just OGSR engine... i don't know what needs to be fixed in shaders.
Friend of mine told something like that "in all OGSR based engines theres problem with foliage".

I will try your method with new foliage textures. Thank you)

Hello
Please compress and attach here your game's gamedata/shaders/r2 folder
I'll try to help you
thank you.

Hi. Here is my R2 folder.

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

работает. А o.low *= 0.5f; просто понижает яркость неба как я понял, мне это не нужно.

default / cjayho / cjayho + r2_tonemap off


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

RayTwitty, конечный вариант можно будет потом получить? Желательно дифф

https://www.gameru.net/forum/index.php?s=&a...t&p=1662170
RT

Зачем выключать, снизь значение r2_tonemap_middlegray

Вот тебе файлик с различными размахами тонмаппинга

Нажмите для просмотра прикрепленного файла

--------------------------

Fizzed, I cannot even launch OGSRMod with your shaders. Which mod you're using?

Cjayho, i'm using OGSR engine (https://github.com/OGSR/OGSR-Engine/releases/tag/1.0.688)

Fizzed, перебирайся на ЧН. Пусть КРодин сперва все баги залечит.
Он на лету только успевает их править. Хотя этот двиг и хвалят. А я не понимаю почему. За DX11?


Вот это глянь. Жаль DХ11 нет. Но там и плюсы очевидны. Хотя и минусы видны.
https://www.gameru.net/forum/index.php?s=&a...t&p=1661169

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

У кого-нибудь есть идеи, от чего так прилично падает производительность при увеличении кол-ва травы? Вроде полигонаж на ней низкий, пиксельный шейдер простой. Во что-то упирается, а во что именно я никак не разберу. Или все же по филлрейту так сильно бьет из-за альфа-теста? А то надо бы траву оптимизировать, все же от нее восприятие в игре сильно зависит: когда травы много и она далеко рисуется, сталк совсем по другому выглядит.

Так это древняя версия и уже не актуальная вообще.
Вот новая самая версия движка. И как я понял он играет в чистый ТЧ с использованием движка ОГСР.


So this is an ancient version and is no longer relevant at all.
Here is the newest version of the engine. And as I understand it, he plays in pure Shadow of Chernobyl using the OGSR engine

https://github.com/OGSR/OGSR-Engine/releases/tag/2.0.814

Лично мне не нравится CHN или ZP.

ShadowMapping не? При включении теней от травы появляются просто дикие лаги. Такое впечатление что оно отрисовывает тень для каждой отдельной травинки.
Имхо отключите вершинный шейдер качания травы и посмотрите, может в нем дело.




ok, downloaded. Please give me savefile when i can see that bug. Thak you.

Я имел ввиду, что после отключения блума, на небе все равно были засветы, которые как выяснилось вообще от другого. Так то даже я понимаю, что блум это постобработка и применяется ко всему - будь то небо или металлическая железяка на полу. Именно поэтому кстати "шлейфы" от света в 1833 билде в саркофаге так круто смотрелись в трейлере, и так стремно работают в реале - шлейфит всё подряд, особенно на улице.

А никто так кстати и не пробовал восстановить оригинальную версию? Как оно работает? Замут на основе блёра не в счет.
На глаз, как будто бы берут пиксели с яркостью больше опред. значения, запоминают позицию в пространстве и потом еще несколько кадров рендерят, постепенно уменьшая прозрачность.