Без понятия. Взял ОГСР, вытянул папку shaders из игров. архивов. Создал свою папку gamedata, сделал правку в файле.


Запаковал. Сначала глянул, как в ориг. ОГСР, затем закинул игровой архив с правкой в папку. Файл ниже, чем другие (это так, на всякий). Глянул, как с правкой. Чтобы легче было понять отличие, то снимок делал с одно позиции. При каждом запуске, сначала удалял папку shaders_cache. Настроек не менял! Мне что, видео снимать?
Я в шейдерах не в зуб ногой. Зато вижу отличия одного от другого в сравнении. Не нужно 7-мь пядей во лбу иметь, чтобы сделать выводы по сравнению. Откуда берется сглаживание и прочее, ответ выше про мои знания шейдеров.


Это понятно. Представление имею, что такое настройка материалов в СДК. Но разговор был о ландшафте, а детали летят на иных материалах. Я не делал сравнения по террейну.

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

Кстати, вот оптимизация. Переводим на траве и листве альфа-тест на билинейку вместо анизо. В файле deffer_base_aref_flat.ps ищем ф-цию tbase и во всех местах переписываем ее. К примеру, вот это

заменить на

Фпс существенно возрастет (до 10%), особенно когда много травы/ листвы. Минус - визуально слегка листва погуще станет, хотя может для кого-то это будет плюс.
Однако есть один нюанс. Линейный семплер не выведен в шейдеры, поэтому его нужно добавить в движке. Открываем файл uber_deffer.cpp, ищем там

и после него добавляем

Это на R3-R4. С R2 сложнее, нужно на входе отделять траву и листву от остального и делать для них отдельный семплер. В двух словах этого не опишешь.


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

Держи файл, который я вложил в игру: скачать
Вверху есть свойства файла и все по байтиками. Ничего не трогал более. Сам проверь файл с оригиналом. Да и другие настройки также. Либо на самом ОГСР запусти.

В файле порядок. А ОГСР у меня нету.

Внимательно просмотрел твои скрины, у тебя 100% включается сглаживание и мылит картинку. Похоже на FXAA. Почему оно включается, тут я без понятия, с ОГСР не знаком (кажется туда интегрировано FXAA). Возможно распакованная геймдата влияние оказывает. Инжектор у тебя никакой сторонний не стоит? Может он активируется.

Нужно было зачистку полную от всяческих адд-онов провести. Мод обновлял, а адд-оны начали конфликтовать с обновами, не суть.
Было vs Стало
vs
Извиняюсь за ложный аларм.

То же протестировал. В движке OGSR уже прописано по ходу вот эта функция C.r_dx10Sampler ("smp_linear");по этому все работает.
Трава стало намного гуще. Просто джунгли. У меня стоит не родная трава, а в 4К и измененный level.details.
По производительности не скажу. Выше ниже не понятно, но качество прорисовки травы очень снизилось. Я снизил плотность травы в движке и да производительность выросла, а визуально уменьшение плотности травы на качестве картинке не так сильно сказалось.
Ну и листва на самих деревьях то же стала намного гуще.

Работать-то оно будет и без прописанного C.r_dx10Sampler ("smp_linear");
Только не так как нужно будет работать. Поэтому все же лучше проверить наличие прописанного smp_linear. Если у тебя джунгли и качество снизилось, значит скорее всего не прописано. Да и про 4К траву ничего не могу сказать, не использовал.

И еще тут есть кое-что. Некоторые в модах по незнанию используют стороннюю траву с 8-битным альфа-каналом. Т.е. берут ее из другой игры в том виде, в каком она есть и переносят в сталк. А в нем требуется использовать траву и листья только с 1-битной альфой. Не знаю как у тебя, но и тут смена фильтрации на smp_linear может сильно повлиять и все испортить.

Кстати, никто не в курсе, какой тип фильтрации мипов используется при создании травы в СДК? Я если сторонними утилитами конвертации в DDS пользуюсь, трава полностью портится. Нужно правильный фильтр выставлять, знать бы какой. Какие пробовал, все равно отличается от СДК.

Я знаю про это и у меня как надо сделано.

При мерже текстур травы в одну текстуру, она сохраняется с "Advanced" мип-мап фильтром. Этот фильтр, если не ошибаюсь, их самописный. Есть ли аналоги, которые визуально схожи с ним, не знаю. Я не встречал.

В старом пейнтнете просто сохраняем как DXT1 с мип-мапами. Но есть одна хитрость: если трава чернеет вдали, повторно открываем этот dds-файл и снова пересохраняем.

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


