В ТЧ вроде два near/far, поэтому не так сильно лагает. Больше плотность/дальность сажает.


У меня на макбуке 17 года, на какой-то версии системы, шахматы все 4 ядра загружали на 100% и ноут пытался всё это дело охладить своими турбинами Это к слову о говнокоде.

Да, в ТЧ два каскада - на 20 и 180 м. Если мы делаем к примеру дальность травы 150 м, то эти 150 м идут в первый каскад, где больше 20 м не требуется (остальные 130 впустую производительность жрут). А в ЗП три каскада: 9, 40 и 160. Так там 141 м впустую в первом тратятся, 110 м во втором.
Нужно для каскадов подготавливать траву исходя не из камеры игрока, а из позиции солнца, откуда тени создаются. Ну а вместо фрустума камеры использовать фруст каскада. Правда, в этом случае будет подготавливаться трава и за игроком, которую он не видит. Но это меньшее зло. К тому же для теней так положено, хотя не для травы, потому как она мелкая. Поэтому ее можно также обрезать фрустом камеры дополнительно.

Вроде это в UpdateVisibleM(), где вместо vCameraPosition нужно использовать cull_COP (из r2_R_sun.cpp), а вместо mFullTransform использовать fuckingsun->X.D.combine
Перед каждым
Details->Render () ;
в тенях солнца вызываем
UpdateVisibleM()
но переделываем его типа того: UpdateVisibleM(cull_COP, fuckingsun->X.D.combine)
Да, и возможно в cache_Update тоже придется менять.

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

Зачем вообще на дальних каскадах отрисовывать траву? Не проще сделать отрисовку теней только на ближнем/ближних каскадах и сделать fading, чтобы резко не пропадала на отдалении от камеры?

Можно и не делать, да. Но на ближнем каскаде у нас как раз идет самый большой overdraw, если можно так выразится. Когда на отрисовку отправляется 150 м травы, а на выходе получается только 20 (для ТЧ near). Итого 130 м обрабатывается впустую. Смысл всей затеи, чтобы и отправлять на отрисовку тоже 20 м, в итоге получить существенное снижение падения фпс от теней травы.

Идеальный говнокод, это террабайтный, требующий больше видеопамяти и оперативки, чем имеется, дико тормозящий и глючащий, классический чёрно-белый Тетрис.

Справедливости ради - оба варианта доступны к реализации и на дх9 и на дх11. С разницей в том, что первый вариант на дх9 ты разумеется не через кс будешь делать, а по классике через вс+пс. Второй вариант совпадает по коду процентов на 90, но если кого-то вообще интересует мое мнение, я бы рекомендовал на дх11 заюзать вот это https://docs.microsoft.com/en-us/windows/wi...exture2d-gather , код будет несколько лаконичней, но да кому какое дело вообще до рефакторинга когда-то было . За статический рендер сталкера конечно конкретно ничего не скажу, не видел его, сказал только конкретно про кулинг и мипмапы.

и немного некропостинга


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


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

Вчера ради интереса прикрутил у себя ЧН-овский рендер с фабрикой. До этого у меня был прикручен рендер из ЗП. Так вот когда бегаешь по тем же местам в игре, на которых ты долгое время бегал на другом рендере, разница очень отчетливо бросается в глаза. Далее я буду писать про чн-овский R3 и зп-шные R3-R4 (визуально меж зп-шными разницы нет, кроме тесселяции на R4). Пока выявил следующее:

1. Ну во-первых на чн-овском не создается кэш шейдеров, что очень удобно при разработке, не нужно его все время чистить (на ЗП его можно отключить, но все равно).
2. На ЧН рендере качественнее палаллакс, больше объемность. Ну там и в шейдерах алгоритмы немного разные. А может просто в ЧН он есть на тех объектах, где в ЗП его убрали для оптимизации (порезали).
3. Самое главное, на ЧН рендере качественнее MSAA. На ЗП они все подпортили (видать для очередной оптимизации), не разбирался почему, но часть сцены не сглаживается вообще (на некоторых объектах остаются лесенки). Подозреваю, что это из-за msaa detect edge. На ЧН рендере сглаживаются полностью все объекты, в целом сцена выглядит куда качественнее со сглаживанием.

