Чернота это болячка OGS* еще с первых версий 0693, собственно по этой причине я его и дропнул в баре - днем все черное при ярком солнце, а когда начинается дождь или ночь вообще ничего не видно. При этом на рассвете все было вполне красиво и адекватно. И дело было не в погоде, они перегнули с затемнением в рендере, никакие параметры в консоли не помогали.
Хотя... судя по скриншоту, они это так и не исправили.

Потому, что там этот параметр перенесён в Лмап колор, и так ещё в нескольких билдах, и поэтому в них часто по две погоды в файле энверонмент, что то вроде "дефолт" и "алл_но_верт".
Не только. Смотри выше.
Пример из 1935
ambient = 0.09, 0.09, 0.09
lmap_color = 1.4, 1.4, 1.4
hemi_color = 0.0, 0.0, 0.0

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

Муторное это дело. Чтобы интереснее было играть установил R.M.A. + Shadows Addon 0.8.3 , и теперь такая штука я пытаюсь настроить погоду, как в 1935 приходится кучу всего править. Я во всю использую консольную команду r2_sun_lumscale_amd для настройки освещения и r2_sun_lumscale_hemi в общем значения после выхода из игры сбрасываются, наверное это из-за shadows addon мода, настройки сбрасываются даже если умрешь и загружаешься или переходишть с локации на локацию, выставляются значения какие-то свои. Есть возможность это поправить?

Где-то есть файл в котором прописаны эти команды. Скорой всего в скриптах где-то! Распакуй и текстовым поисковиком поищи там эти команды. Либо файл user. txt поставь только для чтения.
В движке ОГСЕ такое было. В скриптовом файле были прописаны команды. Которые загружались при любом действии связанном с загрузкой.

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

А за тех. поддержкой Shadows Addon, надо обращаться к Ray Twitty. Хотя, мне кажется, на моменте адаптации к РМА она заканчивается.

Нет, он рисуется отдельным проходом, нечему там просвечивать через дождь.

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

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

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

Уже снёс. Короче нету смысла ничего переносить, потомучто не соотвествуют лампочки из сдк для Тень Чернобыля. Кордон который был открыт мной является кордоном из мода Paradise Lost, а не версией из игры. Вопрос, кто-нибудь знает где взять кордон из ТЧ? Кто-нибудь может проверить правку Zagolski соответствуют ли заданные параметры игровым или нет? Как вообще это проверить кроме как визуально?
Кстати в том же Paradise Lost есть надстройка улучшенная из старых билдов как в 1935. Переносить ничего не надо, достаточно оттуда выдрать её. Вчера установил сей мод не могу понять, там что с твиком от Zagolski, что без него графоний один в один билдовский. Может такое быть, что данный мод уже имеет такое исправление по цветам?

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

Я так понимаю - рисуется еще раз геометрия, но перевернутая?
Почему не SSPR или SSLR ?

Теперь вопрос: насколько эффективен данный метод по сравнению с отражениями в OGSR, да и в целом?

тыжпрограммист, видно ssr артефакты в правом нижнем углу - а именно отсутствие информации

Вообщем перенёс правку в чистый v1.0007rc1, все коммиты совместимы кроме одного, в xrRender_R2\r2_rendertarget_phase_scene.cpp:
Вставил последнюю.

Результат:

Это не SSR - потому при SSR что мы берем пикселы из рендертаргера.
У SSR могут быть промахи - тогда там просто ничего не будет.
В тех местах что я указал - не промахи, а отсутствует геометрия.
В RT там за столбом деревья и здание, в отражении их нет, только небо.
Верхняя (горизонтальная) труба тоже отсутствует, вместо нее опять небо.

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


Added: есть вариант при промахе самплить небо, может это и оно.
Но очень странные промахи

Не разбирался, просто видео понравилось

А, извиняюсь, подумал вы автор, хотел поспрашивать

По идее статья автора: https://www.amk-team.ru/forum/topic/14078-sslr/
Там же ссылки на гитхаб с шейдерами.

Т.е. у него 6 шагов и в world space?
Я отказываюсь верить что это оно на видео. Там артефактищи должны быть невероятные.
Я много вариаций SSLR по работе делал, то что по ссылке - это сойдет за базовый туториал.
И то - я вижу шаги, не вижу проверку на пересечение. Т.е. мы просто шагаем 6 раз и смещаемся в сторону позиции в GBuffer.
Это не SSLR, это какой-то странный маршинг.

