Войти
ПрограммированиеФорумГрафика

На пути к эффективному алгоритму Global Illumination, часть 1 (комментарии) (3 стр)

Страницы: 1 2 3 4 510 Следующая »
#30
16:51, 23 апр. 2019

Panzerschrek[CN]
перекрестись и проходи мимо. можно подумать, я тебе что-то продать пытаюсь, а ты не хочешь это покупать.

#31
16:54, 23 апр. 2019

>>это конечный набор 2д текстур. каким бы пухлым он ни был
А OIT тогда чем занимается?

>>кому очевидно?
Всем?

>>без потери информации о взаимном окклюжене элементов сцены
Я вот не помню, видел ли я когда-то сложные голографические сцены. Обычно это одна фигурка. Впрочем я никогда всеръез не интерисовался голографией.

>>а в волновой графике — есть.
И каков объем этой информации для конечного пикселя?

#32
16:57, 23 апр. 2019

g-cont
> Обычно это одна фигурка
причем выпуклая

#33
(Правка: 17:13) 17:10, 23 апр. 2019

g-cont
> А OIT тогда чем занимается?
oit, depth peeling и прочие можно считать костылями, которые позволяют хранить больше слоёв информации ценой пропорционального увеличения gbuffer'а. фишка голограмм как раз в том, что они хранят информацию, эквивалентную gbuffer'у c бесконечным количеством слоёв, но гарантированно в одном слое. я считаю, что глубинная причина этого явления в том, что многослойный gbuffer — это очень неэффективный способ кодирования трёхмерной сцены, но лучше ничего просто не придумали. однослойный же gbuffer — достаточно эффективный способ, но вовсе не идеальный, так как в нём информация может теряться.

g-cont
> Я вот не помню, видел ли я когда-то сложные голографические сцены. Обычно это
> одна фигурка. Впрочем я никогда всеръез не интерисовался голографией.
посмотри на картинки с википедии:
Изображение
Изображение
ты считаешь, что они выпуклые? или слишком простые, чтобы показать идею?

g-cont
> И каков объем этой информации для конечного пикселя?
важное свойство голограммы — в том, что любой её фрагмент конечного размера кодирует информацию сразу обо всей трёхмерной сцене. чем больше таких фрагментов, тем более точное представление сцены из них можно получить. в геометрической графике вообще(пока) нет аналогов такого представления.

#34
17:19, 23 апр. 2019

>>многослойный gbuffer — это очень неэффективный способ кодирования трёхмерной сцены
Неэффективный, но это первое что приходит в голову, да.

>>посмотри на картинки с википедии:
Там обзор 360 градусов, у реальной голограммы? Я такое никогда вживую не видел, просто.

>>любой её фрагмент конечного размера кодирует информацию сразу обо всей трёхмерной сцене
Пусть. Но сколько это займёт памяти? С одной стороны это может быть универсальный контейнер, с другой стороны при попытке его описать в G-буффере может оказаться, что на пиксель приходится до килобайта информации.

#35
17:25, 23 апр. 2019

}:+()___ [Smile]
ещё одна мысль, которая может быть интересной. дело в том, что в наивной реализации программы наблюдения голограммы, приходится рассчитывать влияние каждого пикселя голограммы на каждый пиксель изображения. это — жутко неэффективный процесс, который скейлится квадратично с ростом объёма хранимой информации. это объясняется нелокальным характером хранимой в голограмме информации, так как любой бит закодированной в ней информации влияет на всё результирующее изображение.

именно такой же сложностью обладают большинство реализаций global illumination, включая любые path tracer'ы — они считают излучение каждого фрагмента сцены на каждый фрагмент сцены, то есть сложность тоже, грубо говоря, квадратичная, и это тоже связано с нелокальностью данных, так как освещённость одного фрагмента переизлучается на всю остальную сцену. и таким же свойством квадратичности обладает наивная реализация преобразования Фурье, которая также реализует нелокальность, просто суммируя все гармоники в каждой точке, получая квадратичную сложность. вообще в голографии существует очень много параллелей между преобразованиями волновой оптики и преобразованием Фурье.

однако, у преобразования фурье существует быстрый вариант — FFT, который позволяет получить линейно-логарифмическую сложность. значит ли это, что за то же время можно получить изображение от голограммы? значит ли это, что за то же время можно рассчитать GI?

#36
17:30, 23 апр. 2019

g-cont
> Там обзор 360 градусов, у реальной голограммы? Я такое никогда вживую не видел,
> просто
там обзор 180 градусов, потому что голограмма выглядит как портал в пространство, которое в ней запечатлено. размерность полупространства равна размерности полного пространства, поэтому топологически можно считать, что голограмма кодирует информацию обо всём пространстве.