Спасибо, пригодится на время тестов. А то я уже замучился с травой в СДК возиться.

Кстати, можно запилить крутой графоний на траве и листве, как при активации 4К DSR с плавностью 0 (суперская четкость, когда каждая ветка и лист вдали видны). Просто не сохраняем все мипы для этих текстур, а только штуки 3-4. Правда, легкий побочный эффект - повышенный шум в движении на траве и листве.

Делаю руками каждый мипмап в ФШ. А также собираю каждый мип-уровень отдельно. В СДК конвертировать текстуру травы, листвы,... не желается, ты прав, знатно похабит мипмапы.
Также и с другими сторонними, портят заразы, любым алгоритмом фильтрации.


Техника знакома. Шум сильный, но меньше, чем без мипмапов. Лучше делать полный комплект мипмапов и четкости добиваться иными способами. Этот топорный.

Zagolski,
если перевести текстуры с DXT на BC6-7 сжатие... Может сюда копать движок?


СДК ЗП.

Исходник vs Advanced
vs

Звучит как какая-то черная магия.
Вот проверенное решение https://xray-engine.org/index.php?title=Чер...._Что_делать%3F

"Идея решения проблемы: Scavenger" - а точнее, идея GSC )) Их заготовки (они даже в ресурсах ТЧ лежат) имели фон - нечто вроде усредненного оттенка, у каждого кустика - свой. Можно спокойно замутить свои аналогичные заготовки и компилить сразу финальный вариант, ничего потом не переделывая.

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

Вкратце - DXT (BC, S3TC) комрессия блочная - это значит что изображение разбивается на блоки 4х4 пиксела, для них ищутся 2 опорные цвета, для остальных - коэффициенты смешивания этих опорных цветов. Опорные цвета 16 бит. Отсюда потери.
Теперь проблема - текстуры с прозрачкой. Канал прозрачки жмется в отдельный блок, и в целом там качество получше чем у цвета, НО!
Сжатие цвета и альфы - происходят независимо друг от друга, и посему при декодировании обоих блоков, попиксельное согласование между ними не происходит.
Отсюда артефакты.

Теперь к решению проблемы.

Нет, любая вменяемая игровая контора решает эту проблему стандартно - посредством т.н. "colour dilation" - т.е. это алгоритм, при котором мы дублируем пикселы на границе прозрачности в неком радиусе. Чаще всего этот радиус 4 пиксела, ибо тогда мы гарантированно перекроем блок.
Альфа канал при этом, естественно, не трогается.

Выглядит примерно так:


Многие программы для редактирования изображений (и даже компрессоры) умеют это делать. Фотошоп точно умеет Ну или Dilation Tool.

Ах вот, что это за размазня в текстурах. Но нет, в gsc так не делали

Dilation надежнее чем константный фон, но суть та же - заполнить блоки.

Хороший плагинчик, благодарю! Всего 2 бакса. Есть схожая функция в других плагинах, но она не дает такого результата, как этот.
Я иным образом обманывал DDS DXT1 ARGB и нет потерь при сжатии мипмапов. Думается мне, что DRKIP применяет именно этот метод.
В общем, вот так:
1. сначала сохраняем 8.8.8.8 ARGB 32bit с автогенирацией Мипмапс, закрываем файл
2. открываем исходник сохраняем в DXT1 ARGB, закрываем
3. открываем оба файла. Копируем все уровни мипмапс с 8.8.8.8 ARGB 32bit в DXT1 ARGB
4. сохраняем DXT1 ARGB с применением уложенных мипмапов.
Вуаля! Получаем четкие мипмапы.

For the love of cthulhu, не используйте никогда этот черезжопный хак под названием "DXT1 с прозрачностью".
Используйте вместо него DXT5 и будет вам счастье и наложницы в загробной жизни.
Да "весить" текстура будет ровно в 2 раза больше, но и качество будет в разы лучше.

iOrange,
я тебя понимаю, так и сделал бы. Но Шталкер где-то подножку делает. Не могу вспомнить где, но четко вбил в память, что никаких DXT5 ARGB. Хотя, кто-то так и делает, когда на руках чужая текстура, а хочется ее малость ковырнуть культяпками.
Сейчас ребята напомнят причины, почему так в Шталкере.