Zagolski, прикрути лужи с отражениями, как у Анонима на АМК. Ты же шаришь.
Кстати, мне скинули шейдеры от какого то мода dwm ЗП. Там лужи реализованы.
https://vk.com/doc368229470_519071257?hash=...78b8b2e05cdc1e4

Я сижу и туплю, у меня ЧН, у меня вообще по-другому.

Я пока за лужи и капли не брался, по другому дел полно. Хотя недавно пробовал прикрутить новые капли (то что ты ранее видео выкладывал). Что сказать, профит есть, но в таком обычном виде их оставлять нельзя. Они очень плохо на земле заметны (впрочем, как и родные капли). Нужно усиливать глосс на каплях, какой-нибудь фонг туда повесить. А без этого очень плохо смотрится, из-за плохой их заметности.

Zagolski, а можно ли опробовать ваш форвард плюс рендер? Интересно же.

Еще не доделано. Я его отложил пока, все это время пилил очередной двиг для нлс7, переделывал его в чн-зп. Планировал на тройку дней, а засел на пару недель. Сейчас к F+ надо опять возвращаться.

К слову, F+ не такая уж панацея, как это на картинках детям на ночь показывают. На практике все неоднозначно. Он тормознее обычного рендера при наличии стандартного кол-ва источников света в кадре (3-8). Из-за фазы отбраковки. Да, он может держать очень много лайтов, но есть ли такое кол-во света в игре? Вот в чем вопрос. Так что реакция на форвард+ глазами простого игрока может быть скорее отрицательная, чем положительная, из-за снижения фпс. Хотя он все равно быстрее ванильного деферреда.

Вот мне и интересно насколько он быстрее

От сцены зависит, от железа. Точно тут ничего не скажешь. У меня прирост на каких-то сценах чуть ли не вдвое, но в среднем около 25%. Причем лучше всего в сталке на дх11 показал себя простой форвард, как самый быстрый. Там около 50% прибавки в скорости. Но с кое-какими важными оптимизациями, к примеру с переносом расчета освещения для flat альфа-теста в вершинный шейдер. Либо с препассом альфа-теста.

MLAA можно и на GPU сделать, кстати.
Мне больше нравится TAA 4х, быстрый и качественный. Ничего лучше не нашел в плане соотношения качество/ цена. В идеале лучше заюзать связку TAA + MSAA (TXAA по такому же принципу сделан), но тут уже из-за MSAA в скорости потеряем (тем более на отложенном рендере), да и лишних проблем в конвеер привнесем. Поэтому на деферред вместо MSAA лучше юзать MLAA. А так да, в такой связке сглаживание идеальное получается, взгляда не оторвать.

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

Есть идеи, где искать причину?

Отбой. Нашел. Это шейдеры партиклов (... и не только).

Странность обновления цикла погоды

xrModder, cтандартная ошибка


Вращение через sky_rotation делаешь?

Просвети меня


Да, точнее sky_rotation_v - вращение SkyBox по координату X.

У тебя в последней секции вращение 330, в первой 0. Вот движок честно и вращает от 330 до 0 = против часовой стрелки. Надо доработать, как фрегат, чтобы вращение шло по меньшей дуге.

Не знаю, не знаю... Цикл разделено на 24 часа, по 15 градусов. Хз из-за чего такой баг.

С 330 обсчитался, 345 конечно.
В первой секции же sky_rotation_v = 0? Вот, когда погода меняется с последней секции на первую, и получается переход от 345 до 0.

Есть какой-нибудь способ исправления "обнуления" цикла погоды?

Я думаю надо в движке углы чуть по-другому обсчитывать, если больше или равно 360 то обнулять и поворачивать в сторону с меньшим углом (но тут надо предусмотреть и обратную ситуацию когда с 360 до 0 крутим).

xrModder, абрам все по делу сказал, дополню его ответ и скажу свое решение. Во-первых это не баг, а тригонометрия, во-вторых как выше верно отметили небо крутится назад так как у тебя небо крутится от 345 до 0 (например), чтобы не крутилось нужно соответственно крутить 345 360 375 и т.д. до бесконечности. Я решил эту проблему под свои нужды следующим образом (мне надо чтобы просто куб по кругу ходил сутки и все), берем ротейшн первой секции и сравниваем его не больше ли он двух пи (так как он нам его в радианы переводит), и вторую секцию соответственно проверяем меньше двух пи, если подпадают секции под это условию, то ставим скай ротейшн форсед, в противном случае меняем плавно как обычно. Вот и все решение, четыре строки кода. Если нужны другие механики работы, то просто дорабатываешь формулу под свои нужды, ничего сложного там вроде вообще нету, код надеюсь не потребуется, это все таки до 9 класса в школе проходят .


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

