Zagolski, а попробуй удалить юзер.лтх
Сдаётся мне, что моргание источников света происходит от нестандартной настройки тонмаппинга.

Выявил причину мерцания света. Нельзя задавать радиус света меньше 2.5 (параметр idle_light_range). Если он меньше, нарушается отрисовка теней, они то создаются, то нет. При этом если тень не создалась, то те места, которые она должна затенять - на них ложится свет (тут скорее всего вообще источники путаются при сортировке в CRender::render_lights, потому как начать мерцать может соседний свет, причем обычный от лампочки), происходит вообще баг мерцания света, как где-то RayTwitty показывал на видео. Если источник бестеневой, то в принципе можно и меньше задать, но все равно слишком сильно мерцание.

И там еще в классе аномалий к радиусу рандом применяется, правда +-0.25 всего, но тоже видимо влияет. Видать в конечном итоге радиус падает меньше определенного предела и тень не создается. Это все относится только к огневым источникам света (костры, керосинки, лампадки), которые на классе аномалии висят.

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

Что главное, нет ни смазов ни отставаний, абсолютно идентичная картинка в динамике и куда более высокая скорость.

Либо можно распределить по каскадам. Ближний каскад обновляем каждый кадр для идеальной точности вблизи, средний каскад каждый второй кадр, а дальний каждый 4 кадр (его можно и раз в секунду обновлять, издалека разницы не видно).

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

Пока не забыл. Возможно кому пригодится. Я чуть выше писал о проблеме получения значения глубины в шейдере напрямую из z-buffer, где стандартная формула преобразования не работала. Я не учел, что сначала нужно декодировать данные из диапазона 0...1 в -1...1. Так что вот работающая формула:

depth = tex_depth * 2.f - 1.f;
final_depth = (2.f * near * far) / (far + near - depth * (far - near));

И как результат мягкая вода на статике (на тени с бампом просьба не обращать внимания, они всего лишь прикручены к R1):

Zagolski, можно дифф?

Откуда ему взяться? Я лишь привел формулу, которая декодирует нелинейную глубину из z-buffer в линейную необходимую для расчетов в шейдере. Аналог s_position, которого на статике неоткуда взяться (как и на любом другом forward render). Добавлю лишь, что near и far - ближняя и дальняя граница "камеры", первый это VIEWPORT_NEAR, по дефолту 0.2, а второй g_pGamePersistent->Environment().CurrentEnv->far_plane (предел, зависит от дальности видимости).

Для динамики это не нужно, там отложенный рендер и глубина везде берется из G-buffer. А на статике для мягкой воды и партиклов ее можно бесплатно получить напрямую из буфера глубины (чтобы не делать предварительный проход по глубине, на котором можно потерять до 20% фпс). Легко начиная с дх10, сложнее на дх9 (там нужно формат буфера глубины другой выставлять). И забирать ее нужно до начала рендера прозрачных объектов (r_dsgraph_render_sorted), к каким относятся вода и партиклы, тогда их не будет в нашей текстуре глубины, что необходимо для расчетов, а также они просчитаются в шейдере в текущем кадре.

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

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

Zagolski, а почему статика? Почему просто не допилить ДХ11, прикрутив к нему ПБР, нормальные отражения и прочие моднявые штуки?

Zagolski, я про тени

Статику я взял за основу как forward render, переделав ее в полноценный. Можно было сразу R4 переделать, но ведь опыт тоже нужно получать.
Отложенный рендер (динамика) мне не нравится, он во многом ограничен (для моих потребностей точно), прямо так все моднявые штуки на нем нелегко сделать. И сам по себе нагроможденный. Сейчас у меня на forward фпс на 50-100% выше при такой же картинке, что и на ванильном R4 (причем с глобальным фонгом), MSAA 4x (включая сглаженный альфа-тест) всего на 10% фпс снижает, двойной рендер на оптике вообще фпс не снижает (на отложенном фпс вдвое ниже), плюс беспроблемные модели в интерфейсе вместо иконок, которые сразу из UI на отрисовку отправляются. И что главное, можно легко любой PBR сделать и не один, и имеется качественная обработка полупрозрачных объектов. Планирую его позже на forward+ дорабатывать.
А отложенный рендер - это как кастрированный слон, как по мне. Сейчас, кстати, некоторые начинают обратно на forward переходить, отложенным наигрались видимо.
А на родном отложенном то тут затык, то там. То городить приходится огород. Плюнул и переделал на forward. Зато теперь без всяких проблем разные интересности делаются. Вот сейчас собираюсь наконец за полноценные отражения отраженной камерой браться.