Давайте не будем уж до такой степени докапываться, а то в поисках исторической справедливости придется разыскивать основоположника этого метода, а он нам сейчас на фиг не сдался. Мы тут, вроде как, непосредственно про "Сталкер" речь ведем, если я не ошибаюсь? И, раз уж на то пошло, конкретно у ПЫС никакого алгоритма не было, там явно ручная заливка фона одним цветом "на глаз", причем не всегда адекватно (встречаются коричневые кустики с зеленым фоном). А в ЧН и ЗП они и на это забили, оставили черноту.

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

В любом случае спасибо за разъяснение, нужно будет попробовать с заливкой. Может и правда все гладко станет.


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

Зачем?

Зачем?

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

Да там в сталке определенный механизм клипа альфа-теста с определенным коэффициентом. Да и родные текстуры травы сделаны под это. Если альфу не сделать с 1-битным цветом, работать все начнет наперекосяк. Разрабы видать все тщательно вымеряли, и шаг влево или вправо - расстрел. Хотя надо будет попробовать поиграться с коэффициентом клипа, возможно достаточно его подобрать для DXT5.

Тут наткнулся на материал по рендереру Deus Ex: Mankind Divided: https://www.eidosmontreal.com/en/news/defer...for-dawn-engine
Думал, они до сих пор сидят на отложенном освещении, ан нет, смотрю еще в 2016 перешли на visibility buffer вместо g-buffer. Мне казалось, эта техника только на бумаге хороша, до этого момента не встречал ее реализации в продакшне. Или я опоздал на вечеринку, неужели действительно next-gen?

Звучит так же стремно как "Думал, они на форвард рендеринге сидят, ан нет, смотрю перешли на occlusion culling вместо отрисовки".

Там "обычный" deferred, но со всем современными плюшками - gpu culling, indirect draw, bindless textures и т.д.
Благодаря этому в gbuffer можно держать только основную инфу (текстурные производные и TBN как база) и фетчить материалы уже в фазе шейдинга. (единственные фетчи на этапе первичной растеризации - это альфа для клипа).

По текстурам травы отвечу чуть позже.

Я только про это. Т.е. держим в буфере uv и некоторое еще, а выборку текстур делаем уже на этапе освещения, тем самым устраняя главную проблему в виде толстого g-buffer. Но если это так идеально, почему все не переходят на нее и продолжают сидеть на стандартном g-buffer, порой толстенном? Тут явно какие-то скрытые камни.

Давай проще. Я думаю, что у тебя есть ФШ. Возьми любую исходную текстуру DXT1 ARGB 4bit и пересохрани в DXT5 ARGB 8bit. А затем открой и сравни мипмапы. Но только не бери с исходника мипмапы, а автогенерируй. Вот тебе быстрое сравнение:
Исходник (DXT1 ARGB 4bit) vs DXT5 ARGB 8bit
vs
Мне в СДК делать сравнение?

Лучше заливай скрины на фотохостинг этого сайта. Вверху есть ссылка. Иначе куча рекламы, вирусов и еще вдобавок скрины не грузятся.

iOrange,
на всякий, чтобы было понимание, алгоритм сжатия на каналах RGB до 8 бит, DXT1~=DXT3=DXT5. Это факт! Причем, как сам вижу, так и специалисты это рассказывали. Далее идет канал альфа, вот тут уже пошла разница в сжатии- от 1 бит до 8 бит.
На кой мне мягкие края на текстурах, где ее не должно быть? Фильтр берет подгрешность +-1 пиксель при сжатии и смягчает края, т.е. делает 128х128х128 цветом. Мне это не нужно.
Про DXT5 c 1 битной альфой не слышал.


Ага, когда размер в 2 раза меньше. И полностью выполняет свои предназначения. Ты еще предложи сохранять в 8.8.8.8 ARGB. Если что, то Шталкер съедает на раз их. Лично извращался. Но правда размерчик душевный. И да, тут будет все то, что было в исходнике, глаз в общем, не увидит разницы.
Ты же бьешься за оптимизацию? Вот и ответ.

Извини, но вот этот кусок дает мне возможность предполагать, что ты путаешь понятия. Visibility buffer - это просто таргет, куда мы рисуем коробки кластеров треугольников с форсированным Early_DS_Z.
Этот буффер затем юзается чтоб собрать дроуколлы для индирект дроу.
В Юбиках вместо него юзают хитрый мердж из HZB и репроджекта депса прошлого кадра.

G-Buffer же - это бутерброд из таргетов, в которых мы храним минимально необходимую инфу о геометрии для последующей шейдинг фазы.