g-cont
> Пусть. Но сколько это займёт памяти? С одной стороны это может быть
> универсальный контейнер, с другой стороны при попытке его описать в G-буффере
> может оказаться, что на пиксель приходится до килобайта информации.
вообще запросто. я тебе больше скажу, учитывая длину волны света, скорее всего, информации понадобится даже больше. но это вообще не играет роли, потому что самое главное — это то, как эта информация масштабируется с увеличением сложности сцены. чем сложнее сцена, тем больше слоёв gbuffer'а необходимо. голограмма же эквивалентна иненно бесконечному количеству слоёв, закодированному в ячейке конечной плоскости. это как сравнение асимптотической сложности алгоритмов против их времени исполнения — какой бы большой константой ни была, всегда найдётся размер входных данных, для которых алгоритм с меньшей асимптотической сложностью будет работать быстрее.

#37
17:36, 23 апр. 2019

Suslik
у тебя в приоритете unbiased или realtime? Я думаю, эти вещи слабо совместимы, даже в 2019-м году.

#38
17:50, 23 апр. 2019

g-cont
у меня в приоритете алгоритмы, которые построены на реальной физике, то есть которые при определённых условиях можно хотя бы гипотетически масштабировать до unbiased. а это вполне может быть realtime.

#39
17:52, 23 апр. 2019

Suslik
очень познавательно, жду продолжения, спасибо!

#40
19:24, 23 апр. 2019

Бедный Суслик: каждый раз при упоминании SSGI ему приходится отвечать на одни и те же тупые вопросы. +1 к ждущим продолжение.

#41
21:41, 23 апр. 2019

Suslik
> кого ты ждёшь, давай думать, как интеграл брать!
Меня больше интересует unbiased в том варианте, что я написал, поэтому современные реалтайм варианты мне не в кассу. В общем, к моей области интереса относится вопрос: как в бюджет 100–1000 лучей на пиксель запихнуть сцену произвольной сложности? Конечно, есть шанс, что на пути к этому получится реалтайм, но невысокий.

Ну и, собственно, решение уравнения рендеринга — это типичная real-world problem. Для ее решения сначала надо сделать декомпозицию на отдельные модельные задачи, решить их, а потом думать, как все это собрать в единый и эффективный алгоритм. Ну а нерешенных проблем даже в моей области интереса (реалтайм до них даже не доходит) вагон и маленькая тележка.

Например, проблема каустики: как получить несмещенное изображение в ESDSL случае с точечным источником?
Или проблема сложности: есть куча процедурно генерируемых мелких объектов на большом расстоянии (видимые расстояния много меньше пикселя), как получить несмещенное изображение? Частный случай с более-менее понятным решением: получить изображение объекта с мелкой текстурой. Или в комбинации с каустикой: на большом расстоянии находится зеркальная поверхность с шумовым процедурным дисплесментом ("длина волны" много меньше пикселя).

> я практически уверен, что единственный способ рассчитать уравнение рендеринга эффективно — это считать его нелокально.
Собственно, локально решить проблему каустики невозможно, поэтому я тоже думал в этом направлении.
Однако, у меня это пока сводится к попытке пускать не один, а два скореллированных луча.
Возможно, что-то типа этого можно будет использовать и для пачки экранных пикселей.

> значит ли это, что за то же время можно рассчитать GI?
Если учесть, что от небольшого изменения базисных функций FFT перестает работать, то я думаю, что не выйдет.
Возможно, здесь больше подойдет аналог решения задачи N тел за O(N), но там только изотропные источники без затенения.

> голограмма же эквивалентна иненно бесконечному количеству слоёв, закодированному в ячейке конечной плоскости.
Ограниченный размер или разрешение голограммы сводят это на нет, поэтому я скептически отношусь к возможности использования голограмм для целей GI. Мне кажется, что голограмма по сути будет эквивалентна полусферической панораме в каждом пикселе экрана.

#42
23:51, 23 апр. 2019
Например, проблема каустики: как получить несмещенное изображение в ESDSL случае с точечным источником?

несмещенную никак, а состоятельную оценку вполне (consistent estimator), например, progressive photon mapping, что на практике может быть не хуже несмещенной.
Или проблема сложности: есть куча процедурно генерируемых мелких объектов на большом расстоянии (видимые расстояния много меньше пикселя), как получить несмещенное изображение?

тут совсем нет проблем с несмещенной оценкой
#43
0:15, 24 апр. 2019
Как бы хорошо rtx ни выглядел для зеркальных поверхностей, у него есть принципиальные проблемы с общностью, из-за которых он в принципе неэффективен для рендеринга матовых поверхностей.

Удивительно, но факт, что в Метро RTX используется для GI диффузных поверхностей :)

И еще факт, что скорость сходимости метода Монте-Карло не зависит от размерности, поэтому в world space не нужно больше лучей.

#44
2:01, 24 апр. 2019

Const
> несмещенную никак
Если даже я, не особо углубляясь, придумал как это сделать, то очевидно, что утверждение не соответствует действительности.

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

> И еще факт, что скорость сходимости метода Монте-Карло не зависит от размерности
Только идеального алгоритма. На практике каждая новая размерность мультипликативно ухудшает сходимость и имеем проклятие размерности. А если еще вклады знакопеременные, то получаем дополнительно и проблему знаков.

Страницы: 1 2 3 4 510 Следующая »
ПрограммированиеФорумГрафика