Здесь такой же код: https://habr.com/ru/post/244367/

И? Ну т.е. ок - как для того кто учится в графоний - ок, более менее.
Но опять же - где условие нахождения пересечения ?
Его нету. Этот "алгоритм" - полный бред.

Ваша задача - найти где же вдоль отраженного вектора будет пересечение.
Есть куча методов как достичь этого с приемлемой точностью и скоростью.

Можно шагать большими шагами, при нахождении отрезка - бинарное уточнение.
Либо, например, строить пирамиду из депс буфера с min фильтром, и использовать как 2.5D BVH.

Маршиться в ворлдспейсе это вообще глупость - вы все 10 шагов можете долбиться в пару пикселей радостно нагружая GPU ненужными расчетами.

И да - то что в видео - не есть результат "такого же кода".

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

Я на 99.9% уверен что это не SSR.

Там другой маршинг, что-то вроде трассировки. Но да, такой алгоритм позволяет получать очень качественные отражения всего при 6-10 циклах, хоть и смотрится со стороны странно. Но в то же время мощно пропускает тонкие объекты или режет их. Для помещений хорошо подойдет, для улицы лучше использовать стандартный маршинг.

Блин, ну какая трассировка, какой маршинг, если оно даже не проверяет куда уперлись, так, подтягивается к пикселу.
И уж тем более на видео это не оно. Присмотрись к скриншоту - кроме мест что я обвел там все кричит:

"Сделано так - переворачиваем камеру относительно плоскости воды/луж, рисуем выборочно геометрию в неком радиусе от камеры в текстуру, шлепаем текстуру на воду / лужи подмешивая нормали (projectedUV += normal.xz * scale)"

Поэтому и тень "не там", и под той бетонной штукой по центру отражение смогло "заглянуть".

Судя по всему, да.



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

Вот обычный SSR с того же ракурса (25 циклов и без заполнения дыр):



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

Читал-читал, всё таки решил немного раскинуться фактами. Давайте начнём с аббревиатуры SSLR, сиё значит что скрин спейс локал отражения, сразу вкинем "а кто сказал то, что отражения в скрин спейсе априори являются конкретным рэй маршем?".

Конкретно по методу\технике\реализации\созидании скажу что это реконструкция позиции пикселя относительно его положения в мире(потомучто по коду и статье так никто и не понял похоже), и да, как сказал айОрэндж нужно таки "долбиться в глубину" пикселя и тогда как сказал загольский мб мы и увидем тонкие обьекты.
Как убедиться? Да вывести позиции вне цикла и посмотреть сколько ударов было сделано и какая точность будет получена, посему сразу говорю 6-10 проход более чем достаточно.

Вопрос:шейдеры за сто
Куда делись кусты?
Ответ - начальное приближение L, кусты то не попали, вот и пропали

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

Но есть тысяча и одно "но". Я делал это для создания отражения в лужах, где не нужно достаточно честных отражений, и именно для этого я запускал ртшник для блюра чтобы скрыть и отвести взгляд игрока от них, можно "долбиться в глубину нагружая гпу", делать бинарный поиск, но зачем? чтобы сделать честные отражения в лужах? Тогда впору рендерить сталкер в 16к и ужимать до 4к, а чё SSAA бы замутили)

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

А на том видосе, таки да, отражения с моей статьи на амк.

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

Спасибо у меня всё)))

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

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

Я у себя все никак до луж не дойду. Последнее время довольно долго TAA занят был. Муторный алгоритм... Но до ума довел, сейчас все корректно, в том числе с учетом скоростей анимаций.

Грю ж, создал ветнесс буфер который пишется наравне с нормалью, позишеном и альбедо и в этот буффер пишу маски из дефффер шейдеров, которые потом на фазе комбайна применяю, помимо этого ещё эти маски на карты высот умножаю)

т.е стандартный аутпут выглядит так
O.Normal = flaot4(Normal,что-то ещё навскидку не помню);
O.Color = float4(Color,Gloss);
O.Position = float4(Position,что-то ещё только другое);

