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

hbao / hbao+ (2 стр)

Страницы: 1 2 3 417 Следующая »
#15
(Правка: 14:01) 13:59, 3 авг. 2018

vindast
> Может это по тому что у меня линейный ao? то есть перекрыто 50% семплов, то и
> Ao = 0.5
насколько я понял, у тебя вообще не hbao, а обычный ao. у hbao вообще нет понятия перекрытости семплов, есть просто угол горизонта для каждого направления, а направления выбираются в экранной плоскости.

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


#16
14:02, 3 авг. 2018

Тут сэмплы видный.

+ Показать
#17
14:04, 3 авг. 2018

Suslik, Вы не поняли. Я оставил эти скрины в начале темы что бы MrShoor не говорил, что у меня ssao косячный.

#18
14:05, 3 авг. 2018

Suslik, по моему c ssao все хорошо.

#19
14:06, 3 авг. 2018

vindast
> Может это по тому что у меня линейный ao? то есть перекрыто 50% семплов, то и
> Ao = 0.5
в общем случае в уравнении рендеринга
Изображение
есть ещё [cht](\vec \omega \cdot \vec n)[/cht], который ты в этом случае не учитываешь. в принципе, без учёта этого косинуса у полученной величины смысл хоть и не будет количеством падающего света, но результат тоже должен выглядеть нормально.

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

#20
(Правка: 14:08) 14:07, 3 авг. 2018

Suslik, лучше использовать радиус, зависящий от расстояния?

#21
(Правка: 14:16) 14:13, 3 авг. 2018

vindast
нет, радиус выборок от расстояния в явном виде зависеть не должен. просто он должен быть гораздо больше, чем у тебя сейчас(в 10-100 раз), а таким методом, как ты сейчас считаешь, это будет жутко медленно. поэтому методы вроде hbao ищут просто выборки в радиусе не в мировых координатах, а в экранных, поэтому получается как бы неявная зависимость от удалённости фрагмента — чем дальше фрагмент от камеры, тем больше получается радиус поиска в мировых координатах. но это просто следствие работы hbao, а не необходимое условие.

ну и учти, что получить просто правильную картинку — это самый первый шаг. самое сложное — это получить её за достаточное время. например, у меня скриншот выше считает ao вместе с global illumination меньше чем за 5мс, это гораздо сложнее, чем посчитать его за 30мс.

#22
14:18, 3 авг. 2018

vindast
> 1 / 2 разрешения fhd, ~1.3 мс.

Норм?

#23
(Правка: 14:21) 14:19, 3 авг. 2018

ещё я не уверен, но мне кажется, что у тебя выборки векторов распределены не равномерно, а по углам ширины и долготы(это неправильно). почитай, как правильно генерить вектор на полусфере с равномерным распределением: https://math.stackexchange.com/questions/1163260/random-direction… itrary-vector

vindast
> > 1 / 2 разрешения fhd, ~1.3 мс.
> Норм?
сколько семплов ты делаешь вдоль каждого направления? мне не нравится засвет внутри фар, ты уверен, что сканируешь весь луч, а не только конечную его точку?

#24
(Правка: 14:30) 14:26, 3 авг. 2018

короче, если ты просто проверяешь по одной точке на конце каждого луча, то это — не совсем ао. точнее, это древняя крайтековская аппроксимация(грубая) ао, которая достаточно далека от истины, хотя работает достаточно быстро. по идее чтобы получить корректную величину ao, надо добавить две вещи:
1) косинус при каждом луче. не забыть помножить результат на [cht]2\pi[/cht], чтоб сохранить нормализацию.
2) луч считается перегороженным, если хоть одна его точка перегорожена, а не только конец.

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

#25
(Правка: 18:20) 17:24, 3 авг. 2018

Suslik
> а не только конечную его точку?
Только. Ок, попробую в лоб. Но тут будет тогда лучше смотреться вариант с равномерным распеределением по сфере и одинаковой длине лучей. И буду проверять через 1/10 их, уменьшив количество семплов в несколько раз, но сделав ssao двух проходным. 1/2 и 1/4 кадра. По идее должно быть не плохо, и блюрить не надо.

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

#26
17:37, 3 авг. 2018

Suslik
> 2) луч считается перегороженным, если хоть одна его точка перегорожена, а не
> только конец.
Я так понимаю это ssao + уже

#27
18:06, 3 авг. 2018

Норм?

#28
18:21, 3 авг. 2018

Suslik
> нужен более умный алгоритм
Какой?

#29
(Правка: 18:43) 18:41, 3 авг. 2018

vindast
> Но тут будет тогда лучше смотреться вариант с равномерным распеределением по
> сфере и одинаковой длине лучей.
да, для начала можно попробовать примерно так.

vindast
> Не понятно, о какой такой нормализации тут идет речь?
если ты помножишь лучи на косинус угла, то сумма перестанет быть равной 1. чтобы получилась 1, нужно помножить на [cht]2\pi[/cht]. и далее нужно ещё раз провести тест, что на плоских поверхностях действительно получается в среднем освещённость = 1, потому что здесь это уже перестаёт быть очевидно.

vindast
> Какой?
например, hbao. но пока у тебя ещё до него далеко, потому что нужно первый шаг — нужно посчитать ao правильно. потом уже будешь думать, как это ещё посчитать быстро. пока что на видео вижу какую-то пересвеченную ерунду. ты опять что ли какой-то кривой power curve к результату применил? результирующая картинка должна получиться строго темнее того, что у тебя было, потому что на каждый луч должно получиться больше вероятности получить окклюжен.

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