Das kommt dabei raus und laggt ziemlich noch dazu, also irgendwie falsch:
http://xenorate.com/tl_files/somekram/deferred%20renderind_2.jpg

Stell ich das blending von GL_ONE, GL_ONE auf GL_SRC_ALPHA, GL_ONE (ein wenig dunkler) siehts ähnlich wie vorher aus, aber der grüne Boden wird immernoch nicht richtig farbig beleuchtet.

Muss ich denn eigentlich nicht, den Albedo-Wert im Light-Accumulation-Pass dazu multiplizieren?
Damit im Light-Accumulation-Buffer am ende, auch der vollständige pixel ist oder ist das so richtig, das man nur die Lichtstärke/Farbe addiert?

Falls es was hilft, hier ist der code für den light accumulation pass:

Hey,

ich habe nicht alles 100% verfolgt, mich wundert es aber, dass du 3 Passes benutzt. Versuchst du dich an Light-PrePass oder normalem Deferred Rendering?
Ich hatte es so verstanden, dass du 2. versuchst. Und dabei kombinierst du im 2. Pass, also im Light-Pass bereits die finale Farbe für jedes Licht und addierst die einfach nur auf einander. Was du in deimen Licht-Shader auch zu tun scheinst, denn da berechnest du nicht die Licht-Farbe, sondern Lambert + Blinn-Phong auf Basis der Licht- und Albedo-Farbe.

Das Was du nach dem Licht-Pass bekommst ist also bereits die Composed-Farbe. (bzw sollte es sein)

Wenn du aber Light-PrePass versuchst musst du im 1. Pass (Geometry 1) nur Normale + Specular Wert speichern. Im 2. (Light-PrePass) dann die Lichtberechnung und im 3. (Geometry 2) dann die restlichen Material Eigenschaften der Geometry einberechnen, aber deine Codes sehen nicht danach aus.

Mir hat vor ner Weile bei der gleichen Aufgabe folgendes Tutorial geholfen, keine Ahnung ob dus schon kennst, ist allerdings OGL 3:
http://ogldev.atspace.co.uk/ (Kapitel 35-37)

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Ich hab weiter probiert und irgendwie war das gl_FragData[3] grotten falsch.
Denn als ich versucht habe, nur ne farbe ausgeben - vec4(1.0, 0.0, 0.0, 1.0), sah es recht merkwürdig aus.
Umgestellt auf gl_FragData[0] und dann hat es zumindest mit der Farbe geklappt.

Ich frage mich die ganze Zeit, wie hat es denn überhaupt funktioniert O_o
Ich verstehe aber nicht wieso gl_FragData[3] nicht geht, denn ich render ja in GL_COLOR_ATTACHMENT3 -.- whatever.

Aber das hat effektiv nichts gebracht - gleiches ergebnis.



Ich versuche normales Deferred Rendering, also ohne Light-Pre-Pass. Was ich aktuell versuche:

1. Pass: GBuffer füllen (Albedo, Normal, Position)
2. Pass: Light Accumulation (Licht-Intensität + Light-Farbe in den LABuffer Blenden - Multi-Pass für jedes Licht)
3. Pass: Finales Fragment = (Albedo * Ambient Color) + (Albedo * Light Accumulation)

Ich habe schon ziemlich viel ausprobiert und könnte mir den 3 Pass komplett sparen, denn das finale Ergebnis könnte auch in den LA-Buffer rein.

Vor allem will ich am ende dieses hier umsetzten:
http://www.john-chapman.net/content.php?id=13 <- Aber da bin ich noch weit davon entfernt.

Vielleicht werf ich die Lichtfarbe über bord, und nehm einfach weiße Lichter, damit geht es ja -.-

Hmm ich glaub ich versteh warum es nicht, es liegt wohl doch am Albedo, bzw. an den Farben... würde ich normale Texture verwenden, dann ist es sehr unwahrscheinlich das ich Farbwerte habe, bei der eine Komponente 0 ist.

Daher ist auch vec4(1.0, 0.0, 0.0, 1.0) * vec4(0.0, 1.0, 0.0, 1.0) = Schwarz.

1.0 * 0.0 = 0.0
0.0 * 1.0 = 0.0
0.0 * 0.0 = 0.0
1.0 * 1.0 = 1.0

Multipliziere ich also farbiges Licht mit einer Grundfarbe, also eine Farbe bei dem Komponenten 0 sind, dann habe ich genau diese Effekt.
Addieren macht das zwar dann richtig, aber dann gibt es keine nicht-beleuchteten Pixel