Загольский, кстати, ты говорил что ты оптимайз г-буфера переделывал? Чо там менял? И еще я тут форвард чучуть попрограмил, скажи как ты там чо оптимизировал? Мне в голову пришло только упаковка четырех трехкомпонентных векторов в три четырехкомпонентных. Опять же там усложняется математика, но это классика для шейдерных оптимизаций. Интересны твои подходы, можно без конкретного кода, просто общую идею, думаю пойму. Форвард коеш такая себе тема, шаг влево шаг вправо и ботлнек, в сталкере все таки за отложик я бы свой голос отдал. И еще вопросец небольшой тени под пцф не переделывал (дх10 и выше онли)?


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

Вообще по шейдерам большой разговор на деле. Я бы на самом деле занялся полным рефакторингом в свойственном мне стиле. Может есть желающие присоединится? Там можно все не только привести в порядок, но еще и неплохо думаю выйдет заоптимизировать, правда возможно немножко придется переделать пайплайн в области формирования константных буферов. Мне бы еще до конца разобраться чо за треш там с регистрами сделан, так на вскидку типа можно выгонять несколько переменных с одним именем и они ушиваются в массив, типо выгоняем две разных матрицы и типа можно получать значения как-то так my_matrix[0][2][2]. Кто в шейдерах сталкерских сечет помогите разобраться или лучше давайте вместе чонить замутим, польза же всем будет .

И да, ссао/хбао на кс надо кому? Я тут чучуть шейдеры пытаюсь програмать .

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

а можно об этом по-подробнее для тех кто ноль в графике?


И про макет, если не затруднит, тоже? Быстрое гугление ничего не дало


Очень спорно.


HBAO+ лучше и быстрее, но я не помню тонкости его лицензирования.

Мне лучше подождать лишние 2 сек загрузки, чем постоянно после каждого пука чистить кэш. Кроме того, сам драйвер должен кэш создавать, но тут я без понятия, как это работает.
Запусти локу на ЧН с параллаксом и ту же локу на ЗП с параллаксом, посмотри разницу.


TAA + MSAA.


На ЗП с G-buffer не надо ничего делать, с включенной оптимизацией (gbuff_opt) он и так хорош. Хотя можно все же улучшить. Нормаль и хеми перенеси в одну DXGI_FORMAT_R8G8B8A8_UNORM. Позицию из г-буфера вырежи, сделай отдельный проход после заполнения г-буфера и из ZB вытащи глубину в отдельную f16 (в линейную переведи). С материалом что-то придумывать надо. Я пробовал кодировать нормаль в DXGI_FORMAT_R10G10B10A2_UNORM, туда же хеми и в 2 бита материал (4 значения, больше толком и не нужно). Сталкерское освещение к точности нормали не сильно привередливое. Еще можно накопление света перенести в DXGI_FORMAT_R11G11B10_FLOAT вместо DXGI_FORMAT_R16G16B16A16_FLOAT. В целом, улучшить можно.


Там нечего оптимизировать, в сталке форвард только на статике. Можно тот же R4 переделать в форвард. Немного шейдеров переписать и сам конвеер. Правда, много возни будет с переделкой источников света, они для деферред заточены. И освещение для всех flat объектов (как минимум трава и листва) переводи на вершинный шейдер, иначе будет дикий овердроу.


Так они и на ваниле PCF 4х4. На макс. качестве солнца используется алгоритм вытащенный из DXSDK (контактные тени или как-то так), по сути PCSS, только более тормозные (я где-то тут выкладывал улучшенный этот алгоритм). Разве что семплов на обычный можно нарастить.


Я у себя пофиксил. Там в движке куча msaa-шного кода - это было сделано для DX10, чтобы в шейдерах циклы не использовать. На DX11 используется SV_SAMPLEINDEX с вытаскиванием семпла за один раз, поэтому можно всю эту кучу кода вырезать.