В r4_R_render.cpp есть такое:
// Directional light - fucking sun
if (bSUN)
{
...
Поставь туда доп. условие навроде if (bSUN && Device.dwFrame&1), будут только по нечетным кадрам тени от солнца рендериться. И еще запрети на этих кадрах также render_lights (их там два), а то тени от ламп будут забивать текстуру карты теней (она общая используется). Только смотри, чтобы утечек не было по свету от ламп, там чуть выше они сортируются и окклюзия по ним обрабатывается (ее тоже возможно придется блокировать на нечетных кадрах). По-хорошему нужно не сам свет отключать, а только тени от него (в r2_R_lights.cpp). И лучше разделить текстуру теней (r2_RT_smap_depth) на 2 отдельные текстуры (одна для теней от ламп, вторая для теней от солнца), но тут за два присеста не сделать...

Попытки разделить Spot и Direct... Осталось понять, как слить два сурфа в один для конечного прохода...

Тот дефолтный s_smap оставь для теней от ламп, но создай новый s_smap_direct и на нем отдельно рассчитывай тени от солнца. В r4_rendertarget_phase_smap_D.cpp достаточно сменить установку RT на новый и его же очищай. Ну и выведи в семплер его в блендере (blender_light_direct.cpp) вместо старого. А в шейдере рассчитывай отдельной ф-цией, не shadow, а какой-нибудь shadow_direct (или лучше добавь в старую передачу семплера, чтоб копий не городить). В итоге тени от солнца обработаются в отдельном ZRT и все так же запишутся в rt_Accumulator.

Но проще вообще это ничего не делать, а просто также и тени от ламп создавать через кадр. В этом случае ничего отдельного делать не нужно. А чтобы все было корректно, на тех кадрах, где не создаются тени от солнца, отправляй лампы не в LP.v_shadowed, а в бестеневые LP.v_point и LP.v_spot. Для этого в CLight_DB::add_light на нечетных кадрах меняй принудительно всем лампам флаг на L->flags.bShadow = FALSE (до export). Тогда они при последующей сортировке окажутся в нужных package и отрисовка теней для них не сработает.

Zagolski, в целом я делал всё тоже самое, только наоборот выносил споты. Однако шейдеры не трогал. Добился света директора, только они мерцали. Но да ладно. Добью потом.

Zagolski, так у тебя статические тени или динамические? Или и то, и другое вместе? Залил бы скринов нормальных, чтобы все посмотрели

Выложил бы исходники форвард+ р1 на дх11 - вот это разговор бы был.
Хотя и так не плохо - можно теперь говорить, на хрее легко делается форвард+ и пбр

Динамические трехкаскадные. Статические тени я вырезал. Оставил бы, но добивался возможности юзать локации скомпиленные на драфте. Т.е. у меня не нужно компилить локи по 8 часов, достаточно 5 минут. Все освещение динамически вычисляется в игре. Правда, пока это дело в процессе доработки.

Вообще я хочу спец. алгоритмами и оптимизациями вычислять тени гораздо более высокого качества, у меня на тенях бзик. Основное - это расчет не каждый кадр и распределение вычислений по частям по кадрам. Плюс еще можно разделить тени от статических объектов и динамических (первые можно совсем редко обновлять). Уже пробовал делать статическую 16к (или 8к, запамятовал) карту теней с обновлением раз в сек, все нормально (вот тут ее лучше по кадрам по частям создавать). Но для быстродвижущихся объектов в любом случае нужно через кадр-два делать (если еще сильнее затормозить, то ГГ на спринте или вороны в небе начинают заметными рывками тени отбрасывать).

Хотя нынешний вариант с созданием теней через кадр сейчас прекрасно работает давая +25% к фпс (если делать через 2 кадра, то прибавка +50%), чем я очень доволен. Как раз за счет этого выигрыша внедрил предварительный проход по глубине и SSAO/HBAO. Получились считай бесплатные.


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

Tile-based/clustered должно помочь, помню видел где-то демку - tile-based ds vs tile-based forward... не помню итог только.. вроде от сцены зависит..

А твой р1 так на дх10 и работает или уже дх11. И почему на дх10 было легче портировать? Или на самом деле без разницы?

Сначала на дх10, потом на дх11. На самом деле без разницы, там различия оказались минимальные между 10 и 11. С шейдерами пришлось повозиться.

Пара советов, которые помогут повысить фпс при создании 3D оптических прицелов (двойной рендер). Так как на ванильном отложенном рендере не получится снизить разрешение картинки из-за G-buffer, чтобы выиграть существенно скорости (линза прицела все равно часто занимает лишь пол экрана, для нее достаточно половинного разрешения), но все равно можно выиграть прилично скорости.

1. Переносим отрисовку худа раньше самой сцены. Это можно сделать отключив сплит сцены (активировав параметр r2_exp_splitscene и запретив его). Но тут я не знаю, как это скажется на скорости, у меня вроде фпс не упал (на динамике там окклюзия рассчитывается). В этом случае при прицеливании будут отбраковываться фрагменты находящиеся за прицелом, а это считай половина сцены. При этом на линзу необходимо обязательно повесить не прозрачный шейдер, иначе эффект сойдет на нет. Выигрыш фпс - до 20%, причем даже просто, когда в руках оружие. Кстати, на статике худ изначально первым рисуется.

2. Поскольку линза у нас круглая, нам не нужно рендерить боковые части картинки. На отложенном рендере динамики отбросить боковины сложнее - нужно установить трафарет при втором проходе. На статике достаточно установить aspect = 1.

3. На втором проходе нет нужны повторно отрисовывать тени, данные по ним берутся из первого прохода. Это существенно повышает фпс.

4. Ну и если у вас forward render (например, статика), то для второго прохода можно и нужно использовать половинное разрешение экрана. Со всем этими махинациями у меня полностью ликвидировалась просадка фпс при просмотре в линзу, а в некоторых случаях фпс даже повысился. И все это без потери качества картинки в линзе.

а что будет, если tex_depth станет меньше 0.5f?

depth уйдет в минус.

я бы к depth применил clamp() или saturate()

и к знаменателю второго уравнения тоже, потому как far не факт что будет больше near, что загонит знаменатель в минус.

Если far станет меньше near, скорее всего игра вылетит еще на этапе калькуляции сцены, ну то есть такого в принципе быть не может.
tex_depth - это выборка из текстуры буфера глубины. И происходит как раз перегон в диапазон от -1 до 1, что необходимо.

depth = lerp( -1.f, 1.f, tex_depth );

не?

Зы. А еще рассказывает про оптимизацию

Не надо ничего мудрить. Формула абсолютно корректная и полностью работоспособная.

Zagolski, так lerp это ж линейная интерполяция из диапазона в диапазон. Он скорее всего прав.

У нас все это depth = tex_depth * 2.f - 1.f; делается. Простейшее декодирование из диапазона 0...1 в диапазон -1...1. Никаких лерпов и клампов тут применять не нужно.

Вот она красава:


Честные отражения, т.е. можно видеть, например, днище моста.

Это как? Сейчас же доступны только ScreenSpace-отражения?..

Как как, сел, да и закодил честные. Давно собирался, все никак руки не доходили. SSR я еще в том году из ОГСЕ перетащил, поигрался с ними, да и забраковал. В движке Дизеля они должны быть.
Тут на скринах они еще не доработаны, слишком выраженные. Да и в половинном разрешении их желательно делать, плюс искажения от волн усилить.

На какой рендер?

На статику.

Честные = вторая камера?

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

Теперь на очереди нормальные намокания сделать с дождем, типа таких:
https://www.youtube.com/watch?v=JHEkn8mtbVk...eature=youtu.be
Но тут сразу чувствую, что придется попотеть.

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

Блин, я и не думал, что честные отражения будут так классно в Сталкере смотреться. Взгляд не оторвать.


В намокании главное реалистичные круги от капель дождя, как по мне. В сильный дождь вода по идее вообще бурлить должна. Ну и конечно же блеск с отражениями. В ЗП с кругами совсем плохо. Круги есть, но их не видно совсем. Я помнится их усиливал, причем заметно, но артефакты в виде полос поплыли.

В воде главное шейдер и освещение: https://gfycat.com/decentcoordinatedgrison
А во время дождя в сталкере больше не хватает луж, имхо, (пример шейдерных луж с маской). В OGSE вроде есть лужи, но там просто приподнимается плоскость с водой, насколько мне известно.

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

Я сам не знаю что у меня есть?

Типа это DX8- R1 отражения - у меня таких шейдеров твоих не было.

дх11- R1.
Да я про огсе-шные отражения имел в виду, которые SSR.

Этим ты меня окончательно завел в тупик. Я в R3 -dx10 не разобрался, а тут еще и такое.

Это сейчас возможно интегрировать в ОЛР, ЛА или в любой из трёх релизов.
Хочу просто побегать, посмотреть.

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

А как в той игре сделано, чей видос выше скидывали? Такое ощущение, что есть некая карта намоканий/луж (по типу карты шейдеров плавных переходов асфальт-земля в сталкере), в местах где лужа нарисована, отрисовывается эта лужа с мягкими краями.



Я думаю воду можно в целом затемнить, а отражения немного размыть по гауссу.

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

Вроде что-то путное вышло в более-менее конечном итоге:

Как ты всё это делаешь? Возможно ли перенос на ТЧ?

Дайте билд...

Это только разработчики могут точно сказать. Вообще можно попробовать сделать карту луж, как в ЗП сделана карта дождя. И по ней уже что-то придумывать. А лужи делать на базе карты глубины, искать места с вмятинами в ландшафте и их заполнять водой или эффектом воды. Чтоб все это на автомате делалось без вмешательств со стороны. Я уже давно собираюсь лужами заняться, только не как в ОГСЕ, а полностью динамические. Вот как раз на днях планирую засесть. Не знаю насчет результата, посмотрим что выйдет.


У меня все сделано и делается на forward render (я спецом на него переделал для своего проекта), а на динамике с ее deferred rendering и половину сделать сложно, если вообще возможно, или результат будет давать низкую производительность.
Когда сорцы движка выложу, к тому времени он еще больше обрастет, тогда любой мод ТЧ-ЗП (по крайней мере ванили точно) можно будет без проблем перенести на этот рендер. Будет типа R5 с forward+ и дх12.
Но это после релиза своего проекта (NLC7:HSM - помесь НЛС, тарковской оружейки-апгрейда и симуляции выживания в Зоне).

Наверное лучше это будет сделать на этапе сборки уровня.

K.D. 2.0

Zagolski, Planar-reflection? Y-высота для отражаемой поверхности вручную указывается или в реальном времени находится \ другой метод?

Поработал с рябью (дисторсия отключена), получилось конечно реалистично, но красота отражений заметно портится из-за рваных искажений (хотя красивости часто "враг" реалистичности). Но это максимальная рябь. Ей еще не мешало бы блики добавить. Впрочем, нужно просто динамически менять силу ряби в зависимости от ветра. Днем сильнее, на восходах и закатах можно совсем убирать, выставляя практически чистое зеркало. Или вообще динамически в зависимости от порывов ветра, будет гнать рябь по волнам. Да, надо бы еще волны сделать по Фурье.


Он самый. Только наоборот более производительный, чем SSR (по крайней мере по сравнению с огсе-шным).
В данный момент отражается банально от 0 координаты. Но поскольку вся вода на уровне расположена именно там (видимо у GSC были четкие указания следовать этому правилу), то оказалось, что и так порядок. Но тут тогда придется располагать свою воду только на нуле по Y. При этом не получится ни лужи сделать, ни дамбы, где вода может быть выше/ ниже нулевого уровня. Так что по-любому нужно дорабатывать, получать данные о Y-позиции плоскости воды и от нее отражать. Здесь сложный момент, потому что тех же луж может быть несколько и они могут располагаться на разных высотах. Но тут можно и несколько раз отрендерить без падения скорости, ведь на лужах у нас будет очень малый frustum.