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

Корректный HBAO (8 стр)

Страницы: 15 6 7 8 9 10 Следующая »
#105
19:12, 3 апр. 2019

Suslik
> это в фейках с ограниченным радиусом действия он зависит от расстояния до фрагмента
Я понимаю. Но ты говоришь «увеличить радиус до половины экрана». Если есть радиус, то есть и центр.


#106
2:39, 4 апр. 2019

San
> Но ты говоришь «увеличить радиус до половины экрана». Если есть радиус, то есть
> и центр.
у меня радиус задаётся не в мировых координатах и пересчитывается в экранные, а сразу задаётся в экранных координатах и равен размеру экрана.

#107
(Правка: 15:46) 15:45, 4 апр. 2019

Сомнения были небезосновательны. Подтвердилось 2 момента:
1. Присутствует косяк с зависимостью АО от угла обзора.
2. Расчеты верны.

Проверял основываясь на следующем:
Если смотреть на двугранный угол под углом в 45 градусов, и рассматривать V, пущенный из центра экрана, то получается вот так:
Изображение
Т.о. вклад освещения рассчитывается как 0.7 - (-0.7) = 1.4. Получается больше единицы из-за того, что мы рассматриваем только один луч (если я не ошибаюсь). При увеличении числа лучей значение сходится к 0.5.

Но если взять фрагмент с краю, то получается, что плоскость сэмплирования перестает быть перпендикулярной оси Х:
Изображение
Из-за этого получается так, что углы init и horz перестают быть равными 45° (становятся например 60°, соответственно, вклад освещения уже рассчитывается как 0.87 - (-0.87) = 1.74)
Логично было бы ожидать, что этот перекос будет устранен вкладом противоположного угла сэмплирования. Но на самом деле, в этом случае сэмпл берется не из "стены", а из "пола" (направление вниз), тангент совпадает с вектором горизонта и получается ноль, т.е. компенсация отсутствует.
Таким образом получается так, что угол обзора (точнее, перспективные искажения), влияет на значения АО. Это становится заметно, если уткнуться в сам угол или сильно увеличить радиус сэмплирования:
Изображение

Векторы нахожу так:

  vec2 dir = vec2(cos(angle), sin(angle));
  vec3 V = normalize(-P);
  vec3 B = normalize(cross(V, vec3(dir, 0)));
  vec3 D = normalize(cross(B, V));
  vec3 T = normalize(cross(B, N)); // N - нормаль из g-buffer
  vec3 H = S - P; // S и P - view positions соответственно, сэмпла и текущего фрагмента

UV для S рассчитывается как P_uv + dir * step_size.

Углы рассчитываются относительно вектора D в базисе BVD такой влобной функцией:

float get_sin(vec3 N, vec3 T, vec3 P) // N и T - соответственно нормальный и тангенциальный векторы
{
  float sign = dot(N, P) > 0 ? 1 : -1;
  // PN и PT - проекции P на оси направлений
  vec3  PN = N * dot(N, P);
  vec3  PT = T * dot(T, P);
  // Py и Px - расстояния от центра координат до проекций P
  float Py = length(PN);
  float Px = length(PT);
  float tg = Py / Px * sign;
  float an = atan(tg);
  return sin(an);
}

Угол init=get_sin(V, D, T), угол horz=get_sin(V, D, H).
Все вектора получаются ожидаемыми, значения тоже, векторы V, D, T, H лежат в плоскости сэмплирования, проекция вектора D на экран совпадает с вектором сэмплирования dir.
Т.е. багов в расчетах нет. Как починить это - непонятно.

#108
16:08, 4 апр. 2019

San
> Т.е. багов в расчетах нет.
если бы у тебя не было багов, то всё бы считалось правильно. проверь, что угол между всеми результирующими плоскостями семплирования равен в точности 2*pi/count. это условие должно выполняться вне зависимости от положения точки на экране. плоскость семплирования определяется как плоскость, проходящая через вектор view и направление семплирования. в расчёте угла у тебя просто атас. должно быть просто atan2(dot(delta, n), dot(delta, t)); и я тебе уже говорил, что при учёте нормали у тебя не получатся точные результаты, если ты используешь приближённые формулы из пейпера по hbao. точные результаты могут получиться только с полуаналитическим интегрированием формулами из gtao.

