Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Графика, рендер, шейдеры
GAMEINATOR forums > S.T.A.L.K.E.R. > Мастерская: создание модов для S.T.A.L.K.E.R.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91
cjayho
QUOTE (Zagolski @ 09.01.2020, 16:39) *
QUOTE (cjayho @ 09.01.2020, 16:46) *
с фотки пипеткой что ли?

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


В спавочниках солнце - смесь источников с разной цветовой температурой - само солнце (6000К, с учетом фильтрации атмосферой получается 1400-6000К в зависимости от угла над горизонтом), рассеянный и фильтрованный облаками солнечный свет (порядка 3000...4000К), отраженный облаками солнечный свет, рассеянно-фильтрованно-отраженный атмосферой солнечный свет (7000-15000К).
Это без учета переотражений между освещаемыми объектами.

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

Единственное что - солнечный свет отраженный от облаков имеет цветовую температуру выше чем свет самого солнца, из-за того что облака освещаются солнцем совсем под другим углом.
Zagolski
Ну вот. Так GSC что-то подобное в настройках погоды использовали или брали цифры от балды? Если второе, то можно как-то реальные данные в погодные конфиги попробовать загнать.
RedMagic
Zagolski, https://en.wikipedia.org/wiki/Color_temperature
cjayho
QUOTE (Zagolski @ 09.01.2020, 17:46) *
Ну вот. Так GSC что-то подобное в настройках погоды использовали или брали цифры от балды? Если второе, то можно как-то реальные данные в погодные конфиги попробовать загнать.


Ну судя по тому как я распинаюсь тут то я загонял.
Получалось кстати весьма недурственно, просмотрите первый десяток страниц этой темы.
DRKIP
Всем привет. Распаковал all.spawn. Хотел добавить флары. Сделал как писал уважаемый KD. Не получилось. Движок OGSR x64. Кто разбирается в этом вопросе подскажите как сделать. Заранее огромное спасибо. Все что нужно скину. Использую ТЧ. all.spawn измененный.
Fizzed
Цитата(DRKIP @ 12.01.2020, 12:40) *
Всем привет. Распаковал all.spawn. Хотел добавить флары. Сделал как писал уважаемый KD. Не получилось. Движок OGSR x64. Кто разбирается в этом вопросе подскажите как сделать. Заранее огромное спасибо. Все что нужно скину. Использую ТЧ. all.spawn измененный.



Hey. Looks like you are using latest version of OGSR - that one contains CoP renderers, without KD stuff like lens flares, lens dirt.
You need to use older versions of OGSR engine.
Zagolski
Немного сглаживания для сравнения (.png)
1 - Без сглаживания
2 - TAA 2x
3 - TAA 4x
4 - MSAA 4x + ATOC

cjayho
QUOTE (Zagolski @ 16.01.2020, 01:43) *
Немного сглаживания для сравнения (.png)


как по мне то вторая картинка наиболее сглаженная
ed_rez
На мой любительский взгляд, то 4 вариант самый оптимальный, причины:
1. сглаживание предельное, как на 3. На 1-ом "лестница" по проводу, на 2-ом меньше;
2. четкость теней на 1-ом и 4-ом. На 2-ом и 3-ем заливаются артефактами- мелкая крошка;
3. на 2-ом и 3-ем картинка разваливается на пиксели- наполнена мелкой крошкой. На 1-ом и 4-ом выглядит естественнее и более сглажено.
RayTwitty
Zagolski, 4 вариант больше понравился.

Картинка на 2-3 скринах светлее из-за рандомной погоды (облаков которые кидают тень на землю)? Или спецэффекты применения сглаживания?
sergy172
Цитата(RayTwitty @ 16.01.2020, 14:54) *
Картинка на 2-3 скринах светлее из-за рандомной погоды (облаков которые кидают тень на землю)? Или спецэффекты применения сглаживания?

Там вроде бы включен эффект киноплёночного зерна.
Fizzed
Hello.

I want to ask about rendering part of XRay.
What is proper way to render previous frame + previous position?

Zagolski's work inspired me to try TAA, but i'm stuck with previous frames stuff.
cjayho
QUOTE (Fizzed @ 16.01.2020, 18:15) *
Здравствуйте.
Хотел бы узнать по части рендера XRay.
Каков правильный путь рендеринга предыдущего кадра и предыдущей позиции?

