Zagolski, могу попросить сразу использовать систему версионирования?

Не подскажете, как r3 на этапе намокания (сразу перед рендером солнца и освещения) получить цвет? Для DX9 из r2_RT_albedo брал, а на DX10 там пусто.
Провожу объединение скринспейсовых отражений с картой дождя/намоканием из ЗП. На DX9 всё удачно завелось, на DX10 без информации о цвете ничего не выходит.

Там не может быть пусто. Ты точно в $user$albedo смотришь?
Посмотри также в $user$accum и заодно проверь $user$generic0, только обязательно MSAA отключи (с ним, кстати, у тебя будут проблемы при внедрении SSR, но решаемые).

Я склоняюсь к тому что встроенная функция может распараллеливаться, в отличие от. Хотя могу быть и не прав.

Точно там смотрю. Остальные тоже проверил - все, кроме accum, нули возвращают. Accum хранит патченную нормаль, которая на предыдущих этапах высчитывалась.

А какая у тебя видеокарта?

На ноуте мобильная Nvidia 860m, на десктопе Nvidia 1063, ведут себя идентично.
MSAA отключен, на переключение оптимизации gbuffer тоже реакции никакой.

Провел некоторые эксперименты в Сталкере с динамической кубмапой. В принципе можно юзать 512х512 (при этом фпс такой же, как с полноразмерным planar reflect 1920х1080), разница в качестве по сравнению с 1024х1024 не сильно заметна, тем более при наличии искажений (а при чтении из кубмапы они более живые/ интенсивные). Вообще из кубмапы отражения считываются по вектору более корректно, конечное изображение реалистичнее, динамичнее и ощущается объем. Также заметил, что лесниц гораздо меньше, чем скажем на planar уменьшать вдвое разрешение (не говоря уж про 4 раза). Тут по большему счету детализация снижается, но изображение при этом остается довольно четкое по краям.
Вот три скрина поглядеть разницу, честных отражений с динамической кубмапой с ее разрешениями 1024, 512 и 256 (фпс на 3 скрине глюканул, не обращайте на него внимание):

Чет, разница то в 20 фпс

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

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

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

Или так, или усредненную высоту, чтобы +/- попасть везде.

Но на практике, я не помню ни одной локации, где такое было. Везде на одном уровне.

Кое-какая интересная информация касательно теней. После переделки алгоритма (схема ЗП, три каскада) на один проход с геометрическим шейдером существенно возросла плавность в игре. Если раньше даже при >100 фпс мог ощущаться дискомфорт (особенно в модах), т.е. фпс вроде как и высокий, а плавность не идеальна, как-будто и нет никаких ста фпс. То теперь стал порядок.
По сути сейчас вся работа перенеслась с проца на ГПУ разгрузив первый, а также существенно снизилось кол-во дипов (а отрисовка теней их как раз больше всего и привносила). Ну и результат, как по мне положительный. Нагрузка на видяху конечно сильнее пошла, моя старушка GTX 660 зашумела...

Отдашь правку оксигенщикам?

Там все непросто, да и сделано у меня для статики (форвард), совместимости нет никакой. Но геометрическими шейдерами поделюсь, они и для ванильной динамики R3-R4 подойдут (R2 не поддерживается): https://yadi.sk/d/djn0vfhQE_oL_w
Какие вопросы если будут, помогу чем смогу.
Вот советую сперва почитать: https://developer.nvidia.com/gpugems/GPUGem...gems3_ch10.html

Всем привет. Подскажите пожалуйста. Использую движок ОГСЕ и его шейдеры. Заметил то, что там не как в обычном ТЧ или том же ЗП работает gloss factor. Ковырял шейдеры, что то не помогло. Нету нормального блеска на оружии. При увеличении параметра белеет окружение но на оружии ничего не меняется. Оружейка с бампами как положено.

У меня вопрос по стандартным шейдерам тч.
Если на меше 2 текстуры-маски, например, на одной части terrain_escape.dds с детальной текстурой escape_grass, на второй же части terrain_garbage.dds с детальной текстурой garbage_asfalt, будет ли на стыке этих масок происходить мягкое смешение, как если бы на меше был только terrain_escape.dds и 2 детальные текстуры escape_grass и escape_asfalt?

Кстати заметил тут, что ещё в ТЧ походу реальные мягкие тени есть


Размываются правда не так интенсивно как хотелось, но тень от плафона около лампочки явно четче, чем тень справа на потолке.

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

Кстати, видел неоднократно инфу, причем вроде как в т.ч. и от самих разрабов, мол, что в сталке особенно в индоре по 50-100 источников света в кадре. Не совсем верно. Ну максимум штук 8-10 на самом деле имеется. Инфу по свету видимо тащили из статистики, а там в том числе отображаются и те псевдо-источники, которые только для расчета теней точечного света применяются (из одного реального поинта создаются шесть прожекторов). А поскольку на локах большинство поинтов, то указанную цифру в 50-100 можно смело на 6 делить. А, еще есть и бестеневые, которые часто теневые накрывают. Непонятно зачем, видимо для лучшего амбиента.

А кто-нибудь пробовал в сталке тесселировать ландшафт? Как оно, профит есть? Хочется понять, стоит ли овчинка выделки и не вылезут ли косяки.

Я так бегло шейдер тесселяции накинул, вроде никакого эффекта... Или он только на динам. моделях работает?

Zagolski, а покажи сетку. На первом скрине выглядит угловато, как и было.