#109
(Правка: 16:39) 16:35, 4 апр. 2019

Suslik
> > Т.е. багов в расчетах нет.
> если бы у тебя не было багов, то всё бы считалось правильно
Я имею в виду то, что результат соответствует ожиданиям (см выше). Проблема не в самих расчетах, а уровнем выше.

> в расчёте угла у тебя просто атас
В бесконечных попытках отладить и не такое напишешь

> при учёте нормали у тебя не получатся точные результаты, если ты используешь приближённые формулы из пейпера по hbao
Правильно ли я понимаю, что используя вычисления HBAO не получится добиться сходимости для любого V? Получается, что я сейчас занимаюсь бессмысленной фигнёй?

#110
17:20, 4 апр. 2019

San

а чем не устроил какой-нибудь HDAO из dxsdk ?

#111
17:32, 4 апр. 2019
Если честно, я вот тут сидел, анализировал что тут пишут, свою поделку и тд. И что возник вопрос. А что такое HBAO вообще? Пайпер от нвидиа (в котором 4 луча по 4 пикселя)?
Или фар-филд трассировщик c qde как у суслика?
Что тут вообще является критерием правильности?

Suslik
> просто ао на картинке нету.
Я не понял эту предвяву) Как бы вот же оно на моих скринах.

San, ты ао вдоль каждого направления считаешь как синус наибольшего угла горизонта? Или как н-видиа предлагает искать добавлять к ао разность синусов?

#112
(Правка: 21:41) 21:38, 4 апр. 2019

innuendo
> а чем не устроил какой-нибудь HDAO из dxsdk ?
Все началось с того, что мне захотелось реализовать HBAO и сравнить с крайтековским SSAO. За пару часов получилось "что-то", но мне вспомнилось как Suslik где-то тут писал о нетривиальности правильной реализации HBAO. Стало интересно запилить все кошерно. Ну а с правильным HBAO можно и GI попробовать сделать, притом, что сама концепция - очень интересна, т.к. позволяет отвязать расчеты GI от геометрии сцены.
В общем, интересно было понять как это все работает и попробовать сделать самостоятельно, не для какого-то конкретного результата.

vindast
> ты ао вдоль каждого направления считаешь как синус наибольшего угла горизонта?
> Или как н-видиа предлагает искать добавлять к ао разность синусов?
Я с этим тупил тоже.
Тут важно понять, что разницы нет. Суть - в определении максимального горизонта. Поскольку интегрирование численное, т.е. делается сколько-то итераций по лучу, то можно на каждом шаге накапливать разницу между предыдущим и текущим горизонтом. Но в итоге все равно получится разница между начальным и максимальным.

> Что тут вообще является критерием правильности?
Я бы сформулировал это так: получаемый на практике результат должен приближаться к предсказываемым теорией значениям. Если полусфера фрагмента перекрыта наполовину, должно получиться 0.5 если перекрыта на 12.34%, должно получиться 0.1234. Как именно ты этого добьешься - не важно. Можно вообще пускать из фрагмента во всех направлениях стопицот лучей по стопицот шагов, но сам понимаешь, это неэффективно.
4 луча или пикселя не являются необходимым условием, а только определяют степень точности получаемых результатов (условно - 100 полигонов на модель или 100000). Near field, far field - неважно, это просто ограничения, которые не влияют на "правильность".

#113
3:18, 5 апр. 2019

San
> Правильно ли я понимаю, что используя вычисления HBAO не получится добиться сходимости для любого V?
я не помню, из каких соображений выводятся их формулы, но я не вижу причин, почему они должны сходиться к точному решению, так как формулы должны включать в себя нормаль в явном виде.

#114
(Правка: 17:21) 17:21, 9 апр. 2019

