spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

dann 3 Werte habe(für 3 Lichter) und die Addiere und durch 3 teile.

Jaein...
Du darfst aber nicht durch drei teiln, sondern bloß aufaddieren.

Stell dir vor du leuchtest mit zwei Taschenlampen an die Wand.
Ed wird doppelt so hell wie wenn du nur mit einer leuchtest.

Zitat von »Spiele Programmierer«

Und wie machen die das dann mit transparenten Objekten?
Ich vermute jetzt einfach mal das FSA auch solche in seiner Szene hat.

Es gibt verschiedene Ansätze. Der gängigste ist wohl transparente Objekte in einem weiteren Forward-Pass zu rendern.

Zitat von »Spiele Programmierer«

Bei gutem Frustumculling und Early-Z fällt der typische Vorteil von deferred Shading auch weg.

Nein, das stimmt nicht. Es geht ja nicht um die Lichtquellen die du ohnehin verwirfst, sondern um die Lichtquellen in einem Frame zu sehen sind. Da ist ein Deferred-Ansatz Forwardrendering weit überlegen.

Zitat

Es gibt verschiedene Ansätze. Der gängigste ist wohl transparente Objekte in einem weiteren Forward-Pass zu rendern.

Ist aber schwierig zu realisieren.
Weil deferred schneller mit viellen Lichtquellen umgehen kann, tut sich der Forward-Pass dannach arg schwer. Außerdem muss dieser exakt die gleiche Berechnungsausgabe haben wie der deferred Shader. Sonst gibts Übergänge.

Zitat

Nein, das stimmt nicht. Es geht ja nicht um die Lichtquellen die du ohnehin verwirfst, sondern um die Lichtquellen in einem Frame zu sehen sind. Da ist ein Deferred-Ansatz Forwardrendering weit überlegen.

Ich versteh jetzt leider nicht ganz was du mir damit sagen willst.
Der Vorteil von Deferred Shading ist doch, das nur die Pixel belleuchtet werden, die es überhaupt in der Renderingoutput schaffen.
Wenn ich aber vorher bereits alle sowieso später verdeckten rausschmeiße(-> early Z) dann kom ich doch auf das selbe Ergebnis.

Der Deferred Shading Ansatz hat allerdings zugegebenermaßen zb. noch zusätzliche Vorteile beim Post-Processing.
Der allerdings bei der Methode nachher nochmal nach der klassischen Methode reinzurendern entfällt.

Der wesentliche Vorteil von Deferred Shading ist imo, dass die Geometrie nur einmal transformiert werden muss
Nur die sichtbaren Pixel shaden schafft man, wie du schon bemerkt hast, z.B. mit einem z-Prepass auch beim Forward Renderer...

Zitat von »Spiele Programmierer«

Ist aber schwierig zu realisieren.
Weil deferred schneller mit viellen Lichtquellen umgehen kann, tut sich der Forward-Pass dannach arg schwer. Außerdem muss dieser exakt die gleiche Berechnungsausgabe haben wie der deferred Shader. Sonst gibts Übergänge.

Nein, das ist sehr einfach zu realisieren. Oft werden transparente Objekte einfach nicht beleuchtet. Falls dies trotzdem geschehen soll hat man natürlich die Probleme von Forward-Rendering. Allerdings ist die Anzahl der transparenten Objekte meißt ohnehin nur relativ klein. Spezialfälle, wie z.B. Partikeleffekte, werden meist anders behandelt. Beispielsweise nur per Vertex beleuchtet (etc).

Zitat von »Spiele Programmierer«

Ich versteh jetzt leider nicht ganz was du mir damit sagen willst.
Der Vorteil von Deferred Shading ist doch, das nur die Pixel belleuchtet werden, die es überhaupt in der Renderingoutput schaffen.
Wenn ich aber vorher bereits alle sowieso später verdeckten rausschmeiße(-> early Z) dann kom ich doch auf das selbe Ergebnis.

Der Deferred Shading Ansatz hat allerdings zugegebenermaßen zb. noch zusätzliche Vorteile beim Post-Processing.
Der allerdings bei der Methode nachher nochmal nach der klassischen Methode reinzurendern entfällt.

Der Vorteil von Deferred Rendering ist die Komplexität. Forward-Rendering hat eine Komplexität von O(nm), für n ist die Anzahl der Objekte und m ist die Anzahl der Lichter. Deferred Rendering hat eine Komplexität von O(n+m) und ist damit ganz wesentlich im Vorteil. Der daraus resultierende Nachteil ist der zusätzliche Speicheraufwand für den G-buffer. Daher existieren Ansätze, wie Deferred Lighting, die nur einen sehr kleinen G-buffer benötigen. Nichtsdestotrotz ist heutige Hardware in der Lage diesen Speicheraufwand zu kompenxieren, weshalb Deferred Rendering mittlerweile von den meisten Engines genutzt wird.

