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

1

14.04.2013, 19:55

Speicheraufwand von Shadow-Maps (Deferred)

Guten Abend,

ich habe eine eher spezielle Frage zu dem Speicheraufwand von Shadow-Maps in einer "Deferred-Shading"-Umgebung. Dafür will ich kurz das Grundgerüst der Beleuchtungs-Pipe darlegen:

Quellcode

1
2
3
4
fill GBuffer (forward rendering)
for each light do
  render Shadow-Map (in case the light casts shadows)
  render light volume and lit


Dies hat den Vorteil, dass ich für jedes Licht die gleiche ShadowMap nutzen kann (sofern der Lichttyp es zulässt). Leider geht es gerade bei Point-Lights auf die Performance wenn die Shadow-Map immer dynamisch generiert wird. Deshalb möchte ich gerne den Lichtern eine Flag mitgeben, ob sie statische oder dynamische Shadow-Maps nutzen. Wenn sie statische nutzen, soll diese Shadow-Map on the fly beim erstmaligen Aufruf des Lichts gerendert werden. Das bedeutet aber natürlich, dass ich die Shadow-Maps vorrätig halten muss. Ich bin mir aktuell etwas unsicher in wie weit das skaliert. Ich ernte zwar einen enormen Performance-Gewinn (gerade bei Point-Lights), allerdings zu Kosten des Speicheraufwands. Habt ihr da Erfahrungen? Eventuell sind meine Befürchtungen auch vollkommen unbegründet.

Würde mich freuen, eure Meinung dazu zu hören.

Besten Dank, Mark

DeKugelschieber

Community-Fossil

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

2

14.04.2013, 22:47

In diesem Fall würde ich Performance vor Speicher setzen. Und der Aufwand sollte auch nicht so groß sein, Shadowmaps sind ja auch nur Texturen (wenn auch mit hoher Auflösung).

3

14.04.2013, 23:52

Naja, ungenutzter Speicher ist doch im Prinzip verschenkter Speicher. Speicher zu sparen, macht erst dann Sinn, wenn du ihn für etwas verwenden möchtest, dass wichtiger ist.
Im Vergleich zu den ganzen Texturen für deine Modelle, sollten die Shadow-Maps doch vermutlich recht wenig Speicher verbrauchen. Außerdem könntest du die auch in den RAM auslagern, insbesondere die, deren Lichtquelle gerade überhaupt nicht zu sehen ist. Du könntest dann ja mal durchmessen, ob das hochladen auf die GPU oder das komplette Neuberechnen langsamer ist (insbesondere, wenn man bedenkt, dass man die dann vermutlich nicht in jedem Frame hochladen muss).
Lieber dumm fragen, als dumm bleiben!

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

4

15.04.2013, 10:28

Meine Erfahrung:

a) Shadow Maps von Punktlichtern sind nicht groß. Wir haben normalerweise 256er CubeMaps vom Format R16F benutzt, also braucht ein Punktlicht 768k Speicher. Das ist heutzutage vernachlässigbar, da gehen hunderte ShadowMaps in den VRAM.

b) Du sparst aber auch nicht so viel. Nach meiner Erfahrung sind Shaderwechsel und vor allem der Wechsel des Rendertargets das Teure. Die paar Dutzend DrawCalls pro ShadowMap-Seite fallen dann kaum noch ins Gewicht. Es kann also gut sein, dass Dein "enormer Performance-Gewinn" in der Realität kaum messbar ist.

Ich habe bei b) jetzt mal vorausgesetzt, dass Du korrekt zwischen statischen und dynamischen Objekten unterscheidest. Du kannst ja nur Objekte in die statische ShadowMap aufnehmen, wenn folgende Bedingungen erfüllt sind:

a) Die Lichtquelle ist fest positioniert und hat eine feste Reichweite.
b) Das Objekt ist statisch in Position, Rotation und allen optisch relevanten Shader-Parametern.

