Hab mich schon gewundert, was Flash überhaupt will. Da ist doch ein schön verständlicher Wikieintrag.
_________________ Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut. Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’. Und du schaust mich an und fragst ob ich das kann. Und ich denk, ich werd' mich ändern irgendwann. _________________Farin Urlaub - Bewegungslos
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.
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?
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
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. 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.
_________________ Yeah!
Zuletzt geändert von Coolcat am Mo Mär 15, 2010 17:02, insgesamt 1-mal geändert.
Registriert: Fr Jan 04, 2008 21:29 Beiträge: 419 Wohnort: Lübeck
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.
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....
Registriert: Mi Mär 09, 2005 15:54 Beiträge: 372 Wohnort: München
Programmiersprache: Delphi, C#, FPC
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
Registriert: Fr Jan 04, 2008 21:29 Beiträge: 419 Wohnort: Lübeck
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.
Registriert: Mi Mär 09, 2005 15:54 Beiträge: 372 Wohnort: München
Programmiersprache: Delphi, C#, FPC
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?
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.