Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / hbao / hbao+ (2 стр)

hbao / hbao+ (2 стр)

Страницы: 1 2 3 416 Следующая »
SuslikМодераторwww3 авг. 201813:59#15
vindast
> Может это по тому что у меня линейный ao? то есть перекрыто 50% семплов, то и
> Ao = 0.5
насколько я понял, у тебя вообще не hbao, а обычный ao. у hbao вообще нет понятия перекрытости семплов, есть просто угол горизонта для каждого направления, а направления выбираются в экранной плоскости.

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

Правка: 3 авг. 2018 14:01

vindastПостоялецwww3 авг. 201814:02#16
Тут сэмплы видный.
+ Показать
vindastПостоялецwww3 авг. 201814:04#17
Suslik, Вы не поняли. Я оставил эти скрины в начале темы что бы MrShoor не говорил, что у меня ssao косячный.
vindastПостоялецwww3 авг. 201814:05#18
Suslik, по моему c ssao все хорошо.
SuslikМодераторwww3 авг. 201814:06#19
vindast
> Может это по тому что у меня линейный ao? то есть перекрыто 50% семплов, то и
> Ao = 0.5
в общем случае в уравнении рендеринга
Изображение
есть ещё [cht](\vec \omega \cdot \vec n)[/cht], который ты в этом случае не учитываешь. в принципе, без учёта этого косинуса у полученной величины смысл хоть и не будет количеством падающего света, но результат тоже должен выглядеть нормально.

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

vindastПостоялецwww3 авг. 201814:07#20
Suslik, лучше использовать радиус, зависящий от расстояния?

Правка: 3 авг. 2018 14:08

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

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

Правка: 3 авг. 2018 14:16

vindastПостоялецwww3 авг. 201814:18#22
vindast
> 1 / 2 разрешения fhd, ~1.3 мс.

Норм?

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

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

Правка: 3 авг. 2018 14:21

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

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

Правка: 3 авг. 2018 14:30

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

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

Правка: 3 авг. 2018 18:20

vindastПостоялецwww3 авг. 201817:37#26
Suslik
> 2) луч считается перегороженным, если хоть одна его точка перегорожена, а не
> только конец.
Я так понимаю это ssao + уже
vindastПостоялецwww3 авг. 201818:06#27
Норм?
vindastПостоялецwww3 авг. 201818:21#28
Suslik
> нужен более умный алгоритм
Какой?
SuslikМодераторwww3 авг. 201818:41#29
vindast
> Но тут будет тогда лучше смотреться вариант с равномерным распеределением по
> сфере и одинаковой длине лучей.
да, для начала можно попробовать примерно так.

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

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

Правка: 3 авг. 2018 18:43

Страницы: 1 2 3 416 Следующая »

/ Форум / Программирование игр / Графика

2001—2018 © GameDev.ru — Разработка игр