Cornholio

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

мягкие тени и освещение в подземелье

Немного покажу свой "доработанный" АО (сейчас делается для проекта и потому это его эксклюзив на данный момент, но и модифицированная версия будет в свободном доступе, первую версию со скинов выше в теме, можно найти в дискорде по моддингу аномалии, если будет запрос, то могу и сюда залить) Вот как выглядит "быстрое" время на исполнение, в профайлере renderDoc: Вот так выглядит идеал (не очень пригодно для игры в реальном времени, но все равно возможно - время на исполнение порядка 9мс) видно, что быстрый алгоритм вполне неплохо приближается к идеалу (пусть и с меньшим контрастом) Еще есть пути для оптимизации, т.е я ожидаю, что спустя какое время мы сможем за 1мс выдавать еще лучшее качество (ну или ускорить его еще раза в 2) на скрине с счетчиками профайлера - время в милисекундах, а цена на исполнение всего алгоритма находится в строке AmbientOcclusion, он имеет 3 пасса: сам АО и 2 прохода фильтром (просто случайно забыл выделение снять со второго пасса фильтра)

@Ghilli к сожалению я не могу подсказать

@Ghilli не знаю - это скорее вопрос к автору мода. Если б мне надо было делать прицелы - я бы сделал иначе (имхо темные луны плохо для восприятия игрока) лучше всего копировать подход армы, старых call of duty и battlefield - там куча бывалых дизайнеров не просто так пришли к тому виду прицелов, что мы видим в их играх (уверен есть даже презентации и методички по этому процессу в интернете) само собой к модам у меня нет претензий - пусть делают, даже если я считаю это не правильным (я охотно пересмотрю свое мнение и признаюсь неправым - когда кто-то круто реализует такой псевдо 3д прицел), но если серьёзно - обычный модификатор FoV и "маска" прицела - вполне хороший вариант: не ест фпс на второй вьюпорт, не загрязняет обзор игроку ненужными эффектами, а уж сделать прицеливание реалистичным (ну там милдоты, прицельные линии и поправки на дальность, возвышенность) никак точно не мешает.

штука в том, что screen_res и pos_decompression_params - регистры, которые передаются от движка в шейдеры. В разных версиях движка могут называться по разному, но если просто объявить, то вполне может оказаться, что там ничего нет и шейдер все равно не работает (пусть и не дает вылета, ведь компайл проходит) @Ghilli

ранний прототип screen space global illumination, пока сделан отдельно на основе GTAO, в планах попробовать его перенести в xray

вопрос по правке движка цель: изменить отношение point light shadow map pixel per meter (сколько метров игрового мира относятся к 1 пикселю карты теней для точечного источника света) суть проблемы: при попытке перевести accumulators на физически более корректное затухание света с расстоянием ( закон обратных квадратов, а в ваниле xray это просто обратно-линейная зависимость ) я упираюсь в границу индивидуальной карты теней для источника (видимая грань на которой обрывается свет) смотрю на класс r2_R_lights.cpp и не могу в нем разобраться, что откуда тянется и где ставится это соответсвие (явно разрешение "индивидуальных" карт теней задается в нем) подскажите - вдруг кто знает? пс - да, я знаю что это значение в некотором роде задается при компайле уровня, но я не хочу пересобирать все уровни, мне кажется проще поставить "заплатку" в виде небольшого множителя K для этого коэффициента.

@ed_rez это - да, знаю. Косячок )) должен уйти сам, когда другую вещь изменю

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

мое колдовство над рендером. База - аномалия. Изменения: HDR процессинг, блум, АО, небольшие правки формулы для источников света без использования решейда, выхлоп старичка xray

портировал в аномаль GTAO ( по этой статье https://www.activision.com/cdn/research/Practical_Real_Time_Strategies_for_Accurate_Indirect_Occlusion_NEW VERSION_COLOR.pdf) без АО (вообще без какого-либо) GTAO пока много багов, надо убрать гало, следы и добавить оптимизации (хотя уже при 16 семплах выполняется за 4-5мс в 1080р на видеокарте 1060)

@_ХоЗаР_ я, пожалуй верну "толстый gbuffer" заодно появится место под roughness ну и другие свойства материала (может даже светимость, чем чорт не шутит, места-то вагон теперь) вот правда проверить - насколько отличается фпс довольно сложно... но я расскажу, если интересно будет

вопрос я немного глупый и не очень понимаю - почему в сталкере используются другой класс для хранения буффера - rendertarget. Я не понимаю, почему сначала создается полноценный буффер для глубины/стенсил, а затем его перезаписывают уже виде компонента "позиции в экранном пр-ве" . чисто, чтобы поиметь линейную глубину, вместо z/w ? И опять же вопрос - насколько затратны эти render target? Просто сжатые данные gbuffer это конечно здорово, но у меня подозрение, что запаковка и последующая распаковка в каждом пассе постпроцесса съедают больше производительности видеокарты. если предположить, что для gbuffer использовать 3 64битных полноэкранных текстуры, то для fullHD это всего около 48Мбайт памяти на кадр. А вот перекодировать нормали каждый раз (особенно если хочется рейтрейсеры для АО/SSR/GI/FOG) занимает уже заметное кол-во операций на кадр. Я не программист, я так - любитель, но вдруг кто-то разбирается - вчем подвох? @_ХоЗаР_ вдруг знаешь ^