The emission texture is rendered incorrectly

[0x4E69676874466F78]

Rays: Lightmap:

[0x4E69676874466F78]

Проблема светимости данных текстур в том что к ним не особо применима логика какой-то там "физической корректности". Есть текстура светящейся лампы, в норме она показывается как обычная диффузная текстура без всяких теней (если только не светит совсем-совсем тускло), то есть по ней нет ощущения что она какая-то там блёклая или пересвеченная. Градации светимости можно увидеть на test_light в комнате с поинтлайтами где позади есть тубы с сурфейсами, они в лучаях совершенно отличаются от курадовского поведения. Художественная задумка ломается, то есть в лучах получается ситуация что внешне они не фига не корректны. Если случай пересвета как-то можно (и в каких-то случаях и нужно) чинить автоматической экспозицией, то случай недосвета уже сложно починить в некоторых местах (потому что комната при задирании значений светимости будет освещаться уже иначе, с другим распределением света и теней и это автоэкспозицией не починить). debug_l_10 ещё светится в кураде, в лучах вообще нет света, на debug_l_50 тоже света нет, на debug_l_100 в лучах едва-едва, а в кураде уже целиком яркая текстура.

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

[w23]

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

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

В настоящий момент я думаю что проблема в:

• неправильной аттенюации площадных источников
• слишком ярком диффузе родных текстур

[0x4E69676874466F78]

@w23

1. возможно
2. ну возьми в рендере и снизь яркость всем текстурам, но как это исправит ситуацию с debug_l_10, debug_l_50, debug_l_100? или это пункт 1?

[w23]

Это пункт 1, да.

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

[0x4E69676874466F78]

Мне кажется первый пункт не поможет выправить настолько ситуацию не в ущерб остальному чтобы заставить светиться правильно при debug_l_10, debug_l_50, debug_l_100. Начинаю потихоньку более глубоко и глобально это всё осмысливать.

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

Почему я всё это продавливаю, простой пример с лампочками, в реальной жизни лампочки это отдельные объекты, но в халфе они тупо запечены в текстуру, в реальной жизни при таком же освещении лампочки будут довольно яркие, но в нашем случае этого не происходит, они превращаются в какую-то серую херню: Вместо:

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

Далее у светящихся текстур есть серьёзная проблема связанная с тем как к ним плюсуется свет. Вроде бы это должно решиться когда ты сделаешь свечение относительно цветов текстуры, но на всякий случай случай отмечу: не мало текстур содержат в себе оттенки чёрного, подразумевается что светиться должна только светящаяся область а тёмная область не должна сильно засвечиваться. Пример: Должна ли так светиться при таком свечении вся текстура? Я думаю нет. И здесь вопрос, можно ли сделать чтобы увеличивался контраст а не тупо яркость? Или мы можем задать маску на то где должно светиться а где нет (поможет ли это не засвечивать вот так соседние пиксели?). Маска заодно может помочь не светить не светящимися по задумке кусками текстуры.

[w23]

Возможно нам нужна отдельная эмиссионная текстура. Или эмиссионная маска, накладывающаяся поверх. Или крутить существующие текстуры в сторону контраста. (это помимо исправления яркости освещения от площадников)

[0x4E69676874466F78]

@w23 можно попробовать серой маской, маску сравнительно легко сделать и благо текстур света не столь много.

[w23]

Пусть тогда будет 'emissive_mask' в mat файле. Можешь сделать для теста несколько, я завтра прикручу

[w23]

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

В данную минуту я думаю, что корень всех зол здесь от умопомрачительно некорректной аттенюации площадных источников. Вместо деления на расстояние там нужен угол, под которым виден данный источник. Мне это знающие ребята с головой и руками в нужных местах несколько раз на стриме говорили в чят с едва скрываемой ухмылкой, а я отмахивался, дескать, да, но я же тупой и не умею. В общем, надо ещё почитать теперь как именно это нужно правильно считать (там ещё рядом MIS всякий возникает), и неумело делать вид, будто я будто бы едва и не тупой.

emissive_mask здесь абсолютно вообще ни при чём, но рюшечкой потом может и пойти.

[0x4E69676874466F78]

@w23 если ты не будешь пересвечивать текстуру выше её номинального диффузного уровня то emissive_mask действительно ни при чём. С другой стороны визуально могло бы интересно смотреться где лампочки светят довольно ярко, при этом только частью которая именно лампочки на текстуре, а не всё остальное, но такой подход с emissive_mask это дискуссионный вопрос.

[0x4E69676874466F78]

267 помечаю тут чтобы не потерялось

[0x4E69676874466F78]

Закрыл так как в целом результат сейчас неплохой.