Cornholio

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

мягкие тени и освещение в подземелье

Немного покажу свой "доработанный" АО (сейчас делается для проекта и потому это его эксклюзив на данный момент, но и модифицированная версия будет в свободном доступе, первую версию со скинов выше в теме, можно найти в дискорде по моддингу аномалии, если будет запрос, то могу и сюда залить) Вот как выглядит "быстрое" время на исполнение, в профайлере renderDoc: Вот так выглядит идеал (не очень пригодно для игры в реальном времени, но все равно возможно - время на исполнение порядка 9мс) видно, что быстрый алгоритм вполне неплохо приближается к идеалу (пусть и с меньшим контрастом) Еще есть пути для оптимизации, т.е я ожидаю, что спустя какое время мы сможем за 1мс выдавать еще лучшее качество (ну или ускорить его еще раза в 2) на скрине с счетчиками профайлера - время в милисекундах, а цена на исполнение всего алгоритма находится в строке AmbientOcclusion, он имеет 3 пасса: сам АО и 2 прохода фильтром (просто случайно забыл выделение снять со второго пасса фильтра)

@Ghilli к сожалению я не могу подсказать

@Ghilli не знаю - это скорее вопрос к автору мода. Если б мне надо было делать прицелы - я бы сделал иначе (имхо темные луны плохо для восприятия игрока) лучше всего копировать подход армы, старых call of duty и battlefield - там куча бывалых дизайнеров не просто так пришли к тому виду прицелов, что мы видим в их играх (уверен есть даже презентации и методички по этому процессу в интернете) само собой к модам у меня нет претензий - пусть делают, даже если я считаю это не правильным (я охотно пересмотрю свое мнение и признаюсь неправым - когда кто-то круто реализует такой псевдо 3д прицел), но если серьёзно - обычный модификатор FoV и "маска" прицела - вполне хороший вариант: не ест фпс на второй вьюпорт, не загрязняет обзор игроку ненужными эффектами, а уж сделать прицеливание реалистичным (ну там милдоты, прицельные линии и поправки на дальность, возвышенность) никак точно не мешает.

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

ранний прототип screen space global illumination, пока сделан отдельно на основе GTAO, в планах попробовать его перенести в xray

вопрос по правке движка цель: изменить отношение point light shadow map pixel per meter (сколько метров игрового мира относятся к 1 пикселю карты теней для точечного источника света) суть проблемы: при попытке перевести accumulators на физически более корректное затухание света с расстоянием ( закон обратных квадратов, а в ваниле xray это просто обратно-линейная зависимость ) я упираюсь в границу индивидуальной карты теней для источника (видимая грань на которой обрывается свет) смотрю на класс r2_R_lights.cpp и не могу в нем разобраться, что откуда тянется и где ставится это соответсвие (явно разрешение "индивидуальных" карт теней задается в нем) подскажите - вдруг кто знает? пс - да, я знаю что это значение в некотором роде задается при компайле уровня, но я не хочу пересобирать все уровни, мне кажется проще поставить "заплатку" в виде небольшого множителя K для этого коэффициента.

@ed_rez это - да, знаю. Косячок )) должен уйти сам, когда другую вещь изменю

@Marafon6540 я понимаю о чем ты, и, по своему, ты - прав. но аномалия имеет всебе слишком много удобных фич: дебаггер, редактор подгоды, возможность загрузить локацию без игровой логики (пустой мир без нпс). Это все очень облегчает мне тестирование фич: я телепортируюсь в нужное место, включаю нужную погоду, время и сразу вижу - где косяк.

мое колдовство над рендером. База - аномалия. Изменения: HDR процессинг, блум, АО, небольшие правки формулы для источников света без использования решейда, выхлоп старичка xray

