Как-то по работе пришла мысль запечь одну непортируемую функцию в lookup table, но тогда ничего из этого не получилось, т. к. кол-во параметров и объём данных грозили превратить таблицу в гигабайтного монстра. Зато появилась идея реализовать lookup table для быстрого расчёта coverage источника света силуэтным ребром. Это функция от четырёх параметров - (x1,y1) и (x2,y2). Идеально подошла бы 4D-текстура или массив 3D-текстур, но железо не поддерживает ни один из этих вариантов. Выход прост - закодировать четырёхмерную таблицу в 2D-текстуре.
Вот как выглядит вариант такой 4D-таблицы для прямоугольного источника света:
Хотя набросать черновой вариант расчёта оказалось достаточно просто, выяснилось, что очень сложно добиться numerical stability для граничных случаев. И хотя мне удалось минимизировать эту проблему, она всё же кое-где даёт о себе знать:
Доработал вариант 4D-таблицы для сферического источника света. Выглядит она вот так:
Особенность расчёта этой таблицы в том, что отсутствуют проблемы с numerical stability, т. к. расчёты для диска проще. Подготовка таблицы помогла мне выявить потенциальные баги в математике, которых, как я считал, нет. У меня было два варианта расчёта coverage диска: один - точный, другой - ускоренный, с меньшим кол-вом мат. операций. Оба варианта почти всегда давали идентичный результат в test case, который я подготовил, при этом сам тест предполагал самые различные ориентации ребра. Как выяснилось, некоторые симметричные варианты расположения вершин всё же дают неправильный coverage в "быстром" варианте расчёта, поэтому он не годится. В принципе это уже не имеет значения, т. к. таблица как раз и призвана заменить эти расчёты выборкой.
Надеюсь, эти варианты таблиц можно будет использовать для первоначального ускорения алгоритма мягких теней. Что же быстрее - выборка или математические операции в шейдере? Дело в том, что мат. операции сами опираются на дополнительные выборки из кубической текстуры (2 выборки) и 2D-текcтуры (одна выборка), т. ч. в любом случае получается экономия.