Man hat üblicherweise aber nur ein paar wirklich statische Objekte (Terrain und Gebäude z.B.) und dazu ein paar dynamische Objekte (Wesen, im Wind schwingender Bewuchs). Also wäre der Ablauf mit gecachter ShadowMap:

1) initiale ShadowMap nur mit statischen Objekten ausrendern
und pro Frame:
2) das RenderTarget in die allgemeine ShadowMap setzen
3) den Inhalt der statischen ShadowMap rüberkopieren
4) dynamische Objekte reinrendern

und das sechsmal pro Lichtquelle. Hm. Mich würde in der Tat interessieren, ob Dir das wirklich was bringt.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

5

15.04.2013, 13:20

Vielen Dank für die Resonanz,

Ich selbst habe leider wenig Erfahrung und Wissen mit der heutigen Hardware, deshalb meine Frage dazu. Aus den Antworten kann ich aber rauslesen, dass der Speicheraufwand zu vernachlässigen ist.
Zu der Frage nach dem Performance-Gewinn:
Ich unterscheide natürlich zwischen dynamischen und statischen Objekten, die beide schön gesplittet in verschieden Queues liegen zum einfachen Culling. Deine Idee (Schrompf) führt ein bisschen darüber hinaus was ich mir vorgestellt habe. Da wie du schon sagst, die Scene 6mal pro Light zu rendern, sehr teuer ist bei vielen Punktlichtern, muss man wohl bei einigen Lichtern Abstriche machen und sie keine Shadows casten lassen. Bevor es aber soweit kommt, war meine Überlegung, dass ich komplett statische Shadow-Maps rendere (natürlich mit den genannten Einschränkungen), die wiederum auch nur statische Objekte in die Map baken. Dynamische Objekte würde ich dann erstmal komplett außen vor lassen. Die Shadows receiven könnten dann wiederum alle Objekte.

Nichtsdestotrotz habe ich bei meinen Überlegungen natürlich auch den Weg bedacht, nur die dynamischen Objekte wirklich neu zu rendern, da war ich mir aber ähnlich wie du unsicher, in wie weit mich das vorran bringt.

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

6

15.04.2013, 13:55

Nun, das stimmt. Wenn Du bei einigen Lichtquellen wirklich nur statische Objekte Schatten werfen lässt, kannst Du Dir alle Schritte außer dem initialen Ausrendern ersparen. Du bekämst damit eine Laterne vor der Taverne, bei der zwar Passanten keinen Schatten auf den Boden werfen, die kleine Mauer am Weg aber sehr wohl einen Schatten auf die Passanten. Wenn Du damit leben kannst, wäre das ein gangbarer Weg.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

LukasBanana

Alter Hase

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

7

15.04.2013, 19:15

Nur so am Rande: Bei VSMs (Variance Shadow Maps) ist der Speicheraufwand halt doppelt so groß. Dafür sind die aber sehr viel performanter als einfaches PCF (Percentage Closer Filtering).

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

8

15.04.2013, 20:22

Und ESM ist nochmal schneller bei gleichem Speicheraufwand wie normale ShadowMaps.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

9

17.04.2013, 22:30

Es sollte natürlich nicht der Default-Weg sein, wenn Lichter zu dutzenden allerdings für eine gewisse Atmosphäre platziert werden sollten, müsste man dort Abstriche machen. In wie weit dies Anwendung finden wird, wird sich zeigen da bin ich nur "Technologie-Lieferant" :).

Ja ich plane in die Richtung ESM (logarithmisch) ähnlich wie es Crytek auch macht, etwas zu basteln. Ich verwenden aktuelle für das Filtern der Schatten der Sonne (CSM) Poisson Disk Filtering. Das Filtern für die "normalen" Maps steht noch aus, wobei ESM aktuell mein Favorit ist, wobei ich mich noch nicht bis ins letzte Detail mit dem Konzept auseinander gesetzt habe.

Werbeanzeige