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

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

Страницы: 15 6 7 8 9 10 Следующая »
#120
(Правка: 18:30) 16:33, 17 апр. 2019

Решил вот вернуться к теме и попробовал сделать относительно полноценный GI (без косинуса - только на HBAO).
Но чтобы ничего не тормозило и выглядело более-менее нормально.

Что запилено:
- рандомизация направлений (non-interleaved)
- выбор мипа глубины и радианса по расстоянию до хита. формула подобрана методом тыка: mip=log(distance * 2) - 1
- временные хаки, призванные компенсировать отсутствие учета косинуса при фрагменте и как-то улучшить картинку (dot(N,H) в качестве косинуса и attenuation=smoothstep(0.0, 1.0, radius - length(H)))
- по идее нужно сделать шаг по лучу логарифмическим (ближе - плотнее)

Косяки so far:
- происходит засветка вторичкой геометрии, которая находится сильно дальше излучаемой поверхности. (0:25, 1:00 и 1:47 на видосе)
- при увеличении радиуса заметны шаги по лучу в виде чередующихся светлых и темных колец (хорошо видно на 1:30)
- криво определяется направление луча при его выходе за экран (примерно ясно как чинить), из-за этого криво вычисляется дефолтный эмбиент (в видосе он выключен)

Погонял на разных сценах. Штука замечательная, сильно улучшает картинку + нет необходимости как-то процессить геометрию. Нужно только косяки починить и оптимизнуть до упора. Ну и косинус добавить.

+ Показать


#121
16:42, 17 апр. 2019

San
видево не играет

#122
18:30, 17 апр. 2019

Misanthrope
И правда не работает. Починил.

#123
18:52, 17 апр. 2019

San

GL?
везде работает ?

#124
(Правка: 19:13) 19:11, 17 апр. 2019

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

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

San
> формула подобрана методом тыка: mip=log(distance * 2) - 1
можно аналитически рассчитать мип так, чтобы размер текселя был равен расстоянию между шагами по лучу

#125
(Правка: 18 апр. 2019, 8:01) 19:26, 17 апр. 2019

innuendo
GL 4.0. Винда 2016 с gtx980.
Шейдер простой, нет причин, чтобы он не работал где-то еще.
Проверял еще на макбуке со встроенным интелом - работает. С перфомансом там, конечно, похуже.
На интеле ботлнеком является генерация мипмапов, т.е. вызов glGenerateMipmap. Судя по показаниям профайлера, мипы генерятся на CPU лол.
Т.е. даже просто расчет средней яркости сцены через мип 1х1 роняет фпс ниже плинтуса )

Suslik
> у тебя сейчас какой-то там радиус можно менять
Для дебага полезно. Ну и в некоторых случаях может быть нужно все-таки ограничить радиус (несмотря на нефизичность этого).
А вообще, конечно есть возможность задавать радиус равным размеру экрана в скринспейсе.

> аналитически рассчитать мип
Вот про это размышлял, но пока не брался (точнее тупо воткнул логарифм пока что).

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

#126
(Правка: 19:37) 19:37, 17 апр. 2019

San
> GL 4.0. Винда 2016 с gtx980.
> Шейдер простой, нет причин, чтобы он не работал где-то еще.

выложи демку - потестю на AMD :)

> На интеле ботлнеком является генерация мипмапов, т.е. вызов glGenerateMipmap.
> Судя по показаниям профайлера, мипы генерятся на CPU лол.
> Т.е. даже просто расчет средней яркости сцены через мип 1х1 роняет фпс ниже
> плинтуса )

какой жесть - делай через rt или cs

#127
20:30, 17 апр. 2019

San
Темпоралку будешь прикручивать?

#128
(Правка: 20:37) 20:35, 17 апр. 2019

innuendo
> выложи демку - потестю на AMD :)
А демки нету. Есть проект, который пустил корни в гигабайты ресурсов и зависимостей. Сделать из него легковесную демку весьма проблематично. К тому же это еще далеко не конечный вариант.

> какой жесть - делай через rt или cs
Увы, CS is not an option. На маке GL4.0 - это максимум, а мне бы хотелось, чтобы апп работал на всем моем железе. RT - да, очевидный вариант.
А еще интересно было бы провести investigation - почему на интеле поведение такое. И понять в чем дело - в дровах интеловских, в макоси или в том, что текстура NPOT.
К слову, на другом маке, с AMD, ничего не тормозит.

Андрей5000
> Темпоралку будешь прикручивать?
Ни в коем случае :)
Мне не очень нравятся такие техники. Субъективно конечно же.

#129
20:47, 17 апр. 2019
Yo dawg we heard you like raymarching, so we put SSLR over SSGI so you can march while you march
+ Показать
#130
3:46, 18 апр. 2019

San
> А как ты разруливаешь ложноположительную засветку? У меня были разные попытки
> это невелировать. Лучший результат дал подход с определением того, с какой
> стороны плоскости, перпендикулярной нормали, находится сэмпл и его отбраковка
> по этому признаку (или как-то так, не помню уже точно). Но это хрень какая-то )
я для этого использую оценку через полином Чебышева по типу variance shadow mapping

San
> Yo dawg we heard you like raymarching, so we put SSLR over SSGI so you can
> march while you march
покажи, как у тебя разруливается disocclusion для sslr. например, если объект в воздухе висит, как у него выглядит отражение?

#131
22:15, 18 апр. 2019

Suslik
> например, если объект в воздухе висит, как у него выглядит отражение?
Не совсем понял про disocclusion, но вот:
Изображение

#132
23:53, 18 апр. 2019

San
Никак, кароч. Можешь блюрить и не очень будет заметно.

#133
2:24, 19 апр. 2019

lookid
> Никак, кароч
что значит "никак"? disocclusion может выглядеть очень по-разному — может быть как растянутый объект, может выглядеть как прерывистый силуэт, вариантов тут миллион.

#134
2:17, 20 апр. 2019

Кто нибудь адаптивыный ssao делал? Интегрируем Монте-Карло и проходимя денойзером

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