Как видишь - Visibility Buffer ни в коем случае не может быть заменой G-Buffer'у.


Нет, они не эту проблему решают. 4 таргета по 32 бита - считай стандарт для современного деферра, у них буфер такой же по толщине остался.
Главная задача - убрать точки соприкосновения GPU и CPU. Вот тут он и нужен.


На нее это на что? Если ты про GPU culling - то юзают практически все, в том или ином виде. Кто-то мешлеты, кто-то просто бъет геометрию на чанки. DICE, Ubisoft, id Software и прочие.
Если ты про отложенное текстурирование - то все упирается в то, что нужно сапортить Dx11. К сожалению.

Этот ФХ без рекламы. Я забываю про внутренний ФХ.

Я с этим провел много экспериментов. Если взять готовую траву и сохранить ее через ФШ. в DXT5 то она будит по любому с 8bit альфой.
В результате мы получим.
1-Если не использовать вот этот метод https://xray-engine.org/index.php?title=%D7...%EB%E0%F2%FC%3F
то трава на границе где-то в 50 метров начнет чернеть.
2-Если мы используем этот метод, то частично от полной черноты избавиться получится, но тогда трава на дальних расстояниях будит менее густая и пропадать по факту из за 8bit альфы.
3-

Оно будит выше только в просмоторщике картинок и все!! И это 100% факт.
В игре же по факту разницы нету.
По этому. Сохранять строго с 1bit альфой. Да если была бы возможность сохранить в DXT5 c 1bit альфой то почему бы и нет. Но я такого способа я не знаю и думаю ни кто тут не знает.
Да и вообще Сталкер с травой работает именно с 1bit альфой.
И тогда при правильном сохранении мипмапов и альфы мы будим иметь четкую траву на любом расстояние от ГГ. в игре.

Совершенно верно

Я вообще во всех постах не про формат DXT с 1-битной альфой толкую, а про битность цвета альфа-канала текстуры. 1 бит - это два значения: черный и белый. А что что я имел в виду про защиту от дурака, так то что простому пользователю лучше сохранять в этом формате, потому как если у него вдруг будет текстура травы из другой игры с альфой большей битности, она у него автоматом преобразуется в 1 бит и косяков в игре с травой не будет.

Прости, но не факт.
В режиме "DXT1 просто цвет" - да, утверждение выше правдиво.
В DXT3 и DXT5, по сути, 2 плоскости - цвет и отдельно альфа, которые жмутся независимо, и цветовая плоскость жмется так же, как и DXT1 без альфы.

Но не зря я писал что "альфа в DXT1 это галимый хак" - ибо в случае наличии "альфы", вместо таблицы из 4 цветов, у нас остается лишь 3 цвета для интерполяции по блоку, и 4-й "цвет" резервируется для обозначения прозрачности.
Как сам понимаешь - цвет при этом сильно деградирует.

vs

Вот если интересно то моя работа. Там четко видно как ведет себя травка да и не только
Сдесь ссылка на скрины из моей работы.
https://ibb.co/album/bY3Tqa

Была 1 битная альфа, стала с твоим DXT5 8 битная. Оно нужно? Мне точно нет.



Сохрани, как DXT1 c 1 битной альфой и перенеси альфа канал на DXT5. Ничего так, забавно.

Простите, но я удаляюсь из этого бтреда. Когда люди начинают спорить со спецификацией формата - это уже слишком. Удачи.

Вот тут говорят, что может: http://diaryofagraphicsprogrammer.blogspot...ity-buffer.html


Да-да, именно про него.

Я пробовал не получается. Он пересохраняет по своему

Ни один ты хитрожопый. Все бы оно хорошо, текстурки текстурками. А вот шейдеры бы подтянуть к тому, что делаем.
iOrange,
https://ru.wikipedia.org/wiki/S3TC
DXT1
Формат DXT1 из всех разновидностей S3TC обеспечивает самое сильное сжатие: каждый блок из 16 пикселей преобразуется в 64 бита. Также используются два различных 16-битных значения цветов RGB (5:6:5) и 2-битная таблица подстановок 4х4. DXT1 не поддерживает альфа-каналы.
DXT3
При использовании формата DXT3 каждый блок из 16 пикселей преобразуется в 128 бит: 64 бита данных альфа-канала и 64 бита данных цвета. Формат DXT3 подходит для изображений и текстур с резким изменением альфа-канала, то есть прозрачности.
DXT5
При использовании формата DXT5 каждый блок из 16 пикселей преобразуется в 128 бит: 64 бита данных альфа-канала и 64 бита данных цвета. Формат DXT5 подходит для изображений и текстур с плавным, постепенным изменением альфа-канала.

