Hi,

mein Ziel ist es, einige Würfel in ein Framebuffer Object zu rendern, das Resultat zurück in den Standard-Framebuffer zu malen und schlussendlich noch etwas (einen einfachen Quad) in den Standard-Framebuffer zu rendern, so dass es korrekt mit dem bereits gerenderten Zeug überlappt. Um dies zu erreichen, muss ich die Tiefendaten aus dem Framebuffer Object weiterverwenden. Deshalb habe ich eine Depth-Texture an das Framebuffer Object gebunden und verwende einen Shader, der die Tiefendaten aus der Textur ausließt und nach gl_FragDepth schreibt.

Der folgende Screenshot zeigt das Resultat:



Wie man deutlich erkennt, funktioniert das Überlappen nicht, wie es soll.

Ich habe eine Minimalanwendung geschrieben, welche das Problem reproduziert, mehr dazu später. Vor einigen Tagen spielte ich mit dem Code der Anwendung herum, während ich auf der Suche nach der Fehlerursache war, und habe folgendes festgestellt: Wenn ich die Near Clipping Plane nach hinten setze und die Far Clipping Plane nach vorne, den Quotienten aus beiden also verkleinere und somit die Präzision der Depthbuffer erhöhe, wird der beobachtete Effekt weniger stark ausgeprägt. Der nachfolgende Screenshot zeigt dieselbe Szene wie eben mit glDepthRange( 1, 50 ) an Stelle von glDepthRange( 0.1f, 100 ) im Original:



Nun schaut es so aus, als würden die Tiefenwerte - irgendwie - viel zu stark quantisiert werden. Aber warum? Es kann eigentlich nicht an der Präzision der Depth-Texture liegen, welche bei 24 bit liegt, da der Effekt genau gleich bleibt, wenn ich die Präzision hier auf 32 bit erhöhe. Würde es an dessen Präzision liegen, hätte man ja erwartet, dass die Intensität des Effektes weiter abnimmt, was sie aber nicht tut.

Mir fallen zwei mögliche Ursachen für das Problem ein, auch wenn ich keine davon zu erklären in der Lage wäre: Also entweder die Projektionsmatrix geht auf irgendeine Weise "kaputt", so dass der Quotient aus Near- und Far Clipping Plane überdimensionale Größen erreicht. Oder die übernormale Quantisierung wird in der Anweisung "gl_FragDepth = texture2D( depthtex, gl_TexCoord[0].xy ).a" im Fragmentshader verursacht.

Vertexshader:


Fragmentshader:


Der wesentliche Quelltext der Minimalanwendung ist hier zu finden:
http://pastebin.com/UctqYW33

Ich verwende SFML2 zwecks Erzeugung des Contexts und Abfangen von Benutzereingaben.
Ist SFML2 auf dem System vorhanden, kann dieser Code zum Ausführen der Minimalanwendung verwendet werden:
http://pastebin.com/yJgvQpnK

Würde mich sehr freuen, wenn jemand die Zeit findet, mal drüber zu schauen, denn ich weiß absolut nicht weiter.
Mich würde erst einmal interessieren, warum es nicht funktioniert.
Es so hinzubiegen, dass es dann geht, ist eine darauf aufbauende Geschichte

Übrigens funktioniert alles, wie es soll, wenn ich direkt alles in den Standard-Framebuffer rendere und den FBO auslasse.

Vielen Dank im Voraus!

_________________

Bin gerade etwas knapp mit der Zeit, aber ich glaube das Problem liegt darin das du eben keine Depth-Texture benutzt, sondern einen normalen sampler2D. Es wäre möglich, dass du sampler2Dshadow nehmen musst. Ich habe aber bisher noch nie Depth-Texturen im Shader verwendet.

_________________
Yeah!

Um ein Texel von sampler2DShadow zu lesen (z.B. per shadow2D, laut Wiki) benötigt man aber ein Koordinaten-Trippel statt eines Tupels.
Was soll man hier denn als dritte Koordinate angeben?

_________________

Wenn ich mich recht erinnere werden die ersten beiden Koordinaten durch die dritte Koordinate geteilt, da man hier normalerweise eine Projektion benötigt. Jedenfalls müsstest du mit der dritten Koordinate gleich 1.0 das bekommen was du willst. Wenn das nicht klappt schau mal in die GLSL Spezifikation, da wird das ja irgendwo beschrieben sein.

_________________
Yeah!

Das Ergebnis sieht genauso aus wir vorher auch mit dem folgenden Fragmentshader:



Was ich für einen Wert als dritte Koordinate für shadow2D nehme, scheint keinen Unterschied zu machen - ich kann auch 0 oder 10 einsetzen, das Ergebnis sieht immer gleich aus.

_________________

Sorry, hatte das mit texture2DProj verwechselt.

Ein Blick in die Spezifikation hilft hier weiter:


Ein Blick in Abschnitt 3.8.14 zeigt das die dritten Komponente als Vergleichswert dient, so dass shadow2D direkt 0 oder 1 zurück gibt, je nachdem ob der Wert kleiner oder größer ist. Das ganze hängt aber von der Einstellung GL_TEXTURE_COMPARE_MODE ab, in der Default-Einstellung "NONE" hat die dritte Komponente wie du gemerkt hast keine Auswirkungen und shadow2D gibt dir hier einfach wie gewünscht den Tiefenwert.

Fazit: Das Problem liegt an anderer Stelle.

_________________
Yeah!

Jetzt bin ich verwirrt. Heißt das nun, dass der Shader-Code, so, wie ich ihn ursprünglich hatte, in Ordnung gewesen ist?

_________________

Gut möglich, wie gesagt ich hab das noch nie gemacht. Mit shadow2D ist es aber auf jeden Fall richtig.

_________________
Yeah!

OK. Und wie gehe ich nun weiter vor, um die Ursache des Problems zu finden?

_________________