Возвращаясь к теме строчки в шейдере sload.h
Ща недавно обнаружили интересный пример влияния данной строчки и почему её всё же стоит убрать.
Модель со строчкой:

Без строчки:

Короче если в нормали есть хоть какие-то артефакты то шейдер их только усиливает.

mortan, а ещё лучше вообще убрать Z-ось Normal Map.

Обновление:
liberty city build 12.02.2021 для ТЧ
https://cloud.mail.ru/public/qwbu/xHJK9ZZZw

Update 12.02.2021
-прозрачные опции
-регулятор дальности травы в опции
-включен мод "soc_sound_clicks_fixx"
-включен мод "правки зубов и меха v3"
-фиксы логики "GameAIFix"
-в спавн-меню добавлен бюрер
-в спавн-меню добавлен велокровосос
-в спавн-меню добавлен мотоцикл с коляской
-в спавн-меню исправлен спавн собак

Update 11.02.2021
-добавлен отдельно скачиваемый базовый архив для установки без ТЧ
-mouse_ui_sens 7 по умолчанию в движке

Обновление:
liberty city build 15.02.2021 для ТЧ
https://cloud.mail.ru/public/qwbu/xHJK9ZZZw

Update 15.02.2021
-правки и оптимизация textures.ltx
-правкa потенциальных проблем с псевдогигантом
-доработка саундтрека

Update 14.02.2021
-правки проблем ТЧ с некоторыми скриптами
-правки проблем ТЧ со спавном псевдогигантов
-улучшение пары текстур
-саундтрек для уровня

macron, может тему отдельную для этого? Не совсем понятно причем тут Графика, рендер, шейдеры

macron,
во флагштоках и их шевелении (шейдеры), необходимы какие-то правки движка или все на уровне адаптации шейдеров?

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

Только шейдеры. Для любой текстуры с шейдером def_shaders\def_vertex можно в level-файле его переименовать в flag00 или в def_shaders\def_flag00.

Еще можно raskolbas.s переименовать в def_shaders_def_vertex.s. Но за последствия для психики не отвечаю!

Макрон, привет! Есть вопрос: как там дела обстоят с мультиплеерным патчем 1.0008 ? Будет ли дальнейшее развитие, или на этом пока все остановилось?

Последняя автозагружаемая вариация X.0006 была на stalker-life, иногда мелькала в общем списке серверов. Есть идеи добавить туда последние мелкие графические наработки. А уж будет ли работать сервер, уже давно не мои проблемы. Я понял так - если хочешь всё сделать хорошо, надо заниматься/контролировать всё самому вплоть до содержания и настройки сервера. "Людям" в широком смысле слова оно не сильно надо или получается криво. Мне оно тем более не надо, других дел хватает.

Есть ламповый офигенный двиг для всея ЧН с рендером ЗП + всё наилучшее из ЧН.(Сам собираю, на данный момент отдельно физику ЗП тащу туда).
Линия старого двига моего допилена SCS - один вариант. Другой на ядре ЗП двиг ЧН + SCS. Третий с физикой пока в глубоком проекте.

И еще забыл: Есть ламповый двиг ЗП 1600 с моим рендером из ЧН+ЗП шейдер компиль.

Через 12 лет я стал различать лайтмапы. Пысы малость притупили с освещением, пришлось создавать систему для поиска истины.



Решил заскринить 1650-1080. Видяха 320 вылетает - не тянет. Один скрин успел сделать.

Почему в игре ЧН ПЫСы заблокировали консоль:
r2_dhemi_light_scale
r2_dhemi_sky_scale

Поэтому мы нифига не можем настроить лайтмапы. Скажете, а какое это имеет отношение к ним? А прямое, для сведения цвета статики и цвета огф.

Всем привет! Скомпилил карту на ТЧ, но при запуске на втором рендере игра вылетает не найдя шейдеров:
deffer_impl_lmh_bump_d-hq.ps и deffer_impl_lmh_bump_d-hq.vs
Где их можно взять? Перерыл уже и релизную версию, и кучу билдов, но этих двух шейдеров так и не нашел

https://files.xray-engine.org/shaders/r2_de...mh_pseudofix.7z
Но это затычки для ЧН, в ТЧ может быть что-то другое. Смотри, копипасть, переименовывай. Или компилируй карту на высоких настройках.

Билдомассон, deffer_impl_bump_d-hq - этот шейдер скопируй и переименуй в тот что нет.

Trollz0r, у него в тектсурах баг. Включена или не включена галка имплисит?
Вообще эти шейдеры через base работают, но когда текстура корявая в компиле, то шейдер создаётся с новым именем.

Карта и была скомпилена на высоких.

Спасибо!

Нужно прописать террейн в textures.ltx

Вроде как это параметры для трасировки глобального затенения у динамичиских объектов в реальном времени. Влияют на освещение динамики "под крышой".

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

Это как если не секрет? Одни шейдры и для статической, и для динамической геометрии?

-------

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

Соответствующие скрины прилогаются:

Классическая лайтмапа
Террейн лайтмапа, Террейн лайтмапа 2
Эффект "бесплатной" мягкой воды, аля билдо стайл.

Hozar_2002, а хрен его знает.
-А ты суслика видишь?


Где то они в движке точно пересекаются - лайт дб сипп.
Амбиент то у них общий.

