DGL
https://delphigl.com/forum/

Deferred Shadding fürs Wiki
https://delphigl.com/forum/viewtopic.php?f=21&t=9088		 Seite 1 von 2
Autor:  Flash [ So Mär 14, 2010 21:39 ]
Betreff des Beitrags:  Deferred Shadding fürs Wiki
Ständig höre ich in letzter Zeit "Deferred Shading".
Kann jemand mit Ahnung den Link oben mal füllen. Ich bin da nicht so auf dem Laufenden. :(
Autor:  igel457 [ So Mär 14, 2010 22:55 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Flash hat geschrieben:
Ständig höre ich in letzter Zeit "Deferred Shading".
Kann jemand mit Ahnung den Link oben mal füllen. Ich bin da nicht so auf dem Laufenden. :(

Done.
Autor:  Ziz [ So Mär 14, 2010 23:01 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Hab mich schon gewundert, was Flash überhaupt will. Da ist doch ein schön verständlicher Wikieintrag. :lol:
Autor:  Flash [ Mo Mär 15, 2010 12:07 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Schön, dass das so schnell ging. Hat jemand noch ein plakatives Bild um den Artikel abzurunden?
Autor:  Coolcat [ Mo Mär 15, 2010 12:24 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Hab die Erklärung am Anfang mal etwas verbessert. Zudem hab ich auch einen Stub-Artikel zu Inferred Lighting angelegt und verlinkt. Bilder hab ich leider nicht.
Autor:  Coolcat [ Mo Mär 15, 2010 14:33 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Jetzt hat igel457 noch mal editiert, was mich etwas irritiert:
Zitat:
bzw. die Lichtgeometrie (Kugel für ein Punktlicht, Kegel für ein Spotlight)

Kann mir jemand verraten was es mit dieser Lichtgeometrie auf sich hat? Wenn ich einfach ein Quad rendere kann ich aus glFragCoord und dem Depth-Wert aus dem G-Buffer wieder zurückrechnen und so an die 3D-Position kommen. Alternativ kann man auch die Position direkt im G-Buffer speichern. Dann den Abstand zwischen Lichtquelle und dieser Position bestimmen und ich weiß wie hell/dunkel mein Punktlicht an der entsprechenden Stelle ist. Wozu muss da eine Kugel oder gar ein Kegel gerendert werden?
Autor:  Aya [ Mo Mär 15, 2010 15:56 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Coolcat hat geschrieben:
Jetzt hat igel457 noch mal editiert, was mich etwas irritiert:
Zitat:
bzw. die Lichtgeometrie (Kugel für ein Punktlicht, Kegel für ein Spotlight)

Kann mir jemand verraten was es mit dieser Lichtgeometrie auf sich hat? Wenn ich einfach ein Quad rendere kann ich aus glFragCoord und dem Depth-Wert aus dem G-Buffer wieder zurückrechnen und so an die 3D-Position kommen. Alternativ kann man auch die Position direkt im G-Buffer speichern. Dann den Abstand zwischen Lichtquelle und dieser Position bestimmen und ich weiß wie hell/dunkel mein Punktlicht an der entsprechenden Stelle ist. Wozu muss da eine Kugel oder gar ein Kegel gerendert werden?


Weil das Licht ja evtl nur einen bruchteil vom bild ausmacht. Wenn du ein FullscreenQuad renderst für das Licht, wird auch das shading für das komplette Bild gemacht, obwohl evtl in 90% des Bildes nix vom licht zu sehen ist. Wenn man direkt eine fläche rendert nur für die fläche des sichtbaren lichtes wird der shading aufwand eben u.U. extrem minimiert :)

Aya~
Autor:  Coolcat [ Mo Mär 15, 2010 16:44 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Achso, das funktioniert aber nur dann korrekt, wenn sich die Kamera außerhalb des Lichtvolumens befindet. (*) Des weiteren kann man jeweils nur eine Lichtquelle verarbeiten. Bei der Quad-Lösung kann man so viele Lichtquellen in einem Pass verwenden, wie man Speicher in uniform-Variablen hat. Beide Verfahren haben ihre Vorteile, kommt wahrscheinlich auf die Situation an was besser ist.

Edit: (*) ok, man könnte auch nur die Innenseiten des Volumes rendern. Allerdings muss man dann aufpassen, dass diese nicht vom Far-Plane abgeschnitten werden. Das Verfahren eignet sich wenn die Radien der Lichtquellen relativ klein sind.

Edit2: *pling* ok, jetzt hab ich's gerafft. :lol: Eine einfache Fallunterscheidung: Wenn die Kamera innerhalb des Lichtvolumens ist wird ein Fullscreen-Quad gerendert, ansonsten das Lichtvolumen mit Backfaceculling. Ich denke mal, dass sollte man noch irgendwie in den Artikel einbauen, den das dürfte wirklich Performance bringen, wenn es viele winzige Lichtquellen (z.B. Glühwürmchen) sind.
Autor:  Sellmann [ Mo Mär 15, 2010 17:00 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Ich weiß nicht, ob ich das jetzt richtig verstanden habe, aber kann man nicht einfach den Radius der Lichtquelle verwenden (errechnen aus den Nullstellen der luminanz-abschwächenden Funktion) um einen Frustum-check zu machen und daraus einen Kreis zu rendern, den man dann auf den Screen projeziert und ohne Depthtest zeichnet?
So rendert man nur den Bereich, der vom Licht effektiv beeinflusst werden kann und hat nicht das Problem, dass die Viewposition inner- oder außerhalb des Lightvolumens ist.

Bei einem Kegel könnte man versuchen anhand von Richtung, Radius und Reichweite ein grob umschließendes 4-Eck (nicht unbedingt ein Quadrat oder Rechteck) zu errechnen.
Autor:  Coolcat [ Mo Mär 15, 2010 17:20 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Sellmann: Jein, ginge wahrscheinlich, aber z.B. ist eine Kugel nach der Projektion nicht zwangsläufig ein Kreis, es gibt da nämlich immer etwas Verzerrung, insbesondere am Bildrand.

Mein 2. Edit (siehe oben) ist übrigens nicht ganz korrekt. Es kommt nicht nur auf die Kameraposition an, sondern man muss auch testen ob sich das Near-Plane mit dem Lichtvolumen schneidet. Vielleicht hab ich auch noch was vergessen....
Autor:  littleDave [ Mo Mär 15, 2010 22:03 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Flash hat geschrieben:
Schön, dass das so schnell ging. Hat jemand noch ein plakatives Bild um den Artikel abzurunden?

Ich habe mal ein Screenshot der einzelnen Texturen des G-Buffers gemacht und hochgeladen. Wenn noch jemand eine Idee für Screenshots bezüglich Deferred Shading hat, kann ich entweder heute oder morgen Abend noch ein paar Machen
Autor:  Coolcat [ Mo Mär 15, 2010 22:07 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Zitat:
Wenn noch jemand eine Idee für Screenshots bezüglich Deferred Shading hat,

Es wäre wohl nicht schlecht auf einen Screen des finalen Bildes zu haben. Aber schön überhaupt mal schon ein paar Bilder zu haben. :)
Autor:  littleDave [ Mo Mär 15, 2010 22:20 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Coolcat hat geschrieben:
Zitat:
Wenn noch jemand eine Idee für Screenshots bezüglich Deferred Shading hat,

Es wäre wohl nicht schlecht auf einen Screen des finalen Bildes zu haben. Aber schön überhaupt mal schon ein paar Bilder zu haben. :)

*done*
Autor:  Sellmann [ Di Mär 16, 2010 07:44 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Ich finde, dass bei dem Beitrag die Screenshots auch zur Implementierung passen sollten. In den Screenshots wurde ein Tiefenpuffer benutzt (elegante Lösung) im Code wird einfach die Position in den G-Buffer geschrieben. Dem entsprechend gibt es dort auch keinen Abschnitt in dem gezeigt wird, wie man die Tiefe in eine Position zurückrechnet, bzw. die Tiefe vernünftig in den Buffer schreibt (lediglich der Hinweis dass es geht ist vorhanden, also nicht sonderlich hilfreicher als andere Seiten zu dem Thema).
Da Little Dave das schon programmiert hat, wäre es doch nur gut, wenn er das zum bisherigen ergänzt. Außerdem wäre evtl. auch eine Glsl Umsetzung interessant (Hlsl/Cg kann man zwar auch lesen, aber in diesem Forum wird es ja eher weniger verwendet). Auch wäre toll, wenn jemand ein Beispiel bringen könnte, wie man die Normalen komprimiert, in den Buffer schreibt und zum Verwenden bei Effekten wieder zurückrechnet.

Das sind meiner Meinung nach die interessanten Sachen am Deffered Shading. Alles andere ist ähnlich "frei formuliert" schon auf anderen Seiten zu finden.
Autor:  littleDave [ Di Mär 16, 2010 10:48 ]
Betreff des Beitrags:  Re: Anti-Aliasing
Sellmann hat geschrieben:
Ich finde, dass bei dem Beitrag die Screenshots auch zur Implementierung passen sollten. In den Screenshots wurde ein Tiefenpuffer benutzt (elegante Lösung) im Code wird einfach die Position in den G-Buffer geschrieben.

Ok, ich kann heute Abend eine Positions-Textur rendern und die dann hochladen - ist also als erledigt anzusehen.

Sellmann hat geschrieben:
Dem entsprechend gibt es dort auch keinen Abschnitt in dem gezeigt wird, wie man die Tiefe in eine Position zurückrechnet, bzw. die Tiefe vernünftig in den Buffer schreibt (lediglich der Hinweis dass es geht ist vorhanden, also nicht sonderlich hilfreicher als andere Seiten zu dem Thema).
Da Little Dave das schon programmiert hat, wäre es doch nur gut, wenn er das zum bisherigen ergänzt.
Außerdem wäre evtl. auch eine Glsl Umsetzung interessant (Hlsl/Cg kann man zwar auch lesen, aber in diesem Forum wird es ja eher weniger verwendet). Auch wäre toll, wenn jemand ein Beispiel bringen könnte, wie man die Normalen komprimiert, in den Buffer schreibt und zum Verwenden bei Effekten wieder zurückrechnet.

Das sind meiner Meinung nach die interessanten Sachen am Deffered Shading. Alles andere ist ähnlich "frei formuliert" schon auf anderen Seiten zu finden.

Deferred Shading an sich ist schon ein relativ umfangreiches Thema. Ich würde das Thema in mehrere Unterthemen (also eigene Seiten) aufteilen.

Auf der Deferred-Shading - Seite sollte meiner Meinung nach nur die theoretische Grundidee und noch ein paar Verbesserungen (wie das mit dem Tiefenpuffer, Normalenkomprimierung, ...) aufgeführt werden.

Auf einer weiteren Seite sollte dann eine Beispiel-Implementierung - vielleicht sogar als Tutorial, aufgezeigt werden. Denn wenn man jetzt zu den Cg-Shadern noch die entsprechenden GLSL-Shader hinzuschreibt, hat man drei Seiten Shader-Code, bei denen man zu schnell aufhört weiter zu lesen (da kein Ende in Sicht ist ;-) ). Das Auslagern in die Shader-Sammlung halte ich hier auch nicht für sooo perfekt, da die Shader doch sehr viel Abhängigkeiten haben (FBOs, Shader-Library [ist zumindest sinnvoll], Licht-Renderer, ...).

Ich würde die Implementation sogar noch weiter auf verschiedene Seiten aufteilen. Einmal eine Seite für die G-Buffer-Generierung bzw. die Initialisierung, eine Seite um den G-Buffer zu füllen (inkl. Shader-Source) und dann noch eine Seite für das Zeichnen von Licht.

PS: kann mal jemand hier die Deferred-Shading-Posts in ein neues Thema verlagern?
Seite 1 von 2 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/