Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / SSAO

SSAO

Страницы: 1 2 Следующая »
IBetsПользовательwww5 ноя. 20184:57#0
Как избавиться от этой хрени. Normal bias не спасает. Результат что во ViewSpace, что WorldSpace одинаково хреновый. Возможно не хватает точности нормалей.
+ Показать

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

SuslikМодераторwww5 ноя. 20186:24#1
IBets
> Normal bias не спасает. Результат что во ViewSpace, что WorldSpace одинаково
> хреновый. Возможно не хватает точности нормалей.
вот как ты так программируешь? напихать спёртый откуда-то паковщик gbuffer'а, не разобравшись толком, нашлёпать сверху на него чей-то АО, а когда что-то не работает, создавать тему на форуме. тебя отладчик что ли забанил? ни у кого на форуме нет доступа к твоему проэкту и никто кроме тебя не сможет заменить упакованные нормали, например, на RGB32F, чтобы убедиться, что дело точно не в них. у ссао тоже свои параметры есть, неужели так сложно поставить там миллион итераций вместо 5, чтобы посмотреть, к правдоподобному ли решению оно сходится?
IBetsПользовательwww5 ноя. 20186:44#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

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

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

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

IBetsПользовательwww5 ноя. 20186:59#4
Suslik
Да так и делаю. Перезагрузка шейдеров на лету(сделал по простому не парился с файловой системой, ловлю Ctrl+S ну дальше сам знаешь), но это компьютерная графика дебажить можно бесконечно))
SuslikМодераторwww5 ноя. 20188:18#5
IBets
тогда, как я уже сказал, в первую очередь проверяй, что нормали выводятся правильно(убери компрессию gbuffer'а, выводи нормали с float32 точностью), во вторую — увеличивай параметры точности своего ssao, чтобы понять, к правильному ли решению он сходится.
IBetsПользовательwww5 ноя. 20189:45#6
Suslik
Не точности нормалям хватает вот c R32G32B32A32. Главное что с противоположной стороны sponz-ы, такой проблемы нет. У меня закончились мысли на этот счет. Да без нормал маппинга тоже пробовал. Возможно дичь происходит со стороны GPU. При расчете обратной матрицы
+ Показать

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

SuslikМодераторwww5 ноя. 20189:57#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?

IBetsПользовательwww5 ноя. 201810:32#8
Suslik
Результат более чем печален. 'I', 'N', 'T', 'Z' для глубины юзаю. Через нее и восстанавливаю
+ Показать

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

IBetsПользовательwww5 ноя. 201811:11#9
IBets
Короче забил на нормаль, мне восстанавливать ее дорого. Получаю нормаль через глубину и все по красоте. Странно почему сам не додумался до этого. Благодарю за хак
SuslikМодераторwww5 ноя. 201811:41#10
IBets
> Результат более чем печален
я не вижу никаких очевидных косяков. нормали расходятся именно там, где они должны расходиться — там, где normal map даёт бОльшую детализацию, чем нормали из буфера глубины. на плоскостях, например, цвет белый, то есть в принципе нормали в правильном пространстве задаются и у разницы нету шума, поэтому, скорее всего, в исходных нормалях шума тоже нет.

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

vindastПостоялецwww5 ноя. 201814:00#11
IBets
> с противоположной стороны sponz-ы, такой проблемы нет.
По моему, это потеря знака.
BingoBongoПостоялецwww5 ноя. 201814:39#12
Могу тебе сказать только что у меня с оригинальными нормалями и координатами в eye-space в этих местах в sponza тоже были такие же затемнения при ssao.

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

IBetsПользовательwww5 ноя. 201820:53#13
BingoBongo
Может быть нормали кривые в данном месте у самой модели?
IBetsПользовательwww5 ноя. 201821:00#14
vindast
В R32G32B32A32 такая же проблема. Может быть BingoBongo прав
Страницы: 1 2 Следующая »

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

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