Нет, лучше не сделать. Они (ОГСЕ шейдеры) там и так на ладан дышат (нет оптимизации в первую очередь). Это максимум, чего можно добиться. И то ему пришлось "запрозрачнивать" верх и бока, а иначе артеафакты сыплют. Я поэтому и решил делать не шейдерный попиксельный пересчет, а движковую систему с отраженной камерой, в которой нет косяков с артефактами.

Сделал импорт уровней в blender вместе с картами освещения:

Но проблема в том, что я не знаю как что и с чем нужно складывать/вычитать/перемножать/делить. Из-за этого результат отличается от того, что в игре. Кто нибудь может подсказать, как в шейдерах для статичного освещения используются значения цветов из карт освещения? Что с чем сложить и т. д.?

Pavel_Blend, псевдокод:

финальный цвет = текстура*освещение*2

освещение = амбиент+лайтмап#1+солнце+хеми

амбиент считается из погоды

солнце = max( 0, dot( направление солнца, -(нормаль вершины в мировом пространстве) ) ) * альфа из лайтмап#1
короче обычное освещение по ламберту

направление солнца считается из погоды

хеми = цвет хеми из погоды * dot( лайтмап#2, вектор(1/3, 1/3, 1/3) )

СамСебеСекретарша, спасибо. А в каком файле всё это описано? Я склоняюсь, что в shaders\r1\lmap.ps, но не уверен.

Zagolski, потом мне в ЗП такой баговый рендер поможешь сделать. Мне и так нравится.

Pavel_Blend, не только. lmap.ps это пиксельный шейдер, или как это называют в мире OpenGL фрагментный. Ещё есть вершинный шейдер lmap.vs. Свет солнца считается там, потом интерполируется для каждой пикселя. Кроме того используется код из common.h, это такой общий файл для всех шейдеров со всякими вспомогаельными функциями, описание формата вершин и прочим.

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

освещение = rgb_лайтмап#1 + a_лайтмап_#1 + rgb_лайтмап#2

финал = освещение * текстура * 2

Я ведь правильно понял?

Pavel_Blend, у тебя тут куда-то делся dot rgb_лайтмап#2 с вектором 1/3, 1/3, 1/3.
Хеми - это свет от неба, если что

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

Как определить к какому шейдеру из shaders.xr привязан определённый шейдер из gamedata\shaders\r1?

Например, я хочу изменить шейдер def_shaders\def_vertex. Как мне понять, какой *.vs файл редактировать? Есдинственное, что я знаю об этом шейдере, это то, что он имеет тип LEVEL: diffuse*base. А как понять, какие пиксельные и вершинные шейдеры привязаны к данному LEVEL: diffuse*base? Есть где нибудь такая таблица?:
имя_типа_шейдера -> имена_пиксельных_и_вершинных_шейдеров

Тут вроде два пути:

1. В шейдередиторе или же утилей пересобирающей shaders.xr редактировать def_shaders\def_vertex внутри самого shaders.xr.

2. Создать файл:
gamedata\shaders\r1\def_shaders_def_vertex.s
gamedata\shaders\r2\def_shaders_def_vertex.s
И в нем уже самому прописать на какие ps/vs он будет ссылаться. Этот s-файл при загрузке будет иметь более высокий приоритет, чем настройки из shaders.xr. Соответственно, так как def_shaders\def_vertex изначально уже имеется в shaders.xr, то не обязательно создавать s-файл для обоих рендеров.

В движке в блендерах смотри. В зависимости от настроек из shaders.xr устанавливается тот или иной шейдер. По cls из shaders.xr и далее в Blender_CLSID.h и Blender_Palette.cpp смотри какой конкретно блендер юзается, а в нем уже ищи нужный шейдер. В твоем случае тебе нужен vert.

Хочу сделать видео с перезарядками всех стволов из ЗП. Как здесь:

Но хочу не в игре это сделать, а отрендерить в блендере на серо-белом фоне, как здесь:

Но у меня возникли проблемы с настройкой карт бликов. Они не видны практически. Может кто подсказать, как вообще влияет карта бликов в сталкере, чтобы я аналогично повторил такое в блендере? В каком ps файле шейдеров можно найти этот алгоритм спекуляра?

Проблема в том, что в блендере и сталкеры разные концепции рендера, я даже не про растеризацию и пас трейсинг, а про non-PBR и PBR. Концепция не-PBR рендеринга уже устаревшая и даже года с 2015-2016 перестает юзаться в игровых движках.

Не забивай голову устаревшими концепциями.

Надеюсь тебе поможет эта инфа.
https://academy.allegorithmic.com/courses/b...45e2deaa0626e65

Не проще ли добавить карту бликов к bump-картам через SDK?

Судя по видео, то это рендер в движке. Падают лучи солнца (непонятная тень с права) и от выстрелов перчатки светятся

Алгоритма как такового нет, как во многих игровых движках расчет спекуляра не алгоритмический, а натягивается текстура для каждого вида затенения - по Блинну, Фонгу, Орену-Найяру и прочие. Сама текстура спекуляра либо генерится в движке, либо берется из ресурсов. Как конкретно в сталкере происходит, не скажу, не помню.

Как в ЧН убрать эффект отражения темных точек на нпс, типа как на стекле?
Еще вопрос: чёрный контур в оригинале ЧН на моделях?

Еще вопрос: куда крутить спекуляр? Я в бампе 0,001 выставил значение - ниже нет.
Текстурой править: темнее - это меньше блеск? Забыл уже - альфу или RGB? Подскажите пожалуйста.

Expropriator, чем светлее пиксель, тем больше способность материала отбивать свет и тем ярче на нём блики от света. В красном канале спекуляр, gba - нормал мап

Модель неплохо выглядит по пропорциям..Сам нарисовал?

guitarking123, iron front

получилось настроить модель в редакторе?

guitarking123, у меня СДК06 поломалась.
Материться на Левел-ченджеры из Болот. Ну, я малость переустанавливаю и ищу баг.

Там рано настраивать модель. Там её еще надо сделать в Максе. Это статика, для рендера текстур.

Всем привет, подскажите можно ли как то оживить glow на dx10, dx11 рендере в ЗП, брал код с оксигена, и на рендерах с dx9 (статика, динамика) все работает, а на остальных нет, можно где нибудь взять готовое решение этой проблемы?

ZveroBoy95rus, оно работает. Только еле заметно.

Где тень? Террейну назначать двусторонний рендер? Негоже. Что то раньше я не обращал внимание на косяк разрабов.

Для отбрасывания тени и отсутствия просветов снизу террейна разрабы размещали по краям локации дополнительную геометрию. Там на текстуре прямо так и написано - no sun.

Молодо-зелено.

Ну а откуда еще тень может взяться... Нужны полигоны правильной стороной повернутые к солнцу.


А причем здесь разрабы? Или ты про разраба локации?

Затупил я. Там на локации есть экраны для тени.

Теперь еще досада, не могу запустить компилятор травы в СДК06.
Создал всё заново даже и один фиг, он лежит не дышит, а я ему вставай...

В СДК 07 я уже делал траву много раз. Опять наверно затуп у меня?

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

Добавочка: еще компилятор травы не встаёт, когда чуждые объекты из билдов в равдате валяются.
Например, объекты локации escape_koanyvrot - это 100%, трава не взлетит ни где.

Поправочка по текстурам: если есть в лод-папке thm, тоже самое.

Кому:
Из исходников ЧН 1510 xrDO_Light https://yadi.sk/d/Q42vFqMIUXn2xg
Должен и к 1602 подойти.

Как улучшить графон на r2 (проверял на ТЧ):

в r2\common.h раскомментировать #define USE_GAMMA_22

в r2\combine_1.ps найти #ifdef USE_GAMMA_22
и вместо D.rgb = (D.rgb*D.rgb);
прописать D.rgb = 1.5*D.rgb;
Вместо 1.5 можно ставить цифру больше, но соответствующе усилится засветка.

Попробовал. Похожего эффекта можно добиться и покрутив гамму/контраст/яркость в настройках игры. Но интересная фишка - я так понимаю, это уже готовое изображение, т.е. можно там прикручивать шейдерные плюшки пост-обработки. Сейчас скопипасчу туда SMAA из SweetFX. А ннеет, я же нифига не разбираюсь, что откуда приходит.
Но надо попробовать отразить картинку слева-направо

D = -D+1;

Посоны, вам фрозян ещё нужен? А то я одной строчкой кода его сделал.

D = D*D+1*D;

Интересно, а при компиляции шейдеров есть оптимизация?

1*D

лишние вычисления

Раскрываю 1080 Ti На самом деле я там пробовал разные факторы кроме единицы, но лучше не перемножать.

дизассемблируй и проверь

В combine_2_naa или аа добавь в начале главной функции I.tc0.x = 1-I.tc0.x;
AA или NAA зависит от r2_aa

r2 sun_lumscale_amb 0
Базарю.
Отключает заполняющую фейковую подсветку, делая графон честнее, хоть и немного темнее.
В неосвещенных прямым светом местах нормально работают запеченые лайтмапы.
Нормальных скриншотов сделать не получилось - внутриигровая яркость игнорируется, из-за чего скриншоты выглядят одинаково темно. Ппц.

Тогда картинка синюшная получается, ибо остаётся только синеватая hemi. Тёпло-ламповый графоуни на R2 получается, если убавить hemi и добавить amb.

Вот я подумал насчёт "r2\combine_1.ps -> #ifdef USE_GAMMA_22"
А можно сэмплить средний цвет неба и на его основе менять цвет и яркость D.rgb в гамма-коррекции? Тогда будет лучшее соответствие неба vs. геометрии, а то бывает небо светлое, а земля чёрная, или наоборот. Ну это костыль само собой, правим следствие, а не причину.

разве так не инверсия получится?


В таком случае любой постэффект - костыль


Наверное, только через костыль. Цвет неба не "экспортируется" в шейдеры. Вроде в шейдерах cjacho я такое, ну или похожее видел

Ты их местами перепутал лол.
amb - синюшная дрянь.
hemi - запеченный ГИ.
Это в зове припяти.

Чистый хеми.

Чистый амб.

Чистое солнце.

Солнце+амб.

Солнце+хеми.

Во, точно. Подкрутил еще этот параметр, чтобы тени не были слишком черными. И глоссу добавил.



Можно через текстуры смоллскаев. Смоллскай от скайкуба каждого погодного часа является дополнительным фильтром цвета и яркости + дает дополнительное затенение на нужные стороны. Из-за кривых смоллскаев (не считая кривых погодных конфигов) и картинка в ванильном ТЧ такая синяя днем.

Грифон. В игре поярче смотрится, скриншотилка игнорирует игровую гамму. Такое бывает в некоторых относительно старых играх.
lumscale 2
hemi 1
amb 0
bloom threshold 0.5 или 0.25, не помню

Чистый amb


Чистый hemi

Возможно в конфигах цвет прописан. В ванильном зове припяти такого нет. В чистом небе вроде тоже.
Но даже так хеми смотрится лучше, затеняя те места, куда свет не может попадать.
Амбиент делает картинку как во вьюпорте 3д-редактора, смотрится дешево и мерзко.

Hemi по идее должен соответствовать цвету неба, т.е. если закат и красные облака, то hemi тёплый и ламповый. Если небо чистое и синее, то hemi синий.
amb - это цвет солнца, который попадает на все обьекты, которые находятся под открытым небом, но не получают прямых солнечных лучей. В реале цвет amb не должен сильно отличаться от hemi.

Прежде всего amb - это цвет и интенсивность затенённых участков, относительно hemi и выключенного, на момент настройки солнца.
Относится и к конфигам погоды для статики и консольных команд (в user.ltx) для динамики.
Идеально, когда в user.ltx:
r2_sun_lumscale 1.
r2_sun_lumscale_amb 1.
r2_sun_lumscale_hemi 1.

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

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

Можно сравнения? Вот уже сколько играю - не пойму чем плохо. Хотя наверное уже привык.

Да всё плохо, но двачую - хочу сравнение.

Где можно достать правленный погодный цикл под ТЧ? Ностальжи накатила, хочу перепройти OGSM (как раз новую версию выкатили).

Вернёмся к коррекции гаммы, я тут нашёл забугорную статью с пояснениями и примерами:
https://learnopengl.com/Advanced-Lighting/Gamma-Correction

Суть упирается в соотношения реальной и воспринимаемой гаммы:


Тов. Macron предлагает "прописать D.rgb = 1.5*D.rgb;", но тогда мы просираем часть графония в засветках и затенениях. Я юзал квадратичную функцию D*D+1, так что у меня может быть получается что-то отдалённо похожее на

Но поулчается всё равно странная картинка, хоть и похожа на чоткое кинцо, всё равно не ествественная
https://i.imgur.com/tcfMR9s.jpg

Вариант по фэш-шую и по науке:

Надо попробовать, но это всё OpenGL синтаксис, надо адаптировать.

А ещё текстурам можно делать гамма коррекцию:
vec3 diffuseColor = pow(texture(diffuse, texCoords).rgb, vec3(gamma));