портировал в аномаль GTAO ( по этой статье https://www.activision.com/cdn/research/Practical_Real_Time_Strategies_for_Accurate_Indirect_Occlusion_NEW VERSION_COLOR.pdf) без АО (вообще без какого-либо) GTAO пока много багов, надо убрать гало, следы и добавить оптимизации (хотя уже при 16 семплах выполняется за 4-5мс в 1080р на видеокарте 1060)

@_ХоЗаР_ я, пожалуй верну "толстый gbuffer" заодно появится место под roughness ну и другие свойства материала (может даже светимость, чем чорт не шутит, места-то вагон теперь) вот правда проверить - насколько отличается фпс довольно сложно... но я расскажу, если интересно будет

вопрос я немного глупый и не очень понимаю - почему в сталкере используются другой класс для хранения буффера - rendertarget. Я не понимаю, почему сначала создается полноценный буффер для глубины/стенсил, а затем его перезаписывают уже виде компонента "позиции в экранном пр-ве" . чисто, чтобы поиметь линейную глубину, вместо z/w ? И опять же вопрос - насколько затратны эти render target? Просто сжатые данные gbuffer это конечно здорово, но у меня подозрение, что запаковка и последующая распаковка в каждом пассе постпроцесса съедают больше производительности видеокарты. если предположить, что для gbuffer использовать 3 64битных полноэкранных текстуры, то для fullHD это всего около 48Мбайт памяти на кадр. А вот перекодировать нормали каждый раз (особенно если хочется рейтрейсеры для АО/SSR/GI/FOG) занимает уже заметное кол-во операций на кадр. Я не программист, я так - любитель, но вдруг кто-то разбирается - вчем подвох? @_ХоЗаР_ вдруг знаешь ^

к сожалению это немного расплывчатая формулировка. В рендере ЗП в общем-то есть система материалов и некое приближение к физическому отображению свойств света на них - считай уже готово))) Если же речь про что-то похожее на то что показывал LV или я - то это чуть более сложная модификация и требует редактирования не только шейдеров, но и обвязки на стороне движка. Готового пакета у меня нет, к сожалению. А самое плохое - что для честного PBR надо перерисовывать все текстуры и менять некоторые моменты связанные с кол-вом "технических" текстур. Так-то все формулы для приближения к PBR есть в открытом доступе - читай статьи или просто выдирай код из Unreal, Unity, Filament

@Шипэтя в консоли комманда r2_sun_lumscale для нее возможны значения от 0 до 3, попробуй что-то в районе 1.0 её так же дополняют r2_sun_lumscale_amb r2_sun_lumscale_hemi с аналогичным диапазоном значений - попробуй уменьшать/подогнать под себя.

не совсем понимаю - что именно ты считаешь за беду. Но если речь идет о "фильтрации" теней - то тебе в shadow.h

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

Возможно всё. Вопрос только в постановке задачи и времени-сложности реализации. А раз ты сам в шейдерах ноль, то не знаю - как именно ты собрался это делать. Как мне говорил LV можно делать индивидуальные шейдеры под определенный mat ID, например, так реализован светящийся экран PDA в модах, где есть "физический" PDA. К сожалению деталей я не знаю, меня мало интересовали "частные случаи" я больше работаю с универсальными подходами. Пример "отложенного" шедера для npc model_npc.s function normal(shader, t_base, t_second, t_detail) shader:begin("deferred_npc","deferred_npc") : fog (false) shader:dx10stencil(true, cmp_func.always, 255 , 127, stencil_op.keep, stencil_op.replace, stencil_op.keep) shader:dx10stencil_ref(1) shader:dx10texture("s_base", t_base) shader:dx10texture("s_bump", t_base.."_bump") shader:dx10texture("s_bumpX", t_base.."_bump#") shader:dx10sampler("smp_base") end deffered_npc.vs #include "common.h" #include "skin.h" v2p_bumped _main( v_model I ) { v2p_bumped O; //Hpos and texcoord O.hpos = mul(m_WVP, I.P); O.tcdh = float4(I.tc.xyyy); //Hemi float3 Nw = mul((float3x3)m_W, I.N.xyz); float3 hc_pos = (float3)hemi_cube_pos_faces; float3 hc_neg = (float3)hemi_cube_neg_faces; float3 hc_mixed = (Nw < 0) ? hc_neg : hc_pos; float hemi_val = dot( hc_mixed, abs(Nw) ); hemi_val = saturate(hemi_val); //TBN float3 N = I.N; float3 T = I.T; T = normalize(T - dot(T,N) * N); float3 B = cross(N,T); float3x3 xform = mul((float3x3)m_WV, float3x3( 2*T.x,2*B.x,2*N.x, 2*T.y,2*B.y,2*N.y, 2*T.z,2*B.z,2*N.z )); // Feed this transform to pixel shader O.M1 = xform[0]; O.M2 = xform[1]; O.M3 = xform[2]; //Position float3 Pe = mul(m_WV, I.P); O.position = float4(Pe, hemi_val); //Use L_material.x for old behaviour; return O; } ///////////////////////////////////////////////////////////////////////// #ifdef SKIN_NONE v2p_bumped main(v_model v) { return _main(v); } #endif #ifdef SKIN_0 v2p_bumped main(v_model_skinned_0 v) { return _main(skinning_0(v)); } #endif #ifdef SKIN_1 v2p_bumped main(v_model_skinned_1 v) { return _main(skinning_1(v)); } #endif #ifdef SKIN_2 v2p_bumped main(v_model_skinned_2 v) { return _main(skinning_2(v)); } #endif #ifdef SKIN_3 v2p_bumped main(v_model_skinned_3 v) { return _main(skinning_3(v)); } #endif #ifdef SKIN_4 v2p_bumped main(v_model_skinned_4 v) { return _main(skinning_4(v)); } #endif FXVS; аналогичным способом можно "переписать" шейдеры для конкретных моделей/материалов Что касается кода выше - я сам его не проверял, что именно он делает. Это просто пример работы подобного подхода для "override" материала. Скорее всего он не дружит с тенями (т.е если ты будешь делать так новую геометрию - она не появится в shadowmap)