Dein Position-Buffer enthält die Koordinaten im Object- oder World-Space?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Objekt-Space, also Vertex multipliziert mit der Modelview-Matrix, welches bei Meshes aktuell noch identity ist und im falle bei Licht, die position und skalierung für die Punktlichter. Camera Perspektive und View-Matrix werden nur für gl_Position beim GBuffer verwendet!

Siehe Shader: GBuffer.vert und GBuffer_Color.frag

Ach zum kotzen, jetzt habe ich mich mal über Light-Pre-Pass Rendering informiert und da stellt sich für mich gleich wieder ne Grundsatz-Frage - Deferred Rendering oder Light pre pass rendering oder irgendwas anderes?

Light Pre-Pass ist doch im grunde Forward Rendering nur das die Lichtstärke und Farbe nachdem GBuffer kommen und man am ende, die Licht-Formeln wieder zusammen baut.

Ich will eigentlich nur erreichen, das statistische und dynamische Geometrie + ein aufwendiges Partikelsystem/Screen Space Fluid korrekt beleuchtet wird und ich nicht n Renderpfade mit Unterschiedlichen Beleuchtungstechniken benötige.
Halt ein einheitliches System für alle, damit man wenig passes wie möglich benötigt, dadurch auch wenig drawcalls.

Wie ich das Screen Space Fluid mit Deferred Rendering kombinieren kann, das ist mir aktuell noch ein Rätsel, denn da soll ja Semi-Transparenz verwendet werden auf basis von der Opaque-Geometrie, das aber schon beleuchtet sein muss. Sprich der Finale Pixel muss schon beleuchtet sein.

Es kommt so häufig vor, das man meint etwas zu verstehen und dann aber des besseren belehrt wird und noch unwissender ist als vorher ist

Mag sein, dass ich mich irre, aber wie soll da funktionieren?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Bezüglich dem Mal eine Anmerkung: Auch wenn du mit glDrawBuffer auf GL_COLOR_ATTACHMENT3 stellst, ist die Nummer die du im Shader brauchst trotzdem 0, weil du mit der Funktion angibts in welches Attachment primär gezeichnet werden soll. Und bei glDrawBuffers sind im Shader die Ziele dann auch auch entsprechend der Reihenfolge beziffert.
Ist auch irgendwie logisch, da sonst die Funktion sinnlos wäre, wenn GL_COLOR_ATTACHMENT3 immer gl_FragData[3] entsprechen würde.

Finalspace: Deine Berechnung ist korrekt. Ebenso die Aussage, dass es an den 0-Komponenten liegt. Licht ist multiplikativ, wenn es um die Beleuchtung von Objekten kommt. Sonst funktioniert Schwarz auch nicht. Was man aber machen kann, ist Specular mit ein bisschen weiß zu mischen. Das ist realistisch, weil kein Material bei specular reflection vollständig absorbiert.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Danke für den Tip mit der Specular-Farbe, ich seh zwar keinen Unterschied, aber später kommen die Specularfarben eh aus dem Material, daher ist das schonmal gut das zu haben

Jetzt komme ich endlich wieder ein wenig vorran, nun werd ich mich an ein Materialsystem wagen mit dem auch Screen Space Fluid Rendering möglich ist und auch Transparente Objekte, aber erstmal klein weiter machen mit einfachen Texturen

Vielen Dank nochmal an alle für die Hilfen bisher.

Ich werd euch auf jedenfall auf dem laufenden halten.

So ich habe mal den aktuellen Stand mal hochgeladen:
http://xenorate.com/tl_files/somekram/rps_deferred3.zip

Sieht teilweise noch merkwürdig aus, aber reicht erstmal für heute. Geometry welches direkt im Licht-Radius befindet wird sehr seltsam beleuchtet.
Irgendwie muss ich es schaffen, das der Mittelpunkt immer über der Normale stehen muss oder so... keine ahnung.

Das "max" verhindert das diffuse<0.0 wird und dadurch dem Licht abgewandten Flächen Farbe "geklaut" wird.

Also in den Shader PointLight.frag und DirectionalLight.frag habe ich das max nicht mehr drin gehabt. Und das sind auch die Zwei die verwendet werden. Kann sein, dass es in den alten Versionen noch drin war.

Für Specular ist das max wichtig, ansonsten stimmt nämlich die Specular-Formel nicht mehr und es sieht echt merkwürdig aus.

Macht es eigentlich sinn nachdem man mit dem Frustum-Culling dass sichtbare Licht ermittelt hat, noch zusätzlich einen Occlusion-Query Test zu machen? Wenn ja, wie verbinde ich das denn mit dem Deferred Rendering?

Habe das hier gestern gelesen:
http://www.heise.de/newsticker/meldung/OpenGL-ES-3-0-die-Zukunft-der-Tablet-und-Smartphone-Grafik-1660473.html?view=zoom;zoom=1