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

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

Страницы: 1 2 3 410 Следующая »
#15
20:14, 22 апр. 2019

Panzerschrek[CN]
Потому что посчитать детальный GI в world space - слишком ресурсоемко. Плюс расчеты в world space несут адовый оверхед по сравнению со скринспейсом.
Голограммы тут притом, что потенциально это способ представления сцены в скринспейсе, но без потерь информации и возможностью полностью восстановить исходное 3d. Что-то типа depth peeling, но без костылей.

#16
0:14, 23 апр. 2019

Suslik
У тебя не хватает членов затухания с расстоянием у источников.
Если для первичных (3) на это можно забить, типа они направленные, то для вторичных (4) стоило бы добавить, хотя бы в виде зависимости [cht]L(\vec x)[/cht]. Еще буква [cht]L[/cht] используется для обоих типов, что нехорошо.

Еще я думаю, что ты, все-таки, неправильно используешь термин unbiased.
Unbiased — это не тогда, когда алгоритм в пределе своих параметров сходится к точному решению, а тогда, когда результат работы алгоритма (при конечных значениях параметров) суть случайная величина, среднее которой равно точному решению.

Ну и просто треп на тему:
На мой взгляд, для true unbiased (в том смысле, котором я написал выше) от трассировки лучей никуда не уйти.
Т. е. эффективные алгоритмы могут считать результат приближенно без трассировки, но финальный корректор придется делать именно ей. Я думаю, что побороть тормоза можно, если распространять вклад одного луча сразу на пачку соседних пикселей. Надо только придумать, как это делать математически корректно, не испортив среднее.

#17
(Правка: 4:23) 3:45, 23 апр. 2019

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

> Еще я думаю, что ты, все-таки, неправильно используешь термин unbiased.
может быть. поэтому я конкретизировал, что понимаю под этим словом

Panzerschrek[CN]
> Чё-то я не понял, зачем автор так неистово топит за техники, работающие в
> экранном пространстве. Это совершенно не глобальное освещение, а очень даже
> локальное. Ну а переход к голограммам вообще не понятно зачем здесь.
жаль, что многие так и не поняли, о чём речь. речь в первую очередь о размерности проблемы. я утверждаю, что проблему нужно решать как двумерную (а при использовании line sweep — вообще как одномерную), так как она сходится гораздо эффективнее, чем если рассматривать её как трёхмерную. а использование скринспейса — всего лишь одно из самых очевидных двумерных представлений, которое можно использовать.

#18
4:37, 23 апр. 2019

Suslik
> там интегрирование ведётся по телесному углу
В исходном интеграле да, а в (4) у тебя сумма.
Но не суть, жду следующей части ;)

#19
4:49, 23 апр. 2019

}:+()___ [Smile]
> В исходном интеграле да, а в (4) у тебя сумма.
а, да. там типа directional light'ы. энивей, оно в первую очередь для юллюстрации вычислительной сложности.

> Но не суть, жду следующей части ;)
кого ты ждёшь, давай думать, как интеграл брать! мне показались очень интересными эксприменты с голограммами, но меня не покидало ощущение, что нет смысла моделировать полностью всю волновую динамику, так как должно быть минимальное представление, обладающее теми же свойствами, но без волновой свистопляски.

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

#20
11:54, 23 апр. 2019

Я мало что понял если чесно, но видео убедительно

Совевую ТС - прикрути свой рендер там к МайнКрафту как люди уже делают и руби бабло

#21
12:31, 23 апр. 2019

mega_otec

У ТС и так целый Path of Exile для экспериментов и рубления бабла есть.

#22
13:28, 23 апр. 2019

nonamezerox

Ему что % капают помимо зарплаты?

#23
13:31, 23 апр. 2019

mega_otec
аппроксимации на спонзе и кубах не нужны

#24
13:59, 23 апр. 2019

Я не понимаю о чем вы...

Тут чел на трубе прикрутилтрейтрес к майнкрафту и рубит приличное бабло...

#25
14:57, 23 апр. 2019

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

#26
15:06, 23 апр. 2019

SSDO будет?

#27
15:46, 23 апр. 2019

Хорошая статья, но я не совсем понял почему утверждается что G-Buffer хранит двухмерную информацию. Там можно хранить всё что угодно, просто он распухнет и производительность сильно упадёт. И насчёт голограмм не понял тоже. Очевидно любая голограмма содержит на порядок больше информации чем нам кажется. Если вопрос только в том, чтобы хранить информацию об освещённости так как это делает голограмма, то мы скорее всего придём к какому-то хорошо знакомому и известному методу для компьютерной графики.

#28
(Правка: 16:50) 16:48, 23 апр. 2019

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

> Очевидно любая голограмма содержит на порядок больше информации чем нам кажется.
кому очевидно?

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

lookid
> SSDO будет?
ssdo — это самая первая, самая наивная реализация gi в скринспейсе, которая не учитывает ни far-field occlusion, ни far-field emission, ничего. так что нет, не будет.

#29
16:50, 23 апр. 2019

Suslik
> проблему нужно решать как двумерную
Тогда не называй это глобальным освещением. Твой подход - очередной обман, каких множество.

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