А я добавил ещё
O.Wetness = float4(Маска луж,три другие маски нужные мне для других целей);
для самой маски можно юзать облака и посылать её по текстурынм координатом детального бампа если для террейна
и по факту ещё надо умножать на второстепенную маску террейна чтобы лужи были ток на плоских поверхностях

И на фазе комбайна у меня выходит s_wetness_mask
И я смешиваю имэйдж и сслр по этой маске
float3 res=lerp(img,sslr,mask);

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

I cannot agree. You are able to make a common function out of SSLR.

Just like i did (you got screens on amkteam). Still, you need to get rid of inverted view matrix.
See example of OGSE reflections by KD.
You can perform a simple blur too - but i don't know if that's really needed there. You can get a nice results using new normal maps for water.

Эммм ,вы меня конечно извините, но "код в статье" - это копипаста с Хабра 100-летней давности, и "никто и не понял похоже" - держите лошадей, пожалуйста, молодой человек.

Любой SSLR начинается с реконструкции позиции фрагмента А у вас это прям "краеугольный камень алгоритма".


Нифига вы там не увидите, просто прошагаете мимо. Где критерий пересечения ? Как вы определите что не прошагнули тонкий объект ? Никак.


Еще раз - лошадок придерживай, ковбой.

Я привел примеры скриншотов, на которых видно что это не SSLR, писал замечания по "алгоритму".
Если это не вы делали то что на видео - то это тогда не к вам, а к автору.

Если вы и есть желание - проясните тогда эти моменты, пожалуйста, а не бравируйте копипастой с Хабра.

Командировка обломала как следует заняться правками от Zagolski, как всегда когда что-то интересное появляются неотложные дела. Однако я все же провёл много тестов нашёл тьму Кордонов за разное время. Всё таки странно как-то воспринимается ТЧ когда что-то пытаешься менять, если ставить эту правку то исчезает синева и лампочки становятся какие-то бледные, мне больше нравятся как раз цвета ТЧ в этом плане, те самые оранжевые лампы в бункере и небольшая синяя подсветка от ламп дневного света, почему-то с правкой исчезает всё. Сначала перло а потом стало как-то скучно, нету того самого эффекта холодной дождливой осени. Имхо Тень Чернобыля хорош таким какой он есть, попытка натянуть на эту историю обёртку Oblivion Lost приводит к разрушению атмосферы и реализма. Кто-нибудь ещё тестил? Какие впечатления?

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

А вообще этот алгоритм трассировки очень интересен. Да, он со статьи на хабре, и интересно, автор его сам придумал или откуда-то взял. Этот алгоритм совершенно не укладывается в привычные нам рамки стандартного марширования луча и для многих кажется диким и неправильным. Но тем не менее он позволяет получить довольно качественную картинку, причем с отличной четкостью и при этом всего за 6-10 итераций луча. Единственный серьезный минус - пропускает тонкие объекты, и не только тонкие. Обычно в этих местах пустота.


Ну просто глаз больше радуется яркой и сочной картинке, чем тусклой. Только и всего. Хотя к этому варианту с освещением в линейном пространстве достаточно применить цветокоррекцию, да и нормально станет. В любом случае освещение нужно производить в линейном пространстве. А не в sRGB, как сделано в сталке по дефолту.

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

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

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

Чтобы ещё раз попытаться вам что-то обьяснить перечитайте пж инфу о такой схеме построения отражений в интернете, ибо инфы дофига и больше и ещё раз перечитайте посты выше, как и для чего они делались, а потом уже можно будет поспорить окей?


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


Увы, но нет. Точность дип буфера с расстоянием как вы знаете падает и чем ближе начальное приближение, тем меньше точность отражения вдали.

Блин, молодой человек, вы можете писать нормально, а не копипастить не имеющую смысла комбинацию слов?
Какое нафиг приближение? Приближение чего? Ваша задача - найти пересечения отраженного луча со сценой.
У вас 2 варианта - рейтрейсинг "по нормальному" - в 3D по всей сцене. Но это дорого.
Либо - SSLR - это когда вы берете депс буфер кадра, и "трейситесь" по нему.

И тут встает проблема - точность. В идеале - шагать нужно с шагом в один пиксел, чтобы ничего не пропустить, но в таком случае производительность будет в заднице.
Поэтому, все те "идиоты" которые работают над ААА играми - они используют "идиотские" маршинги с уточнениями, и даже в таких случаях - остается куча пропусков.

