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

hbao / hbao+ (10 стр)

Страницы: 19 10 11 1217 Следующая »
#135
(Правка: 15:20) 15:18, 10 авг. 2018

vindast
почитай, например, этот тред: https://gamedev.ru/code/forum/?id=226749

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

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


#136
18:29, 10 авг. 2018

Suslik, я в него заглядывал, но там сложно пока что)

#137
19:42, 10 авг. 2018

Suslik
> PS ну и неужели после нормального AO ты ещё можешь смотреть на какой-нибудь
> фейк вроде того, что у тебя было раньше?
Да нуу...
Тот алгоритм дешевый. Да на самом деле для меня вполне норм )

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

#138
19:46, 10 авг. 2018

Дока.
Я по ней делаю. Я думаю, я не правильно ищу тангенс с 11-го слайда.

#139
19:58, 10 авг. 2018

Еще вопрос. Там упоминаются функции ddX и ddY, зачем они там? Что они дают?

#140
20:14, 10 авг. 2018

vindast
> Я запутался как отсечь false-окклюзии.
даже не думай об этом пока.

vindast
> То есть, предлагаете искать не в плоскости изображения, а рассчитывать все в
> касательной плоскости нормали?
не играет роли, в какой плоскости считать. должно результат должен быть одинаковым в любой плоскости, если интегрирование правильно осуществляется. я говорю, что начальные значения горизонтов имеет смысл инициализировать, исходя из предположения, что в локальной окрестности точки горизонты образуют плоскость с известной нормалью.

vindast
> Еще вопрос. Там упоминаются функции ddX и ddY, зачем они там? Что они дают?
в glsl аналог https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/dFdx.xhtml
они их используют, чтобы строить нормаль к буферу глубины. если у тебя есть gbuffer с нормалями, то тебе это не надо.

#141
(Правка: 20:22) 20:17, 10 авг. 2018

Suslik
> я говорю, что начальные значения горизонтов имеет смысл инициализировать,
> исходя из предположения, что в локальной окрестности точки горизонты образуют
> плоскость с известной нормалью.
Такс. Разве не он не ноль всегда?

Suslik
> они их используют, чтобы строить нормаль к буферу глубины. если у тебя есть
> gbuffer с нормалями, то тебе это не надо.
Понял.

Я сейчас скрины залью с тем что есть сейчас.

#142
(Правка: 20:20) 20:19, 10 авг. 2018

vindast
> Такс. Разве не он не ноль всегда?
зависит от того, относительно какой оси ты считаешь углы. можно считать углы относительно нормали, тогда да, они будут нулевые, можно считать углы относительно вектора взгляда, тогда их надо инициализировать горизонтами пересечения с плоскостью нормали.

#143
20:21, 10 авг. 2018

Если я правильно понимаю, то сейчас проблема только с false-окклюзиями.

Изображение
Изображение
Изображение
#144
20:23, 10 авг. 2018

Suslik, перенесу весь алг. в касательную плоскость нормали, думаю там будет проще.

#145
(Правка: 20:29) 20:27, 10 авг. 2018

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

рекомендую для первой версии задать адекватное количество направлений(хотя бы 32 или что-то такое) и все дальнейшие улучшения алгоритма не должны влиять на результирующую картинку, должны только увеличивать производительность. начать можно с рандомизации направлений, более умной схемы семплинга точек, экспериментов с разными рандомизациями, depth aware blur'а, interleaved rendering и так далее и тому подобное.

#146
20:29, 10 авг. 2018

Suslik
> interleaved rendering
Это что?

#147
(Правка: 20:31) 20:30, 10 авг. 2018

vindast
следующий шаг после 5 предыдущих. когда до туда дойдёшь, спроси то же самое у гугла. пока что объяснять смысла нет, потому что у тебя вообще никакой схемы рандомизации нет, поэтому никакого толка от interleaved rendering'а всё равно не будет и проблемы, которую он решает, у тебя ещё даже нет.

#148
20:32, 10 авг. 2018

Suslik
> это не серьёзно, его нужно ускорять в десятки и сотни раз прежде, чем он будет
> для чего-то полезен.
Я заглянул в Вашу тему но тем не менее, я не вижу способа ускорить происходящее значительно, речь даже не о десятках, ну максимум раза в 3.

#149
(Правка: 20:48) 20:39, 10 авг. 2018

vindast
> Я заглянул в Вашу тему но тем не менее, я не вижу способа ускорить происходящее
> значительно, речь даже не о десятках, ну максимум раза в 3.
ну вот выше обозначенный lsao, например. если ты для одного направления делаешь для каждого пикселя, например, 50 выборок, то каждый пиксель ты прочитаешь для каждого из 50 пикселей, лежащих с ним на одной прямой. а можешь пройтись по этой прямой один раз и прочитать каждый пиксель на ней по 1 разу -> экономия в 50 раз. но этого мало, нужно гораздо больше.

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

far field occlusion всегда имеет гораздо более низкую частоту, поэтому нет смысла семплить далёкие пиксели с такой же точностью, с какой ты семплишь ближние. поэтому для обеспечения того же радиуса в 200 пикселей вместо 200 выборок ты можешь легко уложиться в 20, но с правильным распределением плотности. но и этого мало.

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

не существует одной каноничной реализации, которую бы все использовали. каждый использует свою версию AO, что говорит о том, что исследование по-прежнему идёт и нужно искать лучшие пути самому.

Страницы: 19 10 11 1217 Следующая »
ПрограммированиеФорумГрафика