Deferred Rendering hat aber auch andere Nachteile, wie eben z.B. die Probleme mit Transparenz und Multisampling. Wenn man nicht wirklich viele dynamische Lichtquellen simulieren will, dann ist Forward Rendering jedenfalls imo klar im Vorteil, weil es simpel ist und ohne Hacks und Sonderfälle auskommt...

Deferred Rendering hat noch weitere Nachteile, beispielsweise bindet man sich an ein Beleuchtungsmodell... Trotzdem wird viel Energie investiert um Problemfaktoren von Deferred Rendering entgegenzuwirken und Lösungen zu finden, da viele Spiele tendenziell eher auf schöne dynamische Beleuchtung setzen, statt gebackene Lichtinformationen. Klar das in einigen Fällen Deferred Rendering kein Sinn macht. Hardware die stark Speichergebunden ist scheidet aus und wenn nur eine handvoll Lichter notwendig sind vereinfacht man sich das Leben mit Forward-Rendering vermutlich eher.

Forward Rendering ist für den Anfang ne schöne Sache. Man addiert halt einfach Lichteinflüsse auf und muss halt jedes Objekt so oft rendern, wie die Anzahl Lichtquellen es erfordert. Es gibt von da aus auch viele einfache Optimierungsmöglichkeiten, die die Performance für viele Lichter verbessern. Ich denke, es ist lehrreich, mal einen Forward Renderer geschrieben zu haben.

Wenn man den Weg aber weiter geht und so nach und nach ein Spiel baut, landet man heutzutage mehr oder minder automatisch bei einem Deferred Renderer. Die Vorteile sind einfach enorm, speziell auf dem PC, wo es praktisch immer an der CPU hängt und die GPU eh Reserven hat. Das mag auf den Konsolen noch anders aussehen, aber da muss man halt bedenken, dass die Hardware von 2005 benutzen. Und selbst auf Konsolen nutzt die gängigste Engine (Unreal 3) einen Deferred Renderer.

Ich werde auch die Splitterwelten mal auf einen Deferred Renderer umbauen. Das Terrain, bei dem verschiedene Materialien mit Alpha Blending gemischt werden, ist ein Performance-Killer, weil jedes Material alle Lichtquellen und deren Schatten erneut berechnen muss. Mit einem Deferred Renderer könnte ich da einfach die Materialeigenschaften alpha-blenden und mache die ganze Licht-Technik nur noch im Screen Space. Das Gleiche gilt im gewissen Maße auch für den Bodenbewuchs - speziell das Getreide ist durch seinen massiven Overdraw tödlich für die GPU. Man kann dort einiges sparen, obwohl ein Deferred Renderer einen größeren Basis-Resourceneinsatz hat. Und dazu kommt noch, dass die Renderjobs einheitlicher werden, wenn man die komplette Beleuchtung aus der Rechnung rausnehmen kann. Das spart ne Menge Shader- und Texturwechsel auf der CPU und ermöglicht auch neue Optimierungen wie z.b. automatisches Instancing, die bei den ständig wechselnden Lichtparametern eines Forward Renderers kaum was bewirken.

Für die schon genannten teiltransparenten Modelle ist es aber trotzdem nützlich, noch einen Forward Renderer dazuhaben. Die beiden Ansätze schließen einander ja nicht aus.

Zitat

Der wesentliche Vorteil von Deferred Shading ist imo, dass die Geometrie nur einmal transformiert werden muss

Man kann ja auch Singlepass Lightning machen. Bei entrollen der Schleife im Shader, gibt es wirklich keinen Nachteil zum Multipass.
Das mehrfachberechnen entfällt dann auch.

Zitat

Forward-Rendering hat eine Komplexität von O(nm)

Theoretisch schon.
Aber gerade mit sowas wie EarlyZ entfällt dieser Punkt restlos! (Vorausgestzt man rendert grob sortiert von vorne nach hinten)
Es werden nämlich ebenfalls nur die Polygone gezeichnet, die nacher auch an den Bildschirm kommen.



Aber ich geb euch natürlich insofern recht, als das Deferred Shading durchaus auch zahlreiche Vorteile bietet.
Aber für den Ottonormal Programmierer und so zimliche alle hier die keine Engine benutzten ist die Frage nach deferred Shading eher akademischer Herkunft.
FSA ist damit jedenfalls sicher auch nicht geholfen...