Линейный расчёт освещения при использовании текстур sRGB

Отслеживайте смысл значения

Изображение может правильно выглядеть в просмотрщике, но давать неверное освещение в игре. Значение канала может быть кодированным цветом, а не величиной, пропорциональной свету. Суммирование освещения и взвешенное смешивание цвета требуют линейных световых значений; изменение экспозиции обычно не исправляет расчёты над кодированными входами. [1]

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

Отличайте цвет от данных

Формат текстуры sRGB декодирует цветовые каналы при выборке. Альфа-канал не получает такого же цветового преобразования. Нормализованный целочисленный формат и sRGB могут хранить одинаковые байты, но передавать затенению разные численные значения. [2][3]

Изображения базового цвета обычно требуют декодирования цвета. Roughness, маски, глубина и кодированные компоненты нормалей — числовые данные, которые должны следовать собственной объявленной форме представления. Одно расширение файла не устанавливает этот смысл. Запишите и исходную кодировку, и формат GPU-представления.

Рассчитайте контролируемый пример

Возьмём условный нейтральный тексель с сохранённым sRGB-значением 0.5. Декодирование передаточной функции sRGB даёт примерно 0.214 в линейном свете. Уменьшение света вдвое даёт около 0.107; обратное кодирование в sRGB — примерно 0.361. Это расчёты по передаточной функции, а не измеренная яркость экрана. [2]

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

Проверьте весь путь

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

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

Разделяйте связанные понятия

Линейный свет описывает арифметику, цветовые первичные задают охват, а хранение с плавающей точкой — числовое представление. Ни одно само по себе не гарантирует остальные два. Преобразование вывода sRGB также не является тональным отображением неограниченных HDR-значений.

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

Источники

• [1] The Importance of Being Linear — Larry Gritz and Eugene d’Eon, NVIDIA.
• [2] EXT_texture_sRGB specification — Khronos OpenGL Registry.
• [3] Data Conversion Rules — Microsoft.