Suslik
Возникла пара вопросов.
1. При численном интегрировании с синусами вклад каждого сэмпла в GI можно учитывать пропорционально дельте угла горизонта сэмпла. Но как быть в случае с аналитическим интегралом через два максимальных горизонта (GTAO)? Нужно ли каким-то образом взвешивать (косинус?) каждый сэмпл при поиске максимальных горизонтов или можно как-то выкрутиться и использовать только 2 сэмпла по полученным горизонтам и уже посчитанную видимость?
2. Учитываешь ли ты каким-то конкретным образом влияние перспективы или же сам выбор базиса на основе view-вектора это должен автоматически разруливать? Спрашиваю потому что мне так и не удалось добиться идеальной точности для двугранного угла (уже с расчетами на основе GTAO).

+ Показать
#115
17:26, 9 апр. 2019

San
> Нужно ли каким-то образом взвешивать (косинус?) каждый сэмпл при поиске
> максимальных горизонтов или можно как-то выкрутиться и использовать только 2
> сэмпла по полученным горизонтам и уже посчитанную видимость?
если формула посчитана правильно, то косинус уже в ней. попробуй её сам вывести.

San
> 2. Учитываешь ли ты каким-то конкретным образом влияние перспективы или же сам
> выбор базиса на основе view-вектора это должен автоматически разруливать?
> Спрашиваю потому что мне так и не удалось добиться идеальной точности для
> двугранного угла (уже с расчетами на основе GTAO).
всё должно автоматически работать

San
> Вот так сейчас выглядит АО
выглядит правильно, но много артефактов из-за ограниченного радиуса.

#116
(Правка: 17:50) 17:49, 9 апр. 2019

Suslik
> много артефактов из-за ограниченного радиуса.
С этим буду разбираться позже. Лимит на радиус есть, но он выключен, а в случае с бесконечным радиусом, он вообще не нужен, но до этого еще далеко.

> если формула посчитана правильно, то косинус уже в ней. попробуй её сам вывести.
Ты о каком косинусе? Я пытаюсь понять откуда брать значения освещенности для GI. Из-за того, что в GTAO интеграл по лучу берется аналитически, то все движение по лучу - это просто поиск максимального горизонта. В процессе этого мы получаем угол между горизонтом сэмпла и view-вектором (точнее косинус). Но я не уверен, можно ли использовать его в качестве веса для освещенности.
Исходя из уравнения рендеринга получается, что нужно умножить фактор видимости на входящую освещенность. Видимость получается аналитически. А откуда взять освещенность?

В который раз у меня возникает навязчивая идея сэмплить радианс в направлении телесного угла (ведь он уже посчитан). Позже обязательно поэкспериментирую.

#117
3:29, 10 апр. 2019

San
> Но я не уверен, можно ли использовать его в качестве веса для освещенности.
это и есть угловой вклад сектора горизонта с учётом косинуса в освещённость. вклад в освещённость равен этому весу, помноженному на усреднённую яркость этого сектора. если этот сектор не излучает, то он создаёт вклад в ambient occlusion, если этот сектор излучает, то создаёт вклад во вторичное освещение. если этот сектор попадает за экран, то использует светимость ambient'а и создаёт вклад в освещение ambient light'а. все эти случаи должны покрываться одним выражением.

#118
(Правка: 12:21) 12:10, 10 апр. 2019

Suslik
> это и есть угловой вклад сектора горизонта с учётом косинуса в освещённость
Тогда я совсем ничего не понимаю. Это тот косинус, который dot(H, V), т.е. угол между горизонтом и view?
Как я понял, в GTAO сначала ищут максимальные горизонты относительно V, после чего, получив сектор видимости и используя нормаль, аналитически рассчитывают само значение видимости. Но если брать за вес dot(H, V), то выходит так, что интеграл берется численно и нет необходимости в вычислениях с нормалью. По сути, получаются те же расчеты, что и в HBAO, только вместо синуса - косинус, что весьма странно.
Похоже, мне никак не объяснить суть проблемы )

+ Показать

#119
12:49, 10 апр. 2019

San
разумеется, приращение между каждой парой семплов надо рассматривать отдельно

Страницы: 15 6 7 8 9 10 Следующая »
ПрограммированиеФорумГрафика