А там оба скрина из одного флакона, только на первом камера к ландшафту приближена. И видно углы. Без тесселяции вроде то же самое. Я еще точно не разобрал, работает ли она или нет. Вроде не работает.

Вот якобы с тесселяцией:



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

upd.
Работает тесселяция. Вот скрины без нее:



Осталось понять, почему дорога угловатая все равно осталась. Та, что на скрине парой постов выше, где тесселяция функционирует.

Zagolski, триангуляция точно работает, поликов больше чем без тесселяции.

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

Так что там точно нужно подправлять для ланшафта что-то, как я думаю. С таким большим кол-вом полигонов ланшафт должен быть идеально округлый по идее. А не с углами, как на тех первых скринах.

Пробовал для статики:



динамика:



От таких результатов, лучше в 3д редакторе поликов добавить.

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

А чем вообще отличается PN от HM?

upd. Покопал код, вообще для всего нужно юзать PN. А вот HM оказался очень даже интересной штукой. Это как бы displasement mapping... Я в шоке! Оказывается, он в сталке имеется. Но возможно не доделан, потому как в игре нигде не используется, насколько я знаю. Вон кран на последнем скрине какой стал. Но для его корректной работы нужна текстура высоты, которую надо класть в #bump в а-канал. И похоже там само смещение бамповой нормали используется, т.е. по бампу тесселятор проходит, дополнительно учитывая высоту.

Скрины тесселированых лодов (tree):

Zagolski, колеса на грузовике Волк подкачал?

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


То есть кирпичики таки могут на углах быть объемными? В каком-то обзоре 2004 года, разраб рендера, который потом ушел в Метро, говорил, что нереально))

Было бы круто, если бы тесселяция происходила только на определённом участке геометрии. Нельзя ли сделать, например, тесселирование только определённых материалов в сцене: колёс, бочек и т.д. - или в настройках материалов модели задавать параметр тесселяции?


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

Только если в модели отделить участок в отдельную группу и повесить на него шейдер с тесселяцией. Иначе скорее всего никак.

Испробовал в сталке тени Variance Shadow Map с полноценным гауссом. Что сказать? По мягкости они шикарны. При этом скорость высока, фпс раза в 1.5 больше ванильного, потому как используется карта теней меньшего разрешения, да и по сути в один проход. Да и размытие почти бесплатное. В ваниле, кстати, есть шейдер теней на экстрим качестве, который такие же по мягкости тени делает, но он жрет очень много, фпс у меня падает процентов на 300.



С другой стороны ванильные тени в ЗП очень четкие, такие хоть и менее реалистичны, но может быть даже более стильные. Кому как.

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

Что если сделать конфиги погоды в виде таблицы отношении в game_relations.ltx, а не сотни строк как в оригинале? Вот только без редактирования движка это никак, но было бы круто.

Может просто в движке сделать нормальную настройку погоды, чтобы в конфиги вообще не лазить?

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

Я уже отказался от VSM. Там есть визуальный баг, так называемый "light bleeding", полностью на сложной геометрии не убирается. Появляется в сталке то тут то там. Выглядит вот так:

Его можно снизить, но полностью не убрать, причем в ущерб размытию. Так что это техника только демки гонять, для реальных проектов с открытым миром не предназначена.
Поюзал также PSM, эта тоже никуда не годится для сталка. Из-за искажений теней от лоупольных объектов. Так что остаются старые добрые стабилизированные каскады с PCF, как наиболее беспроблемные, к тому же в них можно легко степень размытия от удаленности внедрить навроде PCSS.

Нет, конфиги остаются в конфигах. Просто в движке например вот такой редактор погоды:


Вся погода редактируется в нем, конфиги никому не нужны.

А что, нельзя подобное сделать прямо в игре, в виде мода?

Ну и?

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


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

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

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


Очень удобная штука, настройка погоды через конфиги и рядом не стояла.

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

Зачем тыкать на каждый ползунок, кнопок и искать подходящий цвет если всё можно настроить за один-два клик?
Да и программа какой-то глючный.

Давно пора вообще с конфигов слезть, слишком много с ними возни, лучше все автоматизировать. Цвет окружения = цвет солнца, меняется в зависимости от положения солнца на небе. Скайбокса два - синий дневной и черный ночной. Облака пускаем отдельно по небу в большем/ меньшем кол-ве, скорость движения в зависимости от ветра, плюс их подкрашиваем цветом солнца. Сама погода ясно/ пасмурно на полном рандоме, можно заранее в таблицу загенерить при НИ на год вперед или раз в неделю обновлять. Это так, примерный план.

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

VSM и MSAA. На скрине тени (кроме альфатеста) без какой-либо фильтрации, точнее анизотропная активирована, я имею в виду без PCF. Причем размер карт теней снижен вдвое - до 1024, но (!) на тенях активирован MSAA 4x (~10% снижение фпс по сравнению с выкл). А такое качество теней при обычном раскладе можно получить где-то из 4096 карты. Так что шикарно MSAA отрабатывает, ничего не скажешь.

Ну почему, цвет солнышка и луны (как и в принципе всего освещения) вполне можно генерить, я с этим как раз экспериментирую:

cjayho, весьма неплохо, вот только дымки не хватает. Солнце тоже восстановил движково?

Да, нагуглил решение наконец-то.

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

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

А то в видео ( https://www.gameru.net/forum/index.php?s=&a...t&p=1653251 ) услышал от Парфенюка, что в ЗП такая фишка имеется, зависимость от расстояния. Для меня это нонсенс.