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

Suslik в заговоре с Global Illumination (23 стр)

Страницы: 122 23 24 2530 Следующая »
#330
(Правка: 11:51) 11:50, 1 сен 2022

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

#331
(Правка: 11:59) 11:58, 1 сен 2022

Suslik
Кстати, а чем твой новый алгоритм отличается особо от старого?
Вроде там тоже была трассировка лучшей с шагом, увеличивающимся с расстоянием.

Чем новый подход лучше? Он быстрее/точнее? Может быть заиспользован в большем количестве случаев?

И да, если можешь выложить демку на github, обязательно это сделай. Думаю, кому-нибудь она может быть полезной.

#332
(Правка: 12:04) 12:03, 1 сен 2022

Panzerschrek[CN]
> Чем новый подход лучше? Он быстрее/точнее? Может быть заиспользован в большем
> количестве случаев?
основная разница в том, что старый подход уменьшал частоту семплинга по удалению от точки, для которой собирается вторичный свет. то есть удалённые блокеры, грубо говоря, считаются с низкой детализацией. в новом подходе наоборот: вся область интегрирования семплится с одинаковой частотой, однако, результат семплинга удалённых объектов влияет сразу на много точек. в результате можно получать длинные геометрически правильные вторичные тени без паразитного размазывания, причём результат за то же время сходится настолько точно, что даже денойзер не нужен. то есть, другими словами — за то же самое вычислительное время можно получить гораздо точнее результат.

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

#333
12:16, 1 сен 2022

Suslik
> алгоритм работает дольше предыдущего, но он гораздо быстрее сходится
Можно тогда считать его в уполовиненном разрешении.

Так или иначе, надо видимо посмотреть сравнение обоих алгоритмов на одних и тех же сценах. Буду ждать этого.

#334
(Правка: 12:23) 12:20, 1 сен 2022

Panzerschrek[CN]
> Можно тогда считать его в уполовиненном разрешении.
кстати, очень интересное и показательное свойство у этого алгоритма: у него скорость в половинном разрешении практически не отличается от скорости в полном разрешении. более того, у него даже в 1/16 скорость примерно та же, потому что основное вычислительное время уходит на расчёт дальних окклюдеров, а этот расчёт и так происходит вверху иерархии в низком разрешении разрешении в то время как в высоком разрешении внизу иерархии считаются только самые кончики теней, то есть только малюсенький "острый" участок пенубры, а это очень дёшево. и это по идее правильно, потому что основная "сложная" часть GI, ассоциированная с дальнодействием, по идее должна иметь низкочастотный характер, она не должна зависеть от разрешения.

#335
13:43, 1 сен 2022

Suslik
> в каждой лайт пробе уже находится информация о геометрии сцены, которая
> находится на сфере радиуса R
вопрос что это за информация, SDF? BVH/BSP? и как её быстро получать для динамики

#336
(Правка: 13:49) 13:49, 1 сен 2022

#!
каждая лайтпроба — это просто текстура на сфере. её задача — любому направлению луча, выходящему из центра пробы, поставить в соответствие луч (цвет+прозрачность).

#337
(Правка: 16:18) 16:10, 1 сен 2022

жесть, #328 сработало

Изображение

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

#338
16:21, 1 сен 2022

Suslik
Немного заметны артефакты - тени достаточно резко меняют толщину/интенсивность.

#339
(Правка: 16:30) 16:28, 1 сен 2022

пока что я не обуздал каскады и они не стыкуются. короче, объясняю, в чём последняя идея.

марширование по лучу в каком-то смысле эквивалентно разблюриванию изображения вдоль этого луча с вычислительной точки зрения. например, чтобы промаршировать по лучу на 8 пикселей, это в каком-то смысле эквивалентно тому, чтобы разблюрить изображение П-образным фильтром с радиусом в 8 пикселей:

........O.......
v
.....OOOOOOOO...

это можно сделать просто циклом 0<i<8. а можно это сделать в 3 прохода, каждый раз делая один тап и накладывая изображение само на себя со смещением:

........O.......
v
........OO......
v
.......OOOO.....
v
.....OOOOOOOO...

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

#340
(Правка: 17:27) 17:18, 1 сен 2022

Suslik
захватывающе интересно, мог бы еще показать, как будут выглядеть более мелкие детали (уменьшить размер "кисти")?
или вообще какой-нибудь фрактал для теста нарисовать.

#341
22:56, 1 сен 2022

Suslik
> то есть теоретически из алгоритма GI можно вообще исключить часть, отвечающую за рейтрейсинг
Тут трейдофф между 2D и 3D: трассирующие алгоритмы хранят/обрабатывают информацию только на поверхностях. В трехмерном варианте можно быстро упереться в ограничения по памяти.

#342
23:30, 1 сен 2022

Suslik
> пока что я нахожусь в таком же состоянии, как когда первый раз пощупал fft
грац! знакомое чувство

#343
4:32, 2 сен 2022

}:+()___ [Smile]
> Тут трейдофф между 2D и 3D: трассирующие алгоритмы хранят/обрабатывают информацию только на поверхностях. В трехмерном варианте можно быстро упереться в ограничения по памяти.
для расчёта GI в 3д достаточно хранить информацию о свете только на видимой на экране поверхности, то есть только в gbuffer'е. проблема в том, что информация о глубине в gbuffer'е потенциально "затрудняет" передачу информации от пробы к пробе, то есть закон, по которому пробы обмениваются лучами, затрудняется, и не факт, что доступной в них информации будет достаточно, чтобы построить весь GI так же как в 2д. пока что я хочу обуздать хотя бы 2д.

#344
4:38, 2 сен 2022

Suslik
> для расчёта GI в 3д достаточно хранить информацию о свете только на видимой на экране поверхности
Это только для однократного отражения. Если итерировать до сходимости, то нужно накапливать свет на всех поверхностях в окрестности камеры (особенно, если уйти от чистого диффуза и добавить зеркальных поверхностей).

Страницы: 122 23 24 2530 Следующая »
ПрограммированиеФорумГрафика