Уже давно пытаюсь решить проблему множества источников света в классическом прямом рендере (честно говоря, очень не хочется переходить на deferred). И недавно я открыл для себя отличную технику, которую теперь хочу попробовать применить в Dagon - clustered forward shading. Суть ее заключается в индексировании пространства при помощи 3D-текстуры, ячейки которой (кластеры) ссылаются на источники света в буфере, влияющие на пространство внутри данной ячейки (фактически, в ячейке можно хранить срез индексов - смещение и количество источников света - в виде двух 16-битных значений). Пиксельный шейдер, зная позицию точки в world space, сэмплирует ячейку из 3D-текстуры, получает срез и проходит по нему циклом, считывая атрибуты источников света - позицию в eye space, цвет и радиус.
Метод очень перспективный - минимальная нагрузка на GPU, всего две дополнительные служебные текстуры (кластер и буфер источников света), хорошая масштабируемость и почти полная независимость от сложности сцены (есть лишь зависимость от ее размера - чем больше сцена, тем выше разрешение кластера).
Есть, впрочем, и недостатки - во-первых, небольшая дополнительная нагрузка на CPU при обновлении 3D-текстуры и буфера. Но обновлять их нужно только при движении источников света - если у вас статичный свет, то оверхед будет нулевой. Другое узкое место - передача буфера источников света в видеопамять. У меня это текстура GL_RGB32F шириной N * 8, где N - количество ячеек кластера, и высотой 4 - по одной строке на атрибут. N может достигать 1024 и выше - передавать такой буфер из системной памяти каждый кадр может показаться малоэффективным, но можно обновлять не весь буфер, а только те его части, где меняется список источников света (маловероятно, что в обычной игровой ситуации будут сотни движущихся ламп).
Надеюсь вскоре доделать и выложить демку с реализацией данного метода.
Метод очень перспективный - минимальная нагрузка на GPU, всего две дополнительные служебные текстуры (кластер и буфер источников света), хорошая масштабируемость и почти полная независимость от сложности сцены (есть лишь зависимость от ее размера - чем больше сцена, тем выше разрешение кластера).
Есть, впрочем, и недостатки - во-первых, небольшая дополнительная нагрузка на CPU при обновлении 3D-текстуры и буфера. Но обновлять их нужно только при движении источников света - если у вас статичный свет, то оверхед будет нулевой. Другое узкое место - передача буфера источников света в видеопамять. У меня это текстура GL_RGB32F шириной N * 8, где N - количество ячеек кластера, и высотой 4 - по одной строке на атрибут. N может достигать 1024 и выше - передавать такой буфер из системной памяти каждый кадр может показаться малоэффективным, но можно обновлять не весь буфер, а только те его части, где меняется список источников света (маловероятно, что в обычной игровой ситуации будут сотни движущихся ламп).
Надеюсь вскоре доделать и выложить демку с реализацией данного метода.
Комментариев нет:
Отправить комментарий