- Suslik
- Постоялец
Предисловие
Уже несколько лет интересуюсь темой global illumination. Когда я начал своё мини-исследование, я хотел найти алгоритм расчёта GI, который бы:
+ сходился к точному path traced решению, хотя бы при определённых условиях. то есть unbiased
+ хоть и является следствием предыдущего, но на всякий случай подчеркну — необходим хотя бы аппроксимированный учёт indirect occlusion'а
+ подходил для сцен произвольного масштаба, а не только "игрушечных", которые можно целиком вокселизовать
+ был бы реалтайм или хотя бы околореалтайм с прицелом на будущее
+ аккуратно рассчитывал как near-field, так и far-field GI
+ сцена должна быть полностью динамической, никакого precompute bullshit'а
Как показало моё небольшое исследование, таким нехитрым требованиям удовлетворяют удивительно мало существующих алгоритмов. Вот небольшой обзор фатальных недостатков (с) известных мне существующих алгоритмов вместе с небольшим описанием под спойлером для интересующихся тем, как оно работает. Потом, если кому-то интересно будет, могу более подробную статью написать.
Список алгоритмов, на которых я не хочу останавливаться
Они ни в коем случае не плохие, просто в силу своих ограничний они мне не кажутся интересными.
Список алгоритмов, о которых я расскажу более подробно
Эти алгоритмы мне кажутся наиболее интересными. Не утверждаю, что они — существенно более перспективны или всегда дают визуально лучший результат, но я считаю заложенные в них идеи более глубокими.
Imperfect shadow maps
Алгоритм разработан T. Ritschel'ом и компанией — очень интересные ребята. Идея в том, чтобы создать кучу источников вторичного освещения вроде тех, что используются в reflective shadow maps, а потом очень эффективно построить для каждого из них приблизительную аппроксимацию shadow map'ы. Так как вторичных источников (называются vpl, virtual point light) обычно бывает очень много, сотни и тысячи, то, разумеется, рендерить сцену сотни раз, чтобы построить для каждого классическую shadow map'у, невозможно. Используется подход, в котором геометрия в compute shader'е представляется как множество точек, которые стохастически разбрасываются по всем shadow map'ам. Полученные карты получаются очень приблизительными и, так как состоят из точек, в них есть дыры, поэтому используется дополнительный алгоритм для заполнения пустот в полученных shadow map'ах. Точечное представление генерится на лету и нигде не хранится, поэтому памяти не занимает.
Алгоритм состоит из огромного количества стадий, результат сильно зависит от качества реализации каждой из них, а производительность — от оптимизации. Теоретически алгоритм можно назвать панацеей, потому что он алгоритмически очень красив и подходит, вообще говоря, для любых случаев, включая area lights и многократные отражения. Но на практике реализовать его максимально эффективно — крайне трудно. Вот моя реализация, включите аннотации, потому что я рассказываю, что именно происходит на каждой стадии алгоритма:
Rasterization-based path tracing
Я не встречал описания этого алгоритма, но сомневаюсь, что я его первый придумал, потому что идея достаточно проста. В обычном path tracing'е лучи выпускаются в случайном направлении — в таком виде алгоритм очень плохо уживается со стандартными способами хранения геометрии через меши. Чтобы уметь эффективно считать пересечение произвольного луча с геометрией, её нужно представить в виде особой структуры данных вроде svo или kd-tree. Я же делаю гораздо проще и использую то, что любая видеокарта умеет делать хорошо — растеризовать. Растеризация с ортогональной матрицей проекции — это по сути аппаратный способ поиска пересечения семейства параллельных лучей с геометрией. Поэтому я рендерю сцену со случайных направлений ортогональной камерой специальным depth test'ом вроде depth peeling'а, чтобы эффективно находить пересечения семейств параллельных лучей с геометрией, которые дальше использую для gathering'а. Алгоритм получился не слишком быстрым(не реалтайм), но очень хорошо укладывается во все остальные требования, плюс так как это — практически обыкновенный path tracing, я его использую для верификации других unbiased алгоритмов. Плюс сходится очень забавно:
Screen space ambient occlusion
Все знают, как работает обычный ssao — это просто аппроксимация равномерного ambient освещения, которое преграждается ближайшей окрестностью элеметна поверхности. На первый взгляд, SSAO является очень грубой аппроксимацией GI, хотя если задуматься, то вычислительно они практически эквивалентны, так как в пределе нужно посчитать влияние каждого фрагмента на каждый. Шейдер SSAO элементарно пишется для малого радиуса occlusion'а, в котором можно просто просемплить небольшую окрестность в скринспейсе и посчитать приблизительный occlusion. Если же увеличивать радиус, то cache coherency катастрофически падает, шум увеличивается, выборок больше, fps меньше — всё летит к чертям. Именно поэтому практически во всех играх используется очень грубая аппроксимация SSAO лишь в несколько десятков пикселей радиусом. Если же найти способ рассчитать SSAO с большим радиусом, то это выглядит уже вполне интересно, однако, это — не так просто. Такие алгоритмы только-только начинают появляться. Например, можно для каждого пикселя считать только 1 случайное направление HBAO за кадр, далее усреднять полученный occlusion с соседними пикселями, а потом ещё — за несколько кадров. Такой подход позволяет семплить всего лишь одно направление за пиксель и, с использованием репроекции, получать очень быстрые алгоритмы. Плюс для каждого направления, посчитав линии горизонта, интеграл освещения можно взять полуаналитически, получая хорошую точность. Вот моя реализация:
Screen space Global Illumination (Собственно, для чего я тему-то создавал)
Наконец, мой последний алгоритм. Потуг его придумать было уже очень много, не только у меня. Ни одного достойного результата с качественным occlusion'ом я не видел. Мой алгоритм основан на предыдущей схеме расчёта HBAO, используя репроекцию, но является совершенно честной аппрокцимацией вторичного освещения, которая сходится к точному решению, если в кадр попадает вся необходимая информация. Также используется полуаналитическое интегрирование, но уже для входящего освещения, а не occlusion'а. Алгоритм по факту считает вторичное освещение всех пикслеей framebuffer'а на все пиксели, таким образом, эффекты вроде area lights получаются вообще автоматически — они просто рендерятся forward render'ом, а дальше вокруг них рассчитывается освещение вместе со всеми остальными пикселями. Прикладываю видос, обратите внимание на вторичные тени, на occlusion и на артефакты при резком повороте камеры или если источник света внезапно появляется в поле зрения:
Предлагаю в теме обсудить эти и другие алгоритмы, а также делиться своими соображениями, вопросами и успехами.
Пока что лучшего чем Deferred shading не придумано для риалтайма.
Принципиально против воксельных алгоритмов? А если вокселизовать только значение занят/не занят воксель, на манер VXAO, то такие воксели устраивают?
gamedevfor
deferred shading соврешенно ортогонален global illumination'у. например, он у меня используется во всех демках просто из соображений удобства и, разумеется, сам по себе он реализацией global illumination не является, так что мимо кассы.
Battle Angel Alita
> Принципиально против воксельных алгоритмов? А если вокселизовать только значение занят/не занят воксель, на манер VXAO, то такие воксели устраивают?
воксельные техники — это как рабочая лошадка. если надо, чтобы просто работало при стандартных ограничениях, то вот её надо брать. но мне хочется приключений и неограниченных по размеру сцен.
Suslik
Красивый ги получился. Тени заценил. И каков перфоманс по сравнению с твоим фар филд ссао?
Андрей5000
> Suslik
> Красивый ги получился. Тени заценил. И каков перфоманс по сравнению с твоим фар
> филд ссао?
как ни странно, производительность вполне сравнима. может, раза в 2 медленнее, чем мой SSAO, но это — всё равно 40fps при 1900x1080 fullres. однако, на этой сцене гораздо больше шума. думаю, на более спокойной сцене шума будет на порядок меньше.
Suslik
Опишешь алгоритм? Как ты там реймарчишь? По теме думаю что можно например заюзать lpv для low frequency и ssgi с небольшим радиусом для high frequency. Скомбайнить их как нибудь и будет вполне себе. Для того же ао этот подход очень хорошо работает.
Suslik
> deferred shading соврешенно ортогонален global illumination'у.
Есть Deferred Voxel Shading for Global Illumination
>но мне хочется приключений и неограниченных по размеру сцен.
Ты ещё скажи, что шадоумапы тебя не устраивают, тому что если отлететь от земли на расстояние 5000 км то слишком большая шадоумапа получится и она в память не влезет.
А скринспэйс техники все - мусор. Сам забраковал radiance hints, и сам-же делает скринспэйс.
Андрей5000
> Опишешь алгоритм? Как ты там реймарчишь? По теме думаю что можно например
> заюзать lpv для low frequency и ssgi с небольшим радиусом для high frequency.
> Скомбайнить их как нибудь и будет вполне себе. Для того же ао этот подход очень
> хорошо работает.
ну в принципе да, для совсем уж far field можно использовать что-то вроде light probe'ов или lpv. но меня здесь гораздо больше интересует ssgi часть, потому что нет пока стандартизованных алгоритмов, которые бы с этим хорошо справлялись. ssdo — это только совсем первые шаги, по качеству не сравнить. а больше-то общепринятых алгоритмов и нет.
Suslik
Progressive Photon mapping вроде вполне нормально ложиться на GPU, правда разницы с обычно трассировкой в сложности реализации там нет.
По поводу странной сходимости в Rasterization-based path tracing, наблюдал подобное при фиксированном семпле на кадр, сходится аналогично.
Suslik
> и на артефакты при резком повороте камеры или если источник света внезапно
> появляется в поле зрения
Еще артефакт есть в латенси GI. Т.е. ты двигаешь луч, а оно с отставанием просчитвыает GI. Хоршо видно на 4 секунде, когда лайтспот останавливается, а освещение под жуком плавно затухает.
А вообще пилил бы ты уже статью, сколько можно то нас томить, а?
Kurono267
когда я читал про обычный photon mapping, это было даже не близко к realtime. мне бы всё-таки хотелось realtime.
MrShoor
> Еще артефакт есть в латенси GI. Т.е. ты двигаешь луч, а оно с отставанием
> просчитвыает GI.
да, есть такое. из-за time coherence и reprojection'а оставание где-то кадров на 4-6. его можно убрать, но будет больше шум.
статью напишу, если будет больше чем двум человекам интересно. и надо определиться, про что именно люди хотят узнать.
Suslik
> про что именно люди хотят узнать.
Я в первую очередь практик. Поэтому мне интересно будет получить на выходе рабочую технику. Мне мало интересно читать про подробное вычисление интегральчика X. Поэтому в статье предпочту поверить формулам. Достаточно: "Я поинтегрировал вот это, и получил вот это".
>Еще артефакт есть в латенси GI.
Да там артефакт на артефакте. 28 секунда - камера залетает за штору, через дырку сверху полная чернота, хотя по идее должно быть видно стену освещённую вторичным светом.
Тема в архиве.