Я не знаю способа уменьшить "волны" травы без залезания в сами шейдеры (по крайней мере я в консольных командах не видел ничего, что дало бы надежду) Поскольку я сам все свои эксперименты провожу на Аномалии, то могу только говорить на её примере (ванильный рендер ЗП хоть и является основой, но иногда может отличаться) я не уверен по этому методу, так как замерить "колыхания травы" сложно, а мой глаз не замечал каких-то проблем не гарантирую, что тебе поможет, но (!!) попробуй следующее: найди свою gamedata/shaders/папку используемого рендера (r1, r2, r3)/shared открой блокнотом файл common.h найди функцию calc_cyclic float calc_cyclic (float x) { float phase = 1.0/(2.0*3.141592653589f); float sqrt2 = 1.0;//1.4142136f; измени тут на 1.0 float sqrt2m2 = 2.0;//2.8284271f; измени тут на 2.0 float f = sqrt2m2*frac(x)-sqrt2; return f*f - 0.5; // [-1 .. +1] // а тут была 1.0, замени на 0.5 } по идее это в 2 раза уменьшит "псевдо-синусоиду" по которой считается искажение для травы что касается видоса от LV - то этого скорее всего нет в твоей версии Сталкера, это его эксперименты с искажениями PS я продолжил бороться с облаками: и пытаюсь сделать свое АО с блекджеком.. (ну вы поняли) на скрине нет фильтрации, её еще не придумал (не прочитал - как правильно делать) И я тоже задам вопрос (вдруг тут кто знает) Для АО хорошо бы сделать downscale всего Gbuffer Вроде я видел в рендере что-то связанное с этим делом в фазе AO, но я все свои эксперименты веду на движке аномалии, и хрен его знает - где и как там постарались моддеры до меня (например, я обнаружил что отдельный пасс для облаков просто был выключен) Мне надо сделать, причем довольно экономным способом, Gbuffer в половинном разрешении, желательно с небольшим блюром (шириной 1 пиксель, чтобы уменьшить разницу между увеличившимися в размере текселями) Идеи?

я бы не был так уверен. У них партнёрка с майкрософт, соответственно они не так зависят от реальных продаж игры, как если б у них был издатель или они сами как инди шли. В любом случае подобные заявления надо сопровождать пометкой "моё имхо или мне кажется". По факту UE4 позволяет делать очень многое из того, что хотелось видеть в оригинальном сталкере - это и подгрузка ассетов, т.е возможен "без-уровневый" дизайн карты и параллельная обработка неписей (алайф) в больших количествах (ну правда не масштабах стратегии, но для мира сталкера населения в 1-2 тысячи неписей больше чем за глаза хватит) Т.е были бы руки - можно и хорошо оптимизировать с использованием всех новых фич и технологий. Вот только для этого реально нужны руки и головы. Просто так ничего из крутого добра само работать не станет.

Попробуй в файле шейдера сделать замену "screen_res" на "pos_decompression_params2" Только учти, это векторные величины, они как правило пишутся так "pos_decompression_params.xy или screen_res.zw" - не сотри составляющие случайно. Я пока этим развлекался

спасибо! я сейчас вот это читаю и осмысливаю http://remi-genin.fr/blog/screen-space-plane-indexed-reflection-in-ghost-recon-wildlands/ вроде идея похожа, просто подменю на тот самый перевёрнутый бекбуфер, но с искажением от проекции

Screen Space Contact Shadows raw без наложение и смешивание с обычными тенями и моделью освещения Видео в движении https://www.youtube.com/watch?v=5CronUii8_4 Блум и постобработка тут без сравнения, потому что надо частично менять конфиги погоды, чтобы показать до. Но думаю многие примерно знают, как выглядит сток Аномали. Никакого рейшейда - все встроенно в движок и относительно неплохо оптимизировано В процессе работа с водой не думаю что это сильно отличается по качеству от текущей воды в xray - просто чуть чуть иначе считается переход от "прозрачности к отражению" в плане просто заменить на Screen Space Refection