В сталке что-то вроде HBAO+ используется, как мне кажется. Точно не обычный HBAO. Там текстура полного разрешения + идут каскады по глубине. И он быстрее обычного SSAO, и качественнее. Но мне больше вставил HDAO, классная штука.

Кстати, используйте HDAO исключительно на ультра, только там он обрабатывается вычислительным шейдером, что быстрее (по крайней мере у меня).

Там разница между HBAO+ и HDAO чисто субъективная, основной момент - это заточенность под определенное железо.
HDAO заточено под AMD.
HBAO+ заточено под Nvidia.


И я все еще в недоумении по поводу термина "макет", и возможности "написать свой самплер"

Это в Оригинале не видно. Но я на статике вижу такое.


А блин - это же безлайтмапная зона. Типа там шейдера виноваты?

Дефолтный метериал глючит на статике, так как нет лайтмап?

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

Как оказывается, да. Давича был разговор на эту тему с маппером Терра Инкогнита.

Проводятся некоторые тесты с новым рендером 11.4 (самосозданный, без копи-пасты с ЧН/ЗП).
Trollz0r,
не прав.

Тут с Сталкере они заметно различаются визуально. HBAO как и SSAO затеняет довольно большими областями, а HDAO только мельчайшие впадинки и углубления. Особенно стильно HDAO здесь с детальным бампом смотрится. Я его раньше не использовал, даже вроде и не включал (думал, то же самое), а оказалось, что совсем другое на вид. Действительно высокой четкости вышло. И при этом еще самое быстрое на ультра.

Признаюсь честно - я HDAO никогда не использовал.
Из разговоров с другими разработчиками, и из общей информации о HDAO - он быстрее на AMD, и медленнее остальных методов на Nvidia

Если не секрет - о какой версии Сталкера вы говорите, и на каком GPU тестировали?
Захотелось самому глянуть разницу и посмотреть на производительность.

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


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

ЗП и GTX660. Сильнее выгода на ультра заметна при включенном MSAA.


Я у себя так делал. Выхлоп не менее 5-10% прибавки фпс (от bandwidth зависит) и глюков с освещением худа не заметил. Может ты неправильно как-то линеаризировал или позицию восстанавливал? Но тут надо разобраться. Вообще там только fov меняется, near и far plane одинаковые.

Косячит только худ, всё остальное в принципе нормально работает. Скорее всего из-за fov и выглядит иначе.

Zagolski,
все бы оно хорошо. К каким-то высказываниям, чисто иногда, показывать скриншоты необходимо. Что-то мне попадалось из твоих скриншотов (не для сети), т.к. поле действий наш Сталкер. Мне они понравились, труд очень важный, если он касается оптимизации с улучшением качества визуальной детализации. Но тут же я показывал свои работы, сделаны они куда быстрее, в движках, рендерах и шейдерах ни в зуб ногой. Я провел от силы час над одной работой и добился таких же результатов, причем их не прячу в закромах, а показываю, чтобы мои действия подкреплялись фактами. И самое смешное из всего этого, я все это скриншотил на дряхлых, мохнатых рендерах, кривых шейдерах и бог его знает еще чего. Свою часть работы быстро провел, лишь проанализировал, чем будет отыгрываться мои поделки.
Пару скриншотов, которые еще не сожрал фотохостинг:
Было_________________________Стало
vs
vs
И это оригинал стулкера. Я уже боюсь и представить, если все эти поделки "на коленке" закинуть в ваши работы по рендерам и шейдерам.
Можно конечно взять и другие объекты, которые не сильно подвергаются улучшению:
Было__________________________________________ Стало

И да, было, это с реалистик чего-то там мода. Лучшее из лучшего для сравнения выбрал.

А где потом этот новый созданный с нуля рендер можно будет созерцать?

guitarking123,
там же, где и проводятся тесты- ТИ.
Мой выше ответ скорее понятен Дизелю, т.к. я очень вырвано ответил. Разговор идет о лайтмапах и динамическом освещении, а также про компиляцию локаций без лайтмапов, что сильно сокращает время.

Вспомнил. Было же видео - https://youtu.be/UqKCBdBYqIk
Крайний рендер не показывает финального качества. Для этого нужно довести шейдеры до полного ума под новоиспеченный рендер. Результаты оптимизации и освещения меня уже радуют.
***
Хотелось бы и от других авторов такой же информативности. Ладно с видео, ладно с скриншотами. Но без циферек вообще никак.

