Графика, рендер, шейдеры Опции

[=Diablo=]

Разбор полётов

SSLR & Puddles | Lens Flares | Отложенный рендер ландшафта | Исправление паковки gbuffer'a | Шейдерные константы (Кто допилит - с меня печенька)

Работы участников

Шейдеры от Diablo

Шейдеры из билда 2232 под финалку.
До

После


Скачать

Наработки cjayho

ECB Shaderpack
Официальный репозиторий

Описание

ECB-Shaderpack
Улучшенный набор шейдеров для игры S.T.A.L.K.E.R.: Shadow of Chernobyl
_____________________________________________________________________________
Основные возможности:
_______________________
1) Непрозрачный туман на R2, возможность переключения
из файла конфигурации прозрачный/непрозрачный туман
2) Исправлена "синюшность" изображения на R2
3) Эффект компенсационного светового следа на R2
4) Статический и динамический Depth of field на R2,
Размытие объектов при прицеливании (требует дополнительного скрипта)
5) Билдовский блум с краснинкой на R2, возможность
переключения тонмаппинга в режим, который был в билде 2218
6) Screen space ambient occlusion на R2
7) Правильная отрисовка сияния ламп на R1
8) Правильная отрисовка солнечного градиента на обоих рендерах
9) Полноценная отрисовка occlusion-lightmaps на R2
10) Микроструктурный бамп
11) Правильная отрисовка бликов на блестящих поверхностях
12) Автосатурация - попиксельное уменьшение насышенности слабо
освещенных объектов
13) Мягкие тени на R2
14) Экспериментальная возможность - правильные тени от деревьев на R2
15) Улучшенный Motion blur, более похожий на билдовский
16) Исправлена "кислотность" (перенасыщенность) солнечного освещения объектов на R2
17) Отражабельная вода на R2
18) GodRays на R2 + эффект пылинок в лучах.
19) Мягкие партиклы на R2
20) Мягкая вода на R2

Плюс множество регулировок и исправлений мелких недостатков обоих рендеров
Условия использования
_______________________
Данный продукт предоставляется под соглашением Creative Commons CC-BY 3.0,
Подробнее описано по адресу http://creativecommons.org/licenses/by/3.0/deed.ru
Составитель данного набора шейдеров - cjayho
Свежие ревизии находятся по адресу http://code.google.com/p/ecb-shaderpack/downloads/list
Установка
___________
Данный продукт тестировался под версиями игры 1.0004 и 1.0006
Установка сводится к копированию файлов в папку gamedata мода,
изначальный набор файлов предназначается для чистой игры. В случае
установки погодных модов необходимо правильно совместить файл
config/weathers/flares.ltx

Для более полной настройки шейдеров R2 под свой мод можно править файл
shaders/r2/config.h.
Для корректной работы теней нужно установить следующие переменные
в игровой консоли:

r2_sun_near_border 1
r2_sun_near 20

Благодарности
_______________

Sergy172 за идеи и тестирование экспериментальных веток.
-=Diablo=- за изначально портированные шейдеры из 2232
macron за отражабельную воду и наборы шейдеров из билдов 2217 и 2588
Билдоман за набор шейдеров из билда 2571
BAC9-FLCL, KamikaZZe за дельные замечания и критику
Shadows за неоценимую помощь в разработке и тестирование экспериментальных версий
Meltac <metzinger@gmx.net> (Его мод "Dynamic shaders" здесь: http://www.moddb.com/mods/dynamic-shaders)
за алгоритм Depth of Field. Код DoF используется с его разрешения.
Sky4CE за алгоритм SSAO
K.D. За алгоритмы мягкой воды, мягких партиклов, GodRays

Скриншоты

Скриншоты (Shadows Addon 0.6 Edition)

Скачать все наработки | Зеркало
Наработки ECB Team распространяются под условиями Creative Commons CC-BY.

Правки рендера от K.D.

Подходит как к чистой игре, так и к любым модам.

Изменения

- саншафты (команда r2_sun_shafts off/low/medium/high)
- мягкая вода (команда r2_soft_water on/off)
- мягкие партиклы (команда r2_soft_particles on/off)
- регулировка дальности отрисовки травы через консоль (r__detail_radius [49, 501])
- расширенная регулировка плотности травы (r__detail_density [0.02, 0.6])
- расширенная регулировка четкости текстур (r1_tf_mipbias/r2_tf_mipbias [-3.0, 3.0], только R1/R2)
- расширенная регулировка расстояния переключения на лоды (r__geometry_lod [0.1, 3.0])
- восстановлены тени от травы (r2_sun_details, R2)
- восстановлены блудмарки (r2_bloodmarks, R1/R2)
- правильные тени от солнца (R2)
- увеличенный видеобуфер (фикс ошибки "(bytes_need<=mSize) && vl_Count" на R2, связанной с перегрузками видеобуфера*)

* То есть теперь можно на полной динамике загрузить ресурсоёмкую карту типа болота из ЧН, поставить видимость в 4 километра и взрывать вокруг дымовые гранаты с ЧНовскими партиклами дыма (тоже жутко ресурсоёмкие).

Скриншоты

Мягкие партиклы (до и после)

Установка: закинуть содержимое в папку с установленным ТЧ (6 патч, более ранние патчи не поддерживаются и просить сделать под них аналогичное бессмысленно!)
Настройка: смотрите ogse_config.h
Нюансы:
- мягкая вода работает и без бинарников
- экзешник нужен для пыли в саншафтах и правки вылета перегрузки видеобуфера. Он основан на выложенным в свое время официальном экзешнике для 6го патча без защиты (отсутвие starforce).
- рендер-библиотека обеспечивает работу консольных команд, пыли в саншафтах и мягких партиклов.
Использование: где и как угодно. Не возбраняется указать автора.

Скачать
Часть наработок еще здесь

Сообщение отредактировал ForserX - 21.07.2020, 13:58

[Zagolski]

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

Код

HRESULT    CreateConstantBuffer( ID3DBuffer** ppBuffer, UINT DataSize)
{
    D3D_BUFFER_DESC desc;
    desc.ByteWidth = DataSize;
    desc.Usage = D3D_USAGE_DEFAULT;// D3D_USAGE_DYNAMIC;
    desc.BindFlags = D3D_BIND_CONSTANT_BUFFER;
    desc.CPUAccessFlags = 0;// D3D_CPU_ACCESS_WRITE;
    desc.MiscFlags = 0;

    HRESULT res = HW.pDevice->CreateBuffer( &desc, 0, ppBuffer);
    //R_CHK(res);
    return res;
}

Код

void dx10ConstantBuffer::Flush()
{
    if (m_bChanged)
    {
/*
        void    *pData;
#ifdef USE_DX11
        D3D11_MAPPED_SUBRESOURCE    pSubRes;
        CHK_DX(HW.pContext->Map(m_pBuffer, 0, D3D_MAP_WRITE_DISCARD, 0, &pSubRes));
        pData = pSubRes.pData;
#else
        CHK_DX(m_pBuffer->Map(D3D_MAP_WRITE_DISCARD, 0, &pData));
#endif
        VERIFY(pData);
        VERIFY(m_pBufferData);
        CopyMemory(pData, m_pBufferData, m_uiBufferSize);
#ifdef USE_DX11
        HW.pContext->Unmap(m_pBuffer, 0);
#else
        m_pBuffer->Unmap();
#endif
*/
        HW.pContext->UpdateSubresource(m_pBuffer, 0, NULL, (BYTE*)m_pBufferData, 0, 0);
        m_bChanged = false;
    }
}

Сообщение отредактировал Zagolski - 02.12.2019, 07:59

[Fizzed]

Здравствуйте.
Я работаю над рендерером 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.

[Zagolski]

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

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

[rentgenluch]

и тем самым разгружаем на дипах проц (профит ~10%).

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

[BD194]

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

Я же писал:

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

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

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

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

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

[Fizzed]

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

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

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

[Diesel]

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

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

[Zagolski]

А вообще сам хорошо сравнивал до и после?

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

Сообщение отредактировал Zagolski - 04.12.2019, 05:10

[-StalkMen-]

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

[iOrange]

UpdateSubresource - асинхронная, в то время как Map/Unmap считай синхронизирует ЦП-ГП

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

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

[iOrange]

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

Все что вы писали я вам чуть ли не побуквенно ответил. Ничего внятного от вас не последовало, толко новые наборы рандомных слов.

> и именно для этого я запускал ртшник для блюра чтобы скрыть и отвести взгляд игрока от них
Простите, что вы запускали? При чем здесь блюр при обсуждении SSLR?

[Zagolski]

С какими флагами Map/Unmap делался? С Discard будет отдан новый буффер, никакой синхронизации не будет.

Да, флаг D3D11_MAP_WRITE_DISCARD.
Если взять к примеру структуризированный буфер с кол-вом элементов этак в 250 000, то в итоге с Map/Unmap получим 100% синк и заметное падение фпс. UpdateSubresource в этом случае четко отрабатывает, проблем нет, хоть и поболее грузит GPU. Но в целом для ординарных случаев я за Map/Unmap.

Win 10, GTX 1050ti. А какой у тебя конфиг? Мб от видеокарты зависит.

GTX 660. А проц i7-2600K до 4.5 ГГц разогнанный.
Скорее всего у тебя просто в проц не упирается, поэтому и разницы нет. Нужна сцена, где в проц упирается. Такую можно обнаружить по неполной загрузке GPU. Хотя на чисто ванильном R4 куча QUERY_OCCLUSION на лайтах и вдобавок QUERY_EVENT на каждом кадре от инпут лага, поэтому такую сцену непросто будет найти.
В void CRender::Render() почти в самом начале есть такой кусок кода:

Код

    if (1)
    {
        CTimer    T;                            T.Start    ();
        BOOL    result                        = FALSE;
        HRESULT    hr                            = S_FALSE;
        //while    ((hr=q_sync_point[q_sync_count]->GetData    (&result,sizeof(result),D3DGETDATA_FLUSH))==S_FALSE) {
        while    ((hr=GetData (q_sync_point[q_sync_count], &result,sizeof(result)))==S_FALSE)
        {
            if (!SwitchToThread())            Sleep(ps_r2_wait_sleep);
            if (T.GetElapsed_ms() > 500)    {
                result    = FALSE;
                break;
            }
        }
    }

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

Сообщение отредактировал Zagolski - 05.12.2019, 09:48

[eagleivg]

Простите, что вы запускали? При чем здесь блюр при обсуждении SSLR?

Блин, я извиняюсь что влезаю, но ты исходник-то смотрел? Такое имя файла как gauss5.ps тебе что-нибудь говорит?

[RayTwitty]

При чем здесь блюр при обсуждении SSLR?

Я думаю он имел ввиду, что отражения блюрятся так, чтобы мелких косяков заметно не было По крайней мере, то что показывали выше в видео по лужам меня совершенно не смутило - выглядит классно, может где-то что-то и косячит, но с вероятностью 99% игрок этого не заметит. Я вообще поражен, в ходе выпуска различных модов, насколько игроку похеру на некоторые вещи. Иной раз, нужно просто дизаблить управление и тыкать его туда, что хочешь чтобы он увидел

За исключением конечно ваномасов - они будут в бинокль рассматривать каждый пиксель.

[iOrange]

с Map/Unmap получим 100% синк

Он не так работает, с дискардом синк не будет, ибо драйвер видя Discard бросает текущий буфер и дает из пула тебе новый, и помечает себе сделать свап на следующем sync point.

UpdateSubresource в этом случае четко отрабатывает, проблем нет, хоть и поболее грузит GPU

А метрики точны? UpdateSubresource должен больше грузить CPU, ибо он выполняет дополнительную работу.

Рекомендую почитать советы IHV - https://developer.nvidia.com/sites/default/...nt_McDonald.pdf

[iOrange]

Блин, я извиняюсь что влезаю, но ты исходник-то смотрел? Такое имя файла как gauss5.ps тебе что-нибудь говорит?

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

Я же среагировал на фразу которую даже выделил жирным - запускал ртшник для блюра
Меня заинтересовало что такое ртшник, не более.

[Zagolski]

А метрики точны? UpdateSubresource должен больше грузить CPU, ибо он выполняет дополнительную работу.

В параллельном потоке, возможно. Он все же асинхронный. Главное то, что в сталке он малость снимает нагрузку на CPU на вызовах отрисовки. Я только это замерял. А на них как раз основной затык и часто в проц упирается, когда геометрии много. К тому же в сталке 4-х ядерный проц максимум на 2 ядра грузится, половина простаивает.

Меня заинтересовало что такое ртшник, не более.

Наверное, он имел в виду рендер-таргет, тут в движке они как rt помечаются.

По крайней мере, то что показывали выше в видео по лужам меня совершенно не смутило - выглядит классно, может где-то что-то и косячит, но с вероятностью 99% игрок этого не заметит.

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

[iOrange]

Он все же асинхронный.

Ну так же как и Map/Unmap. Примерно так они работают:

С UpdateSubresource:
- Драйвер выделит в сторонке память, скопирует твою дату в эту память.
- Засунет команду на копирование памяти в command buffer
- Вставит барьер на доступ к ресурсу, чтоб дождаться если его юзают
- После барьера GPU скопирует дату в ресурс

C Map/Unmap (+ discard):
- Драйвер выделит в сторонке память, отдаст тебе указатель
- Ты скопируешь туда свою дату
- После Unmap драйвер поставет команду на копирование памяти в command buffer
- Вставит барьер на доступ к ресурсу, чтоб дождаться если его юзают
- После барьера GPU скопирует дату в ресурс

В твоем случае небольшое ускорение могло быть вызвано более грамотным копированием, реализованным в драйвере.
Я использую Streamed SIMD memory copying, и у меня разницы в целом в скорости не было между обоими, но я все же предпочитаю следовать советам IHV, ибо в будущих драйверах все может измениться.

[BD194]

его вкинул автор для отвода темы от основного вопроса

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

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

[iOrange]

А у вас понимания нет "от слова совсем". Вы лишь пытаетесь казаться каким-то профи, но в моих глазах у вас это не получается.

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

Но да ладно, подозреваю что что такое SSLR вы слабо понимаете, нагуглили статью на Хабре, скопировали код, получилось плохо, но отстаиваете это копипасту как родную. Бывает.

И тут мы подходим к основному:

И какой это основной вопрос такой?

Если отмотать целиком назад, то это был не вопрос а утверждение - на видео не SSR. Я готов на это деньги поставить.

Основные места обведены красным, слева на право:

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

Бетонная хрень по средине - тот "алгоритм" который вы тыкали мне - не сможет даже в ужасный SSR, не говоря уже о том что здесь черезчур много деталей для него, и - обратите внимание - опять таки из-за другой камеры получилось "заглянуть" снизу и увидеть забор между "ногами" постройки.

Столб справа - опять же - другая камера + отсутствующая тень на заборе (сверху она есть).

Попробуйте мне доказать что это SSR.