Implementacja OpenGL GLSL SSAO

Próbuję zaimplementować Screen Space Ambient Occlusion (SSAO) w oparciu o Demo R5 znalezione tutaj: http://blog.nextrevision.com/?p=76

W rzeczywistości staram się dostosować ich SSAO-Linear shader do mojego małego silnika.

1) obliczam normalną powierzchnię przestrzeni widokowej i wartości głębokości liniowej. Zapisuję je w teksturze RGBA używając następującego shadera:

Wierzchołek:

varNormalVS = normalize(vec3(vmtInvTranspMatrix * vertexNormal));
depth = (modelViewMatrix * vertexPosition).z;
depth = (-depth-nearPlane)/(farPlane-nearPlane);
gl_Position = pvmtMatrix * vertexPosition;

Fragment:

gl_FragColor = vec4(varNormalVS.x,varNormalVS.y,varNormalVS.z,depth)

Do moich obliczeń głębokości liniowej odniosłem do: http://www.gamerendering.com/2008/09/28/linear-depth-texture/

Czy to prawda? Faktura wydaje się być poprawna, ale może tak nie jest?

Tutaj wpisz opis obrazka

2) rzeczywiste wdrożenie SSAO: Jak wspomniano powyżej oryginał można znaleźć tutaj: http://blog.nextrevision.com/?p=76

Lub szybciej: na pastebinie http://pastebin.com/KaGEYexK

W przeciwieństwie do oryginału używam tylko 2 tekstur wejściowych, ponieważ jedna z moich tekstury przechowują zarówno zwykłe jak RGB i liniowe Depht als Alpha.

Moja druga Tekstura, przypadkowa normalna Tekstura, wygląda tak: http://www.gamerendering.com/wp-content/uploads/noise.png

Używam prawie dokładnie tej samej implementacji, ale moje wyniki są błędne.

Zanim przejdę do szczegółów chcę najpierw wyjaśnić kilka pytań:

1) ssao shader używa projectionMatrix i jest to macierz odwrotna.

Ponieważ jest to efekt post processingu wyświetlany na ekranie wyrównany kwadrat za pomocą rzutowania ortograficznego, projectionMatrix jest macierzą ortograficzną. Poprawne czy złe?

2) ma połączoną teksturę normalną i głęboką zamiast dwóch oddzielnych.

Moim zdaniem jest to największa różnica między implementacją R5 a moją próbą implementacji. Myślę, że nie powinno to być dużym problemem, jednak ze względu na różne tekstury głębi jest to najbardziej prawdopodobne, aby powodować problemy.

Należy pamiętać, że R5_clipRange wygląda tak

vec4 R5_clipRange = vec4(nearPlane, farPlane, nearPlane * farPlane, farPlane - nearPlane);

Oryginalny:

float GetDistance (in vec2 texCoord)
{
//return texture2D(R5_texture0, texCoord).r * R5_clipRange.w;
const vec4 bitSh = vec4(1.0 / 16777216.0, 1.0 / 65535.0, 1.0 / 256.0, 1.0);
return dot(texture2D(R5_texture0, texCoord), bitSh) * R5_clipRange.w;
}
Muszę przyznać, że nie rozumiem fragmentu kodu. Moja głębia jest przechowywana w alfie mojej tekstury i pomyślałem, że wystarczy to zrobić
return texture2D(texSampler0, texCoord).a  * R5_clipRange.w;

Poprawne czy złe?

Author: Peter O., 2012-01-30

1 answers

Twoja normalna Tekstura wydaje się błędna. Zgaduję, że Twoja vmtInvTranspMatrix jest matrycą widoku modelu. Jednak powinna to być macierz model-widok-projekcja (należy pamiętać, że potrzebne są ekranowe statystyki przestrzenne, a nie obrazowe statystyki przestrzenne). Obliczenie głębokości jest poprawne.

Zaimplementowałem kiedyś SSAO i normalna Tekstura wygląda tak (zauważ, że nie ma tu niebieskiego):

przestrzeń ekranu normalna

1) ssao shader używa projectionMatrix i jest to macierz odwrotna. Ponieważ jest to efekt przetwarzania końcowego renderowany na ekran wyrównany quad poprzez rzut ortograficzny, projectionMatrix jest macierzą ortograficzną. Poprawne czy złe ?

Jeśli masz na myśli drugi przebieg, w którym renderujesz quad do obliczenia rzeczywistego SSAO, tak. Można całkowicie uniknąć mnożenia przez ortogonalną macierz rzutową. Jeśli renderujesz kwadrat ekranu o wymiarach [x,y] w zakresie od -1 do 1, możesz użyć bardzo prostego shadera wierzchołków:

const vec2 madd=vec2(0.5,0.5);

void main(void)
{
    gl_Position = vec4(in_Position, -1.0, 1.0);
    texcoord = in_Position.xy * madd + madd;
}

2) o połączonej teksturze normalnej i głębi zamiast z dwóch oddzielnych jeden.

Nie, to nie sprawi problemów. To powszechna praktyka.
 11
Author: stativ,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-01-30 15:23:10