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

SSAO

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

Как избавиться от этой хрени. Normal bias не спасает. Результат что во ViewSpace, что WorldSpace одинаково хреновый. Возможно не хватает точности нормалей.

+ Показать

5 ноя. 2018 (Правка: 5:00)

#1

IBets
> Normal bias не спасает. Результат что во ViewSpace, что WorldSpace одинаково
> хреновый. Возможно не хватает точности нормалей.
вот как ты так программируешь? напихать спёртый откуда-то паковщик gbuffer'а, не разобравшись толком, нашлёпать сверху на него чей-то АО, а когда что-то не работает, создавать тему на форуме. тебя отладчик что ли забанил? ни у кого на форуме нет доступа к твоему проэкту и никто кроме тебя не сможет заменить упакованные нормали, например, на RGB32F, чтобы убедиться, что дело точно не в них. у ссао тоже свои параметры есть, неужели так сложно поставить там миллион итераций вместо 5, чтобы посмотреть, к правдоподобному ли решению оно сходится?

5 ноя. 2018

#2

Suslik
> ни у кого на форуме нет доступа к твоему проэкту и никто кроме тебя не сможет
> заменить упакованные нормали, например, на RGB32F, чтобы убедиться, что дело
> точно не в них. у ссао тоже свои параметры есть, неужели так сложно поставить
> там миллион итераций вместо 5, чтобы посмотреть, к правдоподобному ли решению
> оно сходится?
Кто тебе сказал, что не разобрался? Этот всанный SSAO писал два дня ища косяк. А разница в том что текстурные координаты в DX9 и DX11 отличаются на пол-пикселя и поэтому позиция нормально не восстанавливалась. Вот линк https://aras-p.info/blog/2016/04/08/solving-dx9-half-pixel-offset/ . Здесь многие люди могут взглянуть на картинку и установить проблему, почему бы и не спросить? И да нормальных отладчиков под DX9 нет

5 ноя. 2018 (Правка: 6:45)

#3

IBets
> А разница в том что текстурные координаты в DX9 и DX11 отличаются на пол-пикселя и поэтому позиция нормально не восстанавливалась.
текстурные координаты в них одинаковые. разные координаты фрагментов в рендертаргете, а именно, в d3d9 фрагменты соответствуют углам пикселов, а в d3d11 (как в любом другом GAPI) — центрам. поэтому да, half-pixel offset.

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

5 ноя. 2018 (Правка: 6:50)

#4

Suslik
Да так и делаю. Перезагрузка шейдеров на лету(сделал по простому не парился с файловой системой, ловлю Ctrl+S ну дальше сам знаешь), но это компьютерная графика дебажить можно бесконечно))

5 ноя. 2018

#5

IBets
тогда, как я уже сказал, в первую очередь проверяй, что нормали выводятся правильно(убери компрессию gbuffer'а, выводи нормали с float32 точностью), во вторую — увеличивай параметры точности своего ssao, чтобы понять, к правильному ли решению он сходится.

5 ноя. 2018

#6

Suslik
Не точности нормалям хватает вот c R32G32B32A32. Главное что с противоположной стороны sponz-ы, такой проблемы нет. У меня закончились мысли на этот счет. Да без нормал маппинга тоже пробовал. Возможно дичь происходит со стороны GPU. При расчете обратной матрицы

+ Показать

5 ноя. 2018 (Правка: 9:55)

#7

IBets
я отлаживаю такие баги следующим образом:

vec3 depthNormal = normalize(cross(dFdx(worldPos), dFdy(worldPos)));
vec3 gBufferNormal = texture(depthSampler, screenPos).xyz;
if(length(depthNormal - gBufferNormal) > 1e-1f)
  gl_FragColor = vec4(1.0f, 0.0f, 0.0f, 1.0f);
else
  gl_FragColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);
идея в том, что нормали, восстановленные из буфера глубины, должны почти всегда совпадать с нормалями в gbuffer'е. по крайней мере в разнице не должно быть никакого шума.

IBets
> Главное что с противоположной стороны sponz-ы, такой проблемы нет
похоже на недостаток точности в чём-то. ты уверен, что никакую позицию чего-нибудь не восстанавливаешь через float16?

5 ноя. 2018

#8

Suslik
Результат более чем печален. 'I', 'N', 'T', 'Z' для глубины юзаю. Через нее и восстанавливаю

+ Показать

5 ноя. 2018 (Правка: 10:36)

#9

IBets
Короче забил на нормаль, мне восстанавливать ее дорого. Получаю нормаль через глубину и все по красоте. Странно почему сам не додумался до этого. Благодарю за хак

5 ноя. 2018

#10

IBets
> Результат более чем печален
я не вижу никаких очевидных косяков. нормали расходятся именно там, где они должны расходиться — там, где normal map даёт бОльшую детализацию, чем нормали из буфера глубины. на плоскостях, например, цвет белый, то есть в принципе нормали в правильном пространстве задаются и у разницы нету шума, поэтому, скорее всего, в исходных нормалях шума тоже нет.

а нормали, восстановленные из буфера глубины, дают эффект flat shading, где между каждой парой соседних полигонов будет излом вместо плавного перехода.

5 ноя. 2018

#11

IBets
> с противоположной стороны sponz-ы, такой проблемы нет.
По моему, это потеря знака.

5 ноя. 2018

#12

Могу тебе сказать только что у меня с оригинальными нормалями и координатами в eye-space в этих местах в sponza тоже были такие же затемнения при ssao.

5 ноя. 2018 (Правка: 14:43)

#13

BingoBongo
Может быть нормали кривые в данном месте у самой модели?

5 ноя. 2018

#14

vindast
В R32G32B32A32 такая же проблема. Может быть BingoBongo прав

5 ноя. 2018

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