Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

BlazeX

Alter Hase

  • »BlazeX« ist der Autor dieses Themas

Beiträge: 478

Wohnort: DD

Beruf: Maschinenbau-Student

  • Private Nachricht senden

1

28.01.2011, 22:59

Deferred Shading + Alpha => Alpha-To-Coverage nutzen?

Hi Leute!
Deferred Shading hat doch das Problem mit den Alpha-Transparenzen.
Wenn es nur um simple "Opak/Transparent"-Transparenz (Blätter, Gras) geht, könnte man doch Alpha-To-Coverage auf allen Render-Targets verwenden.
Multisampling wäre dann beim Scene-Rendering und beim Post-Shading Pflicht. Am Ende wird runtergesampelt, noch evtl. etwas Post-Processing und fertig.
Sollte doch funktionieren oder hab ich da einen Denkfehler?

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

2

29.01.2011, 00:29

Ja das geht natürlich (mit Direct3D 10 und aufwärts). Ein Nachteil ist sicherlich dass dabei der Speicherverbrauch und Bandbreitenbedarf die bei Deferred Shading ohnehin schon zu den Hauptproblemen zählen nochmal weiter nach oben getrieben werden...

BlazeX

Alter Hase

  • »BlazeX« ist der Autor dieses Themas

Beiträge: 478

Wohnort: DD

Beruf: Maschinenbau-Student

  • Private Nachricht senden

3

30.01.2011, 18:12

In welche Richtung entwickelt sich eigentlich das Deferred Shading: im kommen oder nur eine Modeerscheinung?
Ist die Hardware in naher Zukonuft bereit für DS oder sollte man doch eher beim Forward-Shading bleiben?

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

4

30.01.2011, 18:52

Ein Kommilitone schreibt seine Diplom-Arbeit unter anderem darüber und Forward-Shading ist definitiv langsamer als seine Umsetzungen von der Deferred Variante.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Beiträge: 721

Wohnort: /dev/null

Beruf: Software-Entwickler/Nerd

  • Private Nachricht senden

5

30.01.2011, 18:57

Plattformen sind nicht "in Zukunft" bereit für DS-Varianten, sondern jetzt schon. Viele AAA-Titel verwenden zum Beispiel Deferred Lighting, das dem Deferred Shading vom Prinzip her ähnelt. Halo Reach und Blur sind für den LPPR ein gutes Beispiel, für Standard DS die Stalker-Serie. Ich würde jedem einen LPP-Renderer empfehlen anstatt einen DS-Renderer. Beim LPP-Renderer hat man einfach bessere Möglichkeiten mehr Materialien und mehr Lichter darzustellen. Außerdem scaled LPPR wunderbar und ist im Prinzip sogar auf D3D8 Hardware möglich. Zu dem Thema findest du auf Wolfgang Engels Blog viel, er ist schließlich der "Erfinder".

Ansonsten könntest du dir nochmal den "Light Indexed Deferred Renderer" von Humus angucken.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

6

30.01.2011, 21:17

Deferred Shading ist momentan grad ganz groß in Mode. Es hat halt gewisse Vorteile, aber auch Nachteile. Vor allem was die Bandbreite und Speicherbedarf angeht kann man mit einem Light Prepass da was rausholen, das dürfte atm so ziemlich der State of the Art sein. Ich würde mal meinen mindestens 50%, vermutlich sogar 70% oder mehr, der aktuellen Spiele setzen auf Deferred Shading. Die Frage ist was die Zukunft bringt. Die Probleme mit Transparenz und Antialisaing sind eben für viele doch ein Dealbreaker und Deferred Shading kann seine Stärken jetzt auch nicht bei jeder Art von Szene ausspielen. Da atm mit Tesselation etc. alles hin zu mehr Geometrie geht wird es sicherlich zumindest für die nächsten paar Jährchen relevant bleiben.

BlazeX

Alter Hase

  • »BlazeX« ist der Autor dieses Themas

Beiträge: 478

Wohnort: DD

Beruf: Maschinenbau-Student

  • Private Nachricht senden

7

31.01.2011, 18:36

Danke, dann werde ich wahrscheinlich meinen Renderer neu implementieren müssen ;)
Hab ich das mit dem LPPR so richtig verstanden:
1. SceneGeometry rendern, dabei Depth und Normal speichern.
2. "Hüllen" der Lichter rendern (PointLight Kugel, SpotLight Cone, DirectionalLight FullscreenQuad), dabei in Die Lichtintensität des entsprechenden Pixels berechnen und speichern. Dabei alle LightSources additiv blenden.
3. Die gesamte SceneGeometry nochmal rendern, aber diesmal aus den MaterialEigenschaften und dem LightBuffer aus Pass 2 den finalen Pixels berechnen.

Das heißt doch, dass die gesamte Szenengeometrie doppelt gerastert wird. Das drückt doch, oder?
Oder einfach im 3. Pass den DepthBuffer des 1. Passes verwenden und per Depth EQUAL schreiben?

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

8

31.01.2011, 19:46

Bei (1) fehlen die Materials, bzw. ist (1) eigentlich ein normales Rendern, ohne Beleuchtung (Achtung! Nicht das gleiche wie rendern mit Beleuchtung ohne Lichtquellen!) und Normalen+Depth speichern.
Bei (3) dann das Ergebnis aus (1) verwenden und shaden.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

BlazeX

Alter Hase

  • »BlazeX« ist der Autor dieses Themas

Beiträge: 478

Wohnort: DD

Beruf: Maschinenbau-Student

  • Private Nachricht senden

9

01.02.2011, 19:26

Und anstatt bei 3. wieder Forward zu Rendern, kann ich hier Deferred Rendern.
Da fällt mir auf: Wenn ich für das ganze noch RelaxedConeStepMapping nutzen will, ist Deferred Rendering besser geeignet. Bei 1. Muss ich das TextureOffset pro Pixel berechnen, um an die Normale zu kommen und müsste bei ForwardRendering das Offset nochmal berechnen, um an die PixelFarbe zu kommen.

Also versuche ich demnächst mal DR in Kombination mit LPPR. Wenn ich brauchbare Ergebnisse habe, melde ich mich wieder.

Beiträge: 774

Beruf: Student

  • Private Nachricht senden

10

01.02.2011, 23:14

Die vielfältigen Probleme mit Antialiasing könnten sich die nächsten Jahre auch noch lösen - Stichwort Morphological AntiAliasing (MLAA) welches die Radeon 6000er Reihe bereits unterstützt. Allerdings ist die Qualität des Verfahrens recht umstritten nach dem was ich so gelesen hab.

Werbeanzeige