ed_rez, Первые скрины со стеной совсем не понравились, все стало плоско и убился детальный бамп. А вот грузовик шикарен. Ты у него бамп переделывал, и только?


О каких скриншотах речь?

Прикольно. Вот вроде и дх11 рендер сами написали, а зпшная коричевность все равно заменила тчшную синеву.

Именно это я и делал. Я никогда не видел такого кирпича, как в случае "было". Также, проводил опросы, как лучше, что предпочтительнее для игры и что желают видеть игроки стулкера. Опрос показал, что они также видят кирпич. Без шишек, а гладкий и шершавый. В общем, главное, чтобы не переливался и ух точно не давал отблеска. Не это важно. Мне важна ваша информативность. Мне интересно подготавливать материал опираясь на новые наработки по рендеру и шейдерам. И дело совсем ни в "нравится" или "не нравится", а в том, что получаю на выходе на лохматом рендере и кривых шейдерах.

Таки да. Малость с текстурой ЗИЛа повозился, но совсем малость. Поэтому она стала более сочная. Но на это не нужно смотреть. В этом сравнении суть работы бампа. Не диффуза. Понятное дело, что параллакс не включал. Он нафиг не нужен на транспорте.


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

Любых. К примеру, как было в оригинале, не меняя текстур (!) и как стало после проведенных работ тобою над рендером и шейдерами. Результирующую. Как мне понять, как подготавливать исходный материал на будущее?

Понятно, что не сложно. Просто упор был на "самозданный без копи-пасты". Жалко костер в кадр не попал

abramcumner,
еще сложно судить о финале. Я в своей теме на АМК информировал как-то по DX11.4. Меня радует одно, что мои текстуры взяты за основу, чтобы настраивать рендер и шейдеры. Мои работы прошли "огонь, воду и медные трубы" и если было бы что-то сделано не так, в техплане, то выявилось сразу. Но не об этом.
Мне главное результаты. Больно я щепетильный в вопросах оптимизации, но и не дам спуска в визуальной составляющей. Понятное дело, что есть свои предпочтения в освещении, но они отодвигаются на вторичный план. Я для себя сам настрою, как мне нравится. Задача передать все плюсы и как можно меньше при этом, прихватить минусов.
А сам передаю то, что сказано в диалогах. По факту же станет все ясно, когда выйдет релиз, а он выйдет. Присутствует копи-паста или нет. Глупейшая ситуация будет, если это не правда. А еще точнее, это будет подставой для других, кто взял за основу этот проект и создание сюжетной линии. Мы взрослые люди. И что-то мне подсказывает, что "меряние писюнами" тут ни к месту.
Да и вообще, тут много негатива на счет ОГСЕ, понимаю. Копирайты- это правило в моддинге. Но также важна конечная работа, которая нашла игрока, других модмейкеров.

Это просто забавный факт, ничего более. Что дескать взяли тчшный р2, саморучно перенесли его на дх11 и получили коричневость из зп. Хотя по логике шейдеры(кстати не факт что коричневость из-за шейдеров, а не констант в движке или смолскаев) наверное тоже должны быть тчшные р2 и тогда должна синюшность получиться, разве нет?
Но конечно это было сделано специально, правда не могу придумать зачем. Ведь изначальный посыл был, чтобы сделать не так, как в ЗП

Никакой подставы в копипасте нет - это абсолютно нормальное и полезное явление.


Негатива нет. Есть всем доступный репозиторий, в котором четко видно, когда что было сделано. И есть секретный подвал. Да, секретчикам приходится тяжело.

Я понимаю так, со всеми шейдерными приблудами по типу SweetFX или ENB, то от шейдеров и складывается освещение. Я не трогаю погоду, ибо она была ЗП-шная в ранней версии, также и солнце. Следовательно погода и солнце ЗП тут не причем.


Вот и я о чем. Этот 11.4 рендер начали делать из-за моих просьб. Хотя меня убеждали, что хватает модифицированного DX9.
Автору зачем врать про копи-пасту!?

Синюшность бывает от качества компиляции локации. От терайн-текстуры, в папке левел, может зависеть.
Возмите эту текстуру и обычным конвертером dx5 прогоните. Будет блестеть как у кота яиса, и синюшность пропадёт.