Нужное подчеркнул. Про альфу я выше Zagolski наглядно объяснил и доказал.


Не знаю. Только что провернул это действие и все как нужно сохранилось.

Это альфа-канал.

Просто DXT1 не поддерживает, но есть еще DXT1a, где присутствует 1-битная альфа, биты для которой забираются от основного цвета. Так вот этот формат по дефолту в сталке для альфа-тестовых текстур используется и менять его нельзя, если не хочется получить визуальных косяков.


Покажи для сравнения мипы, важны именно они.

Zagolski,
именно поэтому и iOrange пишет про хак. Это самоделка видать чья-то. Очень нужная самоделка, я вам скажу. Экономит объем и получаем четкие контуры с 1 битной альфой.
Да и вообще. Про сжатие я вообще не забиваю голову. Тут и так все ясно.
Главное, с чего начали разговор, это мипмапы. И я описал, как можно делать их без потерь на 1 битной альфе. По сути, вопрос закрыт. Также делает DRKIP.

Прикол в том, что в сталке текстуры листьев и травы низкого разрешения и при этом без детализации. По сути там только цвет. Так что DXT1a вряд ли визуально что-то испортит, если конечно многократно не пережимать.

Но в случае DRKIP, когда используются качественные hi-res текстуры растительности, тут уже однозначно нужно задуматься о формате, да и о мягкой альфе.

Я же выше постами описал пошагово, как создать 1 битную альфу на мипмапах без потерь. Также сделал сравнение из DXT1 1 бит в DXT5 8 бит. И да, Шталкеру и нужно подсовывать 8 бит (канал цвета) и если нужно 8 бит альфу. Никак ни 16 или выше бит на канал. Можно, сожрет, но жди безлоговых вылетов.
Zagolski,
я уже предлагал программистам поработать на тему, чтобы текстурщики могли добавить бампы + деталь-текстуры с бампами к траве, листве,... Тут была как-то давеча какая-то правка от macron, но она тестовая и только на использование бампа на траве. Этого мало и это уже завезли в Иксрей.

Она ужасно выглядит на листве и всем том, где нужен четкий кантик по альфе. Либо у тебя будет ощущение картинки, что она у тебя "плывет".
Я использую 8 битную альфу только там, где это нужно и никак иначе.

Это да. Я вот растительность на деревьях сохраняю только в DTX5 формате. При DTX1 есть потери в качестве. Не раз проверял. А вот с травой все по другому. По хоже движок с разыми типами того или иного работает абсолютно по разному. Тут уже надо в движке смотреть. А я в нем совсем 0 знаний имею)))))

Знаешь что я тебе скажу. Конечно можно "крутить пейсы" 8К текстурами, но утомит борьба за ФПС, когда у тебя будет подключена ИИ НПС, множество иных геймплейных решений. А играть хочется в умную игру, не только картинку для 8К мониторов.
Так вот, кто хоть мало мальски соображает в моделлинге и наложении текстур по развертке, то прекрасно понимает, что любой модели есть максимальный размер текстуры, из которого делай хоть в многократно большие размеры, а толку не будет.
Пример, можешь сделать текстуру 512х512 для крыски, а можешь сделать 8К. И ты не увидишь разницы, т.к. предел для этой модели в 512х512.

***
Вечерком, ради забавы, покажу, как выглядит ПЫС текстура на одной модели.Сейчас несколько устал.
Пока так:

Вечером из игры. Малость модельно доработал ПЫС плащ (поликов накинул, где нужно, чтобы мягче модель была и т.д. и т.п.), мусор вырезал, подпихнул свои части. Делал ради забавы, а получилось так, что самому понравился результат.
Пошкандыбал я

отдыхать.

Это понятно. Текстуры окружения, текстуры растительности и ландшафтные прекрасно масштабируются до 4К. И разница реально заметна между 2К и 4К.
Тут главное не переусердствовать. И да надо понимать, что 2К текстура может быть лучше 4К. Все зависит от того насколько все таки правильно создана та или иная текстура.
Для текстур растительности на деревьях в принципе достаточно и 2К. А вот для текстур ландшафта и окружения разница между 2К текстурой и 4К очевидна.
А вот 8К к примеру асфальт или трава на ландшафте это уже перебор. Разницы в качестве не видно, а вот фпс немного проседает.
По этому ко всему надо подходить с умом