Аналитического решения нет у этой задачи, потому нужен брутфорс с ухищрениями (типа 2.5D трассировки по HZB).

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

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


Причем лучше в половинном разрешении.

iOrange, Не подскажешь, сегодня в грамотных играх какой чаще по толщине буфер истории для TAA используют? В смысле, сколько предыдущих кадров берут. Насколько я знаю, чаще используют только один, т.е. основной и предыдущий. Но это по качеству не ахти, особенно в движении. Хотя если взять тот же Metro Exodus, явно видно, что сглаживание отличное, в нем похоже даже не 4х, а все 8х используется.

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


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


Да, на заре SSLR использовали даунсемпленный Depth чтоб bandwidth экономить (особенно на консолях, на боксе этот депс как-раз весело укладывался в ESRAM).
Сейчас все стараются использовать HZB (все равно он уже есть), алгоритм сам экономит bandwidth (мы же шагаем по мипам), зато гарантированно не пропустишь даже однопиксельной толщины объекты.

Возвращаясь к теме разгрузки CPU в рендерере на дх11. Переносим обновление константных буферов с Map/Unmap на UpdateSubresource и тем самым разгружаем на дипах проц (профит ~10%).

Здравствуйте.
Я работаю над рендерером DX9 в Clear Sky.

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


Hello.
I'm working on DX9 renderer in Clear Sky.

I want to ask, how i can optimize it? Where i should start?
Currently i removed old bloom, and implemented faster code.

Советую сначала перенести DX9-10 рендер Clear Sky на DX11, а затем уже заниматься улучшениями.
Что касается улучшений, то игре нужен нормальный быстрый и качественный AA, а также внедрение отражений. Также желательна переделка блума и HDR в целом. В конечном итоге можно поработать с ambient light, перевести его с лайтмапов и запеченного вершинного освещения на кубмапы-пробы.

Попробовал совет. Нам не помогло. Но возможно на движках, где рендер более долгий - поможет.
А вообще сам хорошо сравнивал до и после?

Я же писал:

А вы бараньей упрямостью прёте дальше, даже после того что я писал относительно недавно:


В итоге тот шейдер + оптимизированный гаусс блюр, вот что получилось: https://yadi.sk/i/PamHVm-pXqdkOg

И мне до сих пор не понятно, где это я назвал другие маршинги идиотскими?

Я думаю, что более простым вариантом для меня будет оптимизация DX9. Я попытался один раз перенести DX11 рендерер на ShoC, и это не получилось

Fizzed, dx9 не оптимизируется, так как dx10.
У dx9 буфер отличимый от dx10 и dx11.

Пример движок NeoAxis OLD dx9 - маленькая локация нормально работает, но стоит туда перенести локацию любую из Сталкера, то движок просто умирает в потугах отрендериться.

В сценах где в проц упирается прибавка фпс у меня около 1-2%. Процессорное время на дипы сокращается с 2 до 1.8 мс. UpdateSubresource - асинхронная, в то время как Map/Unmap считай синхронизирует ЦП-ГП. А в сталке переменных в шейдеры тьма отправляется, особенно на скиннинг. С Map/Unmap суммарно на кадр для обновления константных буферов тратится 0.5 мс проца, с UpdateSubresource - 0.3 мс. И да, UpdateSubresource чуть больше загрузит ГП. А тестировать лучше с большим кол-вом неписей и других динамических объектов в кадре, тогда выигрыш должен быть еще больше.

Zagolski,
Что-то не получилось заметить разницу.
Пробовал разные сцены, пробовал 700+ сталкеров в кадре , но нет.
Win 10, GTX 1050ti. А какой у тебя конфиг? Мб от видеокарты зависит.

Это как-минимум неверно.
С какими флагами Map/Unmap делался? С Discard будет отдан новый буффер, никакой синхронизации не будет.
Мало того - Nvidia советует для Dynamic буферов Map/Unmap делать, ибо UpdateSubresource может вызывать дополнительные компирования внутри.

ЗЫ. Раньше кое-у-кого в драйвере (не буду тыкать пальцем) UpdateSubresource был реализован через Map/Unmap