Вы про это. Понял. Ну у нас в иксрее на динамике по большей степени отложка. Все расчеты проходят после рендера геометрии. Хеми затенение на динамике передается из вертексных шейдров (для динамических моделей это deffer_model_*.vs, для статики deffer_base_*.vs, ну и частные случаи, такие как растительность), и из лайтмап, если они назначены на эту модель. Расчет же освещения (от источников света, и эмбиентного) проводится после всех этих расчетов.

В ОГСР паралах недоделан был. Он как бы был, но работал иначе.

Вот я в стандарт вернул:

А что вернул, а потому что это работает делка рендера ЧН-ЗП SCS, вмонтированная в ОГСР.

Его никто и не делал, следовательно, криво работает.
ОГСР больше подходит 11 рендер, на 10 сильно слабая картинка.

Уважаемые, а со скриптовыми шейдерами кто работать умеет?
У меня проблема - создаю свой шейдер, прописываю ему следующее:

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

Для теней надо кроме normal еще функцию l_point прописать.
Если по аналогии с движковым, то как-то так получается:



Это странно. Разница между р3 и р4 должна быть только в теселяции. В ОГСР все затесселировано что ли?

у тебя тоже паралах недоделан...

Спасибо! Только один момент - там shadow_direct_model надо было использовать для vs.
Собственно, ради чего всё это затевалось:

О, у анимированных флажков тени появились. Правда, статичные, но хоть что-то.

Это вряд ли. Я как-то правил ребятам одну модель и не было там шейдера тесселяции.
А визуально разница огромная:
р3 - http://www.imagebam.com/image/3d47fd1304329174
р4 - http://www.imagebam.com/image/6cc29f1306611714
И мне явно не нравится р3. И тут дело не во вкусах, на этом рендере полный ахтунг.

НоСун забыли сделать.


R3

Тени тоже можно анимировать. Надо всего лишь скрестить вершинные шейдеры из normal и l_point.

Тогда вот ещё вопрос - как можно вытянуть значение хеми (лайтмапы) в шейдер model_env_lq?
По-идее оно берётся из s_hemi, но не получается нужные координаты получить.
Это должно частично решить проблему с освещением полупрозрачных поверхностей (стёкол), т.к. в ванилле они используют лишь упрощенное освещение от положения солнца, не учитывая хеми (потому банки и бутылки в помещениях светятся, если не максимально прозрачны). Останется косяк с освещением от динамических источников света, но по этому поводу у меня тоже есть идеи.

А для них лайтмапы по идее и не созданы. model_env_lq - это динамические объекты. А лайтмапы делаются только для статики.

Да, но есть же общая карта хеми, которая через r2_sun_lumscale_hemi регулируется ещё. В hmodel.h она считается с последнего канала из s_normal

ed_rez, не могу привыкнуть к R3 OGSR. В моём двигле хоть костыльно, но R3 бодрее.


На динамику только через комбин шейдер влияет.

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

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

Нет такой карты.
Для s_hemi надо знать секретные uv, которые знает только xrlc и прописывает в модели статики. Для стекла таких нет.
s_normal - это рендертаргет, который заполняют шейдеры, содержащие слово f_deffer. Как правило они берут значение из s_hemi.

Можно попробовать брать хеми от геометрии за стеклом(читать s_normal с координатами текущего пикселя).

И в разы симпатичнее. Но это на мой взгляд.

Diesel, тут на amk приметил кто-то процедурные небо/облака ковырял, может вам есть смысл обменяться опытом...

https://www.amk-team.ru/forum/topic/12673-s...comment=1358817

Вообще можно использовать хеми для динамических моделей. В common.h(или его аналоге для R3) перед функцией calc_model_lq_lighting создать функцию

//  Hemi cube lighting
float	clac_hemi_val_dynamic_model(float3 norm_w) {
	float3   hc_pos	= (float3)hemi_cube_pos_faces;
	float3   hc_neg	= (float3)hemi_cube_neg_faces;
	float3   hc_mixed= (norm_w < 0) ? hc_neg : hc_pos;
	return saturate(dot(hc_mixed, abs(norm_w)));
}

Далее в calc_model_lq_lighting заменяем L_material.x на clac_hemi_val_dynamic_model(norm_w). По идее все. Хеми будет выглядеть примерно так же как и у другой динамики. По идее все должно работать.

На амк я не ходок более. Там дебильные модераторы, которые в теме "костер" (типа ФФ), банят за халявную раздачу на эпиках - а еще там юзеры в "костре" Павлы Морозовы, которые стучат с жалобами куда надо.

Сработало, спасибо!

Hi. In first place I'm sorry for writing in english on RU forum.

I would like to ask, have anyone tried to approximate Hammon's diffuse model for image based lighting (in DFG LUT/convluation form)?
Right now I'm using Burley's model, but it's not energy conserving (yeah, DICE attempted to fix it, but I would like to try something better like Hammon model).
Thanks!

So I got it working, I'll leave some pseudocode for interested;
Just baking it into LUT.

Hi.
There are only two or three guys who can make such work. But i didn't hear they're working with this.



you can use saturate() function instead

Well, there are rumors that the saturates are slower than the clamp. But they still understand that it is most correct to use min(1.0, max(0.0, value))

We can easily check instructions count (even assembly code) with fxc.exe from windows 8.1 SDK.
i wrote two simple fragment shaders: one with saturate and one with clamp.
They produce same code.

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

Thanks.