Работа Zagolski побудила меня попробовать TAA, но я остановился на моменте предыдущих кадров.


i'd like to know this too :-)
because this way gives not only TAA, it gives proper way to make motion blur and light trails without ugly hacks.

--

я бы хотел это тоже узнать smile.gif
потому что таким способом можно получить не только TAA, но и правильный способ создания размытия в движении и световых следов без применения костылей
Zagolski
Цитата(sergy172 @ 16.01.2020, 17:54) *
Там вроде бы включен эффект киноплёночного зерна.

Да. В игре шума почти не видно, при этом он улучшает четкость, а вот на скринах шум очень заметен.

Цитата(RayTwitty @ 16.01.2020, 14:54) *
Картинка на 2-3 скринах светлее из-за рандомной погоды (облаков которые кидают тень на землю)? Или спецэффекты применения сглаживания?

Просто яркость увеличена на 25%.

Цитата(cjayho @ 17.01.2020, 17:03) *
потому что таким способом можно получить не только TAA, но и правильный способ создания размытия в движении и световых следов без применения костылей

И не только это. Еще сглаженные четкие тени, отражения, SSAO, сглаженный второй рендер для 3д оптики и др. И все это почти бесплатно.

Цитата(Fizzed @ 16.01.2020, 19:15) *
What is proper way to render previous frame + previous position?

Получаем мировую позицию текущего кадра и преобразуем ее при помощи матрицы VP предыдущего кадра (ниже код для ЗП с вкл. оптимизацией g-buffer).

Код
float linearDepth = s_position[pos2d].z;
float3 viewPosition = float3( linearDepth * ( pos2d * pos_decompression_params.zw - pos_decompression_params.xy ), linearDepth );
float3 worldPosition = mul(m_v2w, float4(viewPosition, 1.f));
float4 prevClip = mul(m_VP_prev, float4(worldPosition, 1.f)); // m_VP_prev - это Device.mFullTransform (RCache.xforms.m_vp) предыдущего кадра
prevClip.xy /= prevClip.w;
float2 prevUV = prevClip.xy * float2(0.5f,-0.5f) + 0.5f;
float4 prevColor = s_prev_color.SampleLevel( smp_nofilter, prevUV, 0 );
RayTwitty
Цитата(Zagolski @ 18.01.2020, 01:37) *
Просто яркость увеличена на 25%.

Понятно. Впрочем я думаю, сравнение надо делать на одном наборе. И да, если зернистость это неизбежный спецэффект такого сглаживания, то имхо такое сглаживание в топку. Сглаживание должно сглаживать, а не менять оттенки и в целом картинку (для этого есть другие эффекты).
Zagolski
Цитата(RayTwitty @ 18.01.2020, 02:37) *
если зернистость это неизбежный спецэффект такого сглаживания, то имхо такое сглаживание в топку
Впрочем я думаю, сравнение надо делать на одном наборе

Да нет, шум сам по себе визуально четкость улучшает, на любой картинке. Причем в игре его и не видно из-за динамики. Сейчас шум везде делают, как неотъемлемый компонент постпроцессинга. А для TAA шум очень желателен, потому как этот тип сглаживания часто мылит картинку.
А так вообще да, нужно было везде одинаково делать. Допишу FXAA и сделаю с ним еще линейку скринов без шума и с одинаковой яркостью, также добавлю туда к базовому TAA с мылом TAA без мыла.
RayTwitty
Кто-нибудь в курсе, за что именно отвечает этот дефайн в шейдере common.h?

Код
// Defines
#define def_gloss half(2.f /255.f)

Делал сравнительные скрины при значениях 2.f/255.f и 8.f/255.f - разницы в глоссе текстур (бликов) от того же костра не заметил. Или этот "глосс" за что-то другое отвечает?
Diesel
RayTwitty,

// 1. Base texture + kill pixels with low alpha
// 2. Standart output

Второй вывод.
Часто на альфа-тест ссылается. По всей вероятности DX10.1 туда.
Zagolski
Цитата(RayTwitty @ 20.01.2020, 02:13) *
Кто-нибудь в курсе, за что именно отвечает дефайн def_gloss в шейдере common.h?

Для бампов спекуляр берется из текстуры (R канал), а для объектов без бампа (в т.ч. и трава) вместо него используется это значение.
Zagolski
Хочу представить на суд общественности варианты SSLR отражений. Сложно понять, что лучше использовать.
На скринах представлены сырые отражения, т.е. без заполнения отверстий (заполняется отражением скайбокса) и каких-либо блюров. Хотя используется временный фильтр TAA 4x в обоих случаях. Также стоит принять во внимание фпс. Все скрины в .png. Видяха - Nvidia GTX 660.

Без SSLR


HiZ трассировка, итерации: 128, 64, 32, 24, 16


Линейный марш луча в скринспейсе с бинарным поиском, итерации: 128, 64, 32, 24, 16, + во всех случаях 6 итераций уточнения. Также здесь использован сдвиг луча на каждом кадре, что вкупе с TAA дает неплохую фильтрацию.


Как по мне, HiZ конечно дает четкое отражение и качественное, тонкие объекты не пропускает, но напрочь рушится с малым кол-вом итераций. Кроме того, сложно получать с его помощью размытые отражения при высокой шероховатости.
Обычное марширование вкупе с джиттерингом и TAA способно выдавать приемлемое изображение даже с низким кол-вом итераций, что дает существенный плюс и в целом хорошую масштабируемость.
При этом при одинаковом кол-ве итераций (в линейном даже на 6 больше) фпс в обычном выше, чем в случае с HiZ.
Где профит?
Yara
Цитата(Zagolski @ 22.01.2020, 13:51) *
Хочу представить на суд общественности варианты SSLR отражений. Сложно понять, что лучше использовать.

Тут либо второй скрин с хиз, либо первый с линейной и привести размытие к такому виду:





abramcumner
Цитата(Zagolski @ 22.01.2020, 10:51) *
Где профит?

Бессмысленно их в таком виде сравнивать. Эти скриншоты только iOrange показать для ревью.
Заблюривай и все такое, тогда уже можно будет сравнивать картинку.

Добавь еще твой старый метод(с двумя камерами?). Там же сразу будут крутые отражения?
И тот странный амкашный сслр, он прикольный smile.gif
Zagolski
Цитата(Yara @ 22.01.2020, 13:11) *
Тут либо второй скрин с хиз, либо первый с линейной и привести размытие к такому виду:

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

Цитата(abramcumner @ 22.01.2020, 13:13) *
Бессмысленно их в таком виде сравнивать. Эти скриншоты только iOrange показать для ревью.

Тут как раз именно в сыром виде отличия наиболее сильно видны, после постобработки разница слабее заметна. Тут главное - разница между HiZ и линейной.
Вот тут первый HiZ 64 итерации, второй - обычный 64. Блюра и прочего нет. Видно, что во втором случае джиттер + TAA хорошо заполняют дыры.


Цитата(abramcumner @ 22.01.2020, 13:13) *
Добавь еще твой старый метод(с двумя камерами?). Там же сразу будут крутые отражения?

Тот метод только для плоских объектов, даже для ванильной воды с небольшой рябью уже не подойдет. Только если для утренней воды с гладью. Но опять же только для воды или зеркал, блестящего пола. Для окружения, каких-либо округлостей этот вид отражений использовать нельзя, некорректно будет смотреться. Только SSLR, а все его косяки маскировать.
iOrange
Цитата(Zagolski @ 22.01.2020, 09:51) *
Хочу представить на суд общественности варианты SSLR отражений.

Ну вот тут хоть видно что это SSLR а не гадание на кофейной гуще wink.gif

Цитата(Zagolski @ 22.01.2020, 09:51) *
Сложно понять, что лучше использовать.

Ну если у вас отражения только в воде - то SSPR однозначно зарулит все (http://remi-genin.fr/blog/screen-space-pla...econ-wildlands/)

Если современное generic рещение - то SSLR с ускорением по HZB.

Цитата(Zagolski @ 22.01.2020, 09:51) *
HiZ трассировка, итерации: 128, 64, 32, 24, 16

Это максимальное ограничение на итерации? Там же в алгоритме досрочный выход если уперлись. В целом HZB метод у меня всегда однозначно быстрее был чем обычный маршинг. То что сейчас бегает - планка 32 шага для 1080p.

Цитата(Zagolski @ 22.01.2020, 09:51) *
Кроме того, сложно получать с его помощью размытые отражения при высокой шероховатости.

Одно к другому никак не привязано. SSLR (вне зависимости от алгоритма) лишь способ найти пересечение. Для рафнеса префильтруйте RT перед вычиткой.
Вообще все современные движки имеют порог рафнеса, где вместо SSLR просто пропускается, и остается только envprobes выборка (которых, я так понял, в Сталкере нет).

Если не секрет - алгоритм для HZB шагания - ближе к Killing Floor статье, или статье Autodesk ? Или (надеюсь нет) вообще из GPU Pro ?
Zagolski
Цитата(iOrange @ 22.01.2020, 17:50) *
Ну если у вас отражения только в воде - то SSPR однозначно зарулит все

Мне не особо понравился. Он самый быстрый и качественный, но зараза сочетает в себе минусы как планарного (только для плоских объектов), так и SSLR (отсутствие информации). Даже при небольшой ряби (мини-волны на нормалях) на воде уже нет того чувства, что это отражения, т.е. они не играют, не живые, а чувство натянутой на воду текстуры, как и у планарных. Их хорошо на дальней дистанции использовать, где уже не видно "игры света". Или на воде в рассветную тишь. А так у меня отражения на всю сцену делаются, поэтому отдельно применять два "дырявых" алгоритма не хочется.

Кстати, по поводу SSPR не подскажешь, что за артефакт такой в виде сетки?

Он есть и на вычислительном шейдере и на пиксельном. Фильтрация никакая не используется при выборке текстур. Не могу понять, откуда это вообще и что это. Или сам UAV так шалит? Хотя больше нигде я подобного не встречал. Текстура UAV 32-битная UINT (разные пробовал). Причем сетка искривляется подобно перспективе и вся ровная, ячейка к ячейке.

Цитата(iOrange @ 22.01.2020, 17:50) *
Если не секрет - алгоритм для HZB шагания - ближе к Killing Floor статье, или статье Autodesk ? Или (надеюсь нет) вообще из GPU Pro ?

Autodesk. Хотя он по сути слегка исправленный GPU Pro. Я и из GPU Pro пробовал, у него артефактов больше, а по скорости такой же. Линейный сам писал.
iOrange
Цитата(Zagolski @ 22.01.2020, 18:31) *
Кстати, по поводу SSPR не подскажешь, что за артефакт такой в виде сетки?

Больше похоже на проблемы со снаппингом (когда мы ищем клетку в которую шагнуть, но иногда мы уже стоим на границе клетки, и тогда пересечение дает нашу же. Но у Autodesk с этим вроде борятся в статье, уже не помню подробности.)

Цитата(Zagolski @ 22.01.2020, 18:31) *
Даже при небольшой ряби (мини-волны на нормалях) на воде уже нет того чувства, что это отражения

Согласен, просто они быстрые и неплохие + можно прикрутить фейковые отклонения в духе старого dudv (считать от нормали) и будет норм. Особенно для такой игры как Сталкер biggrin.gif
atanda
Цитата(iOrange @ 22.01.2020, 19:53) *
Особенно для такой игры как Сталкер

А можно отражения на затылке Сидоровича?
iOrange
Цитата(atanda @ 22.01.2020, 19:00) *
А можно отражения на затылке Сидоровича?

RTX ON biggrin.gif
Zagolski
Цитата(iOrange @ 22.01.2020, 17:50) *
Это максимальное ограничение на итерации? Там же в алгоритме досрочный выход если уперлись. В целом HZB метод у меня всегда однозначно быстрее был чем обычный маршинг. То что сейчас бегает - планка 32 шага для 1080p.

У тебя 32 итерации с маршингом за объектами, когда луч под ними проходит? В этом случае у меня в 32 совсем не умещается. Особенно если это ветки-листва, между которых нужно промаршировать, тогда труба, тут как раз особенно итерации поедаются... sad.gif
SkyLoader
Цитата(Zagolski @ 22.01.2020, 10:51) *
HiZ трассировка, итерации: 128, 64, 32, 24, 16

А это нормально, что -30 фпс при 32 итерациях? Алгоритм правда такой прожорливый?
Zagolski
Тут зависит от видеокарты, да и от начального фпс без отражений. Если бы он был к примеру 60, а не 118, то и падение было бы где-нибудь до 50. Сам по себе SSLR кушает примерно как SSAO.

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

Собственно, это подтверждает и автор материала:
Цитата
Unfortunately this often means that the traced rays travelling behind a surface degenerate into a linear search and the cost can skyrocket for these traced pixels


А если маршинг за объектами отключить, тогда фпс с HiZ немного возрастает. Но качество отражений заметно страдает, такие задаром не нужны. Впрочем, отключение маршинга за объектами в линейном тоже хорошо увеличивает фпс. В общем, основные проблемы от объектов вроде веток и листвы.
iOrange
Цитата(Zagolski @ 22.01.2020, 23:34) *
У тебя 32 итерации с маршингом за объектами, когда луч под ними проходит?

32 это кап, т.е. если в 32 не уложились - выходим. У нас нет столько растительности, SciFi и прочее.
Т.е. в моем случае - чаще всего лучу надо проходить много пустого пространства, поэтому HZB вариант намного быстрее ибо быстро его прошагивает.
Zagolski
Попробовал провернуть рейтрейсинг в сталке на дх11. Саму трассировку еще не делал, пока только voxelization. На фпс не обращайте внимание, потому как каждый кадр, да и сама отрисовка воксельной сетки на экран очень много жрет. Ну а так начало положено.
iOrange
Увидел воксели подумал ты LPV прикручиваешь.

А для трейсинга BVH лучше, ты задолбешься воксели трейсить.
RayTwitty
Zagolski, вокселизация нужна для упрощения трассировки? То есть мы как бы с ней работаем потом, а не с реальной геометрией?

З.Ы. майнкрафтеры прильнули к экрану biggrin.gif
iOrange
Цитата(RayTwitty @ 25.01.2020, 02:12) *
То есть мы как бы с ней работаем потом, а не с реальной геометрией?

Смотря что он пилит. Может Voxel Cone Tracing. Для обычной трассировки геометрия нужна, от вокселей толку не будет.
Zagolski
Цитата(RayTwitty @ 25.01.2020, 03:12) *
вокселизация нужна для упрощения трассировки? То есть мы как бы с ней работаем потом, а не с реальной геометрией?

Не для упрощения, а вообще для трассировки. Мир вокселизируется в буфер и трассировка происходит не по полигонам и не на CPU, а по вокселям на GPU. Можно сказать, что это почти аналог RTX, только воксельный, не требует новых API и специальной видеокарты с поддержкой RTX. Вот простой пример от Crytek:
https://youtu.be/1nqhkDm2_Tw

Цитата(iOrange @ 25.01.2020, 03:26) *
Может Voxel Cone Tracing.

Да, VCT, на котором можно и индирект делать, честные отражения и даже трассировать тени. В общем, так называемый SVOGI (SVOTI), который я пытаюсь пилить.

Цитата(iOrange @ 24.01.2020, 23:10) *
А для трейсинга BVH лучше, ты задолбешься воксели трейсить.

Сейчас это не для моего ума, я в трассировке начинающий, еще не изучал этого зверя.
Zagolski
Вот такая система рейтрейсинга получается:



Тут без освещения и воксель крупноват, но тем не менее отражения на затылке у Сидоровича имеются. Да и фпс неплох, я думал будет хуже.
iOrange
Цитата(Zagolski @ 25.01.2020, 11:57) *
В общем, так называемый SVOGI (SVOTI), который я пытаюсь пилить.

Во-первых - это очень похвально, молодец. Без шуток. bravo7kg.gif

Но я все же немного попридираюсь к формулировкам если ты не против. Ну уж такой я человек wink.gif

Цитата(Zagolski @ 25.01.2020, 11:57) *
это почти аналог RTX

Цитата(Zagolski @ 25.01.2020, 11:57) *
Вот простой пример от Crytek:

Нет, даже не близко. RTX, и то что в демке от Крайтек - это именно рейтрейсинг - т.е. полноценные пересечения лучей и геометрии.
Трассировка конуса по вокселям - это, по сути, просто попытка определить "апертуру" исходной точке. Этого вполне хватает для GI (можем прикинуть баунс и перекрытие).

Цитата(Zagolski @ 25.01.2020, 11:57) *
честные отражения и даже трассировать тени

Вот тут прям совсем нет - отражения ты с помощью VCT не получишь никак, сорри. Тени нормальные тоже нет.
Уточнюсь - я про праймари тени, низкочастотные вторичные перекрытия - это то для чего VCT и делался, именно та самая "апертура".

Чтоб не было обид - повторюсь - то что ты делаешь это круто и очень похвально. Даст очень хороший результат для GI.
Просто бросилось в глаза что ты несколько раз назвал это "рейтрейсингом". wink.gif
Zagolski
Да вроде то же самое, только тут по полигонам рейтейсишь, а там по вокселям. Принцип ведь тот же. Хотя конечно в случае с вокселями ее можно и реймаршингом назвать. На вокселях конечно не получишь качественных четких отражений, но размытые вполне себе можно.
Тут у них вроде как отражения получились на VCT: https://www.ogre3d.org/2019/08/05/voxel-cone-tracing

Мне сначала у Крайтека как-то странно показалось, как они смогли четкие отражения на voxel raytracing получить... Но как я понял основа одна - воксельная (SVO используют), т.е. они по вокселям рейтресят, а затем уже из вокселя по ссылке достают данные полигона, текстуры или чего-то там. А как еще в реальном времени честно рейтрейсить, да еще при сохранении фпс 30-40? На CPU это нереально, думается мне. А по геометрии на GPU - это только RTX.
RayTwitty
Нашел тут у себя в закромах несколько эффектов постобработки.

Стилизация картинки Battlefield 3
Код
    half3 vLum = half3(0.33, 0.59, 0.11); // brightness
    half3 ColorGradingParams2 = half3(0.4980392, 0.6745098, 0.7882352); // color
    half fLum = dot(img.xyz, vLum);
    half3 cMin = 0;
    half3 cMed = ColorGradingParams2;
    half3 cMax = 1.0;
    half3 cColor = lerp( cMin, cMed, saturate(fLum * 2.0) );
    cColor = lerp( cColor, cMax, saturate(fLum - 0.5) * 2.0 );
    img.xyz = lerp( img.xyz, cColor.xyz, saturate(fLum * 2.0) );

Насколько я помню, цветокоррекция была сделана K.D. и я получил ее задолго до выхода OGSE. Дальше я просто стилизовал ее на свой вкус.
Кстати кто следил за разработкой Phantoms Zone, возможно помнят, что эти скрины я выкладывал в 2013 году с припиской "Альтернативный рендер" biggrin.gif
Скриншоты


Фильтр контраста
Код
    float3 highcontrast = img.xyz*img.xyz;
    img.xyz = lerp(img.xyz, highcontrast, CONTRAST_FILTER);

Тут всё просто и понятно. CONTRAST_FILTER - это дефайн с float-числом. Можете определить его или вбить константу прямо в код. Автор тоже K.D.

Всё это добро активируется в файле r2\combine_2_naa.ps, код (по отдельности или всё вместе) нужно засунуть над
Код
return     combine_bloom        (img,bloom);


З.Ы. Копирасты наверняка нагуглят эти коды где-нибудь в инете и начнут писать мол K.D. тут не причем. Сразу скажу, что мне пофигу - для меня автор в данном случае тот, кто код предоставил, искать первоисточник предоставлю задротам wink.gif
iOrange
Цитата(Zagolski @ 26.01.2020, 00:20) *
Тут у них вроде как отражения получились на VCT

Так тут сцена 5х5 метров, воксели крохотные. Синтетика. На реальных уровнях у тебя размер вокселя будет такой, что эти отражения ты не захочешь wink.gif
Ну для высокого рафнесс - там да, пойдет, но дешевле будет env probes самплить, имхо.

Цитата(Zagolski @ 26.01.2020, 00:20) *
как они смогли четкие отражения на voxel raytracing получить

Потому что у них там не VCT. Там такой же стохастический алгоритм как и в Battlefield 5, только на компьютах. Отлично видно на крутящихся зеркалах.
Тот же BVH, та же трассировка. Все что дает тебе RTX - это удобный API, callable shaders и хардварный интерсектор wink.gif
cjayho
QUOTE (RayTwitty @ 26.01.2020, 00:26) *
Нашел тут у себя в закромах несколько эффектов постобработки.

<--->

З.Ы. Копирасты наверняка нагуглят эти коды где-нибудь в инете и начнут писать мол K.D. тут не причем. Сразу скажу, что мне пофигу - для меня автор в данном случае тот, кто код предоставил, искать первоисточник предоставлю задротам wink.gif


Хреново - писать шейдеры с помощью контрол-це-контрол-вэ, совершенно не понимая о чем вообще идет речь.

CODE
    half3 vLum = half3(0.33, 0.59, 0.11); // brightness // cjayho: LUMINANCE_VECTOR из common.h юзать несудьба?
    half3 ColorGradingParams2 = half3(0.4980392, 0.6745098, 0.7882352); // color
    half fLum = dot(img.xyz, vLum);
    half3 cMin = 0; // cjayho: используется ниже только один раз
    half3 cMed = ColorGradingParams2; // cjayho: что за бред?
    half3 cMax = 1.0; // cjayho: используется ниже только раз

    // cjayho: три лерпа ниже это слижком злобное колдунство, особенно первый и третий, но фиг с ним, он художник он так видит
    half3 cColor = lerp( cMin, cMed, saturate(fLum * 2.0) );
    cColor = lerp( cColor, cMax, saturate(fLum - 0.5) * 2.0 );
    img.xyz = lerp( img.xyz, cColor.xyz, saturate(fLum * 2.0) );


легким движением превращается в нечто более лаконичное без потери функционала:

CODE
    
    half3 ColorGradingParams2 = half3(0.4980392f, 0.6745098f, 0.7882352f); // color
    half fLum = dot(img.xyz, LUMINANCE_VECTOR);
    half3 cColor = lerp( 0.f, ColorGradingParams2, saturate(fLum * 2.f) );
    cColor = lerp( cColor, 1.f, saturate(fLum - .5f) * 2.f );
    img.xyz = lerp( img.xyz, cColor.xyz, saturate(fLum * 2.f) );


----

CODE
    float3 highcontrast = img.xyz*img.xyz; // cjayho: возводим цвет во вторую ступень
    img.xyz = lerp(img.xyz, highcontrast, CONTRAST_FILTER); // лерпим от первой до второй ступени


один вопрос - зачем, если можно просто

CODE
img.xyz = pow( img.xyz, CONTRAST_FILTER+1.f );
Zagolski
img.xyz*img.xyz быстрее чем pow.

Странность обнаружил, что SSLR на воде в отложенном режиме (отражения считаем через квад и карту нормалей воды) дает порядком больше фпс (общий на ~5% выше), чем если мы рассчитываем SSLR в форварде, т.е. сразу при редеринге воды. В последнем случае вода рендерится уже поверх остальной геометрии как непрозрачный объект и с принудительным ранним z-тестом, там по-любому овердро быть не может. Тогда почему, спрашивается? Единственное объяснение, что приходит мне на ум, так это то что овердро все равно где-то просачивается.
iOrange
Цитата(Zagolski @ 27.01.2020, 23:42) *
Единственное объяснение, что приходит мне на ум, так это то что овердро все равно где-то просачивается.

Вода многополигональная? Если шейдер тяжелый - овершейд на гранях полигонов может сказаться.
Собственно поэтому даже для полноэкранных эффектов все перешли на full-screen triangle вместо квада.
Zagolski
Вода очень низкополигональная, овершейда какого-либо заметного там точно быть не может. А здесь аж на целых 5-6% разница в скорости, что непомерно много. И неясно, из-за чего. Такое впечатление, что ранний z-тест не до конца работает, хотя спецом [earlydepthstencil] включено. Может он на таких сверх огромных полигонах воды и не работает толком?
iOrange
Цитата(Zagolski @ 28.01.2020, 01:04) *
Вода очень низкополигональная, овершейда какого-либо заметного там точно быть не может

Сетку бы увидеть
cjayho
QUOTE (Zagolski @ 27.01.2020, 23:42) *
img.xyz*img.xyz быстрее чем pow.


а если еще lerp-ом сверху шлифануть?
Zagolski
Цитата(iOrange @ 28.01.2020, 04:35) *
Сетку бы увидеть

То что я выше на скринах с SSLR показывал озерцо у избушки - это вот это:


А так вода вот такая:


Цитата(cjayho @ 28.01.2020, 18:51) *
а если еще lerp-ом сверху шлифануть?

Это надо на практике смотреть.
Diesel
Цитата(Zagolski @ 29.01.2020, 23:58) *
А так вода вот такая:


Это что за багавая вода? Это реально не оригинал. Не могут ПЫСы такой геом замутить.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.