Moinsen,

auf die Hoffnung hin, den heiligen Gral der Schatten einmal zu finden schreib ich nochmal meine jetztigen Erfahrungen auf:
Es geht um die Schattenberechnung von Spotlichtern die sich bewegen (rotieren um die eigene Achse) und das sehr viele.. Ziel sind mehr als 500, auch bei rel. Komplexen Scenen. Die Beleuchtung wird mittels Deferred Shading mit MRT realisiert.

Meine Testumgebung:
Szene mit 500.000 Polygonen und verteilt auf rund 300 Modellen.
Graka: Geforce GTX 465

Durch diverse weitere Techniken, wie LightScattering, SSAO, SSGI, HDR, Particles, etc.. wird der GRAM schon ohne Lampen mit rund 600MB gefüllt.. (mehrere FBOs+Texturen in Bildschirmgröße)

Ohne Schatten rund 500 Lichter möglich.

Meine 1. Variante - Projezierte ShadowMaps:
Hier rendere ich bei jeder Bewegung einer Lampe dessen Schattenmap neu. Dazu verwende ich ebenfalls die Technik Frustum-Culling um nur Objekte zu rendern die sich im Lichtkegel befinden.

Vorteil: Recht ordentliche Schatten bei rel. kleiner Schattenmap (256x256).
Nachteil: Langsam..
Renderbare Lichter: max 30-50 bei >25fps

Meine 2. Variante - Dual Parabolide Shadowmaps
Hier rendere ich nur beim Ändern der Szene und beim verschieben der Lampe die Schatten in 2 Schattenmaps (front & rear).

Vorteil: Keine Änderung der Performance beim Rotieren der Lampe, daher bessere Performance
Nachteil: Schlechte Schattenqualität trotz großer Shadowmap (2048x2048). Fehlerhafte Schatten auf der Schnittebene der Maps. Sehr hoher Speicherverbrauch.

Renderbare Lichter (>25fps)
2x 2048x2048
max. 16 Lampen da Speicher voll..
2x 256x256 (sehr verpixelte Schatten)
max. 400 Lampen

Fazit: Beide Schattentechniken haben ihre Probleme... Die restlichen Techniken wie SSAO, SSGI etc. müssen nicht zwangsläufig in Echtzeit verfügbar sein. Dennoch ist der Speicherkonsum der DPSMs zu groß um soviele Lichter zu rendern..
Gibt es noch weitere Möglichkeiten die mir vielleicht weiterhelfen könnten?
Wie sieht es mit Stencil Schatten aus? Ich denke da irgendwie an eine Kombination aus Siluetten und DPSM?
Ich habe gehört das Stencil Schatten auf neueren Karten auch im Shader berechenbar sind?

Grüße
Thomas

Du könntest noch Cubemaps versuchen. Die müssten auch nur beim Verändern der schattenwerfenden Geometrie neu berechnet werden.
Außerdem könntest du versuchen die Shadowmaps zB nur jeden 2ten Frame oder nach einer bestimmten Zeit neu zu berechnen. Allerdings müssten dann alle Shadowmaps in den Speicher passen.
Oder du verwendest nur eine Shadowmap und fügst immer nur ein Licht zur Szene hinzu, bevor du die Shadowmap mit den Daten für das nächste Licht füllst. Das eliminiert das Speicherproblem. Nachteilig wirken sich aber sicherlich die FBO-Wechsel auf die Performance aus.

Vllt gibt es auch noch eine Möglichkeit herauszufinden welche Schatten für die aktuelle Szene kaum von Bedeutung sind. Dann könnte man denen eventuell eine Textur mit stark reduzierter Auflösung zuweisen.
Außerdem solltest du vllt alle Texturen, die nicht für Berechnungen gebraucht werden, komprimieren, falls du das nicht schon gemacht hast.

Stencilschatten sind bei so vielen Lichtern vllt nicht so gut. Die dürften extrem an der Füllrate zehren und viel Spielraum für Optimierungen hat man da nicht.

nun das Speicherproblem lösen indem ich nur in eine Map rendere macht ja wenig sinn, denn dann muss ihc ja wie bei den projezierten Maps jedes Frame (oder 2.) die schatten rendern.. Sinn ist es ja die Schatten vorzurechnen um dann bei einer Rotation der Lampe trozdem den korrekten schatten zu haben. Das funktioniert auch wunderbar.. doch wie gesagt zu speicherintensiv..
Ich werd erstmal Versuchen alles andere ein wenig zu verkleinern.. Wie meinst du das mit Texturen komprimieren? Die größten Speicherfresser (~300MB) sind meine FBO Texturen.. wie könnt ich die denn komprimieren? Bei vielen Texturen brauch ich z.b. den Alpha Kanal nicht.. krieg ich den irgendwie raus?

Stencil:
Nun ich meinte nicht die allte bekannte technik ein "Mesh" zu bauchen.. sondern eher irgendwie die Siluette in eine Textur zu speichern um dies dann "irgendwie" wieder zu verwenden.. z.b. ob ein Fragment innerhalb dieser Siluette ist..



Grüße,
Thomas

Eine weitere Koriosität ist ja, dass wenn mein Speicher Voll ist (GRAM) dann werden überhaupt keine Schatten mehr berechnet.. Alles dunkel.. Ich dachte immer wenn Speichervoll, das die Graka das dann in den Arbeitsspeicher auslagert?
Meine Karte hat 1024MB dedizierten Speicher aber insg. verfügbar 4095MB.. Wenn ich allerdings pro Lampe eine 2048x2048 Schattentextur habe ist bei 16 Lampen irgendwie schluss..

Najo, fragst du OpenGL fehler ab? Bei mir setzt er nach glTexImage2D den Fehler auf Out of memory, wenn kein Speicher mehr da ist (was bei mir schon bei 2 Texturen mit 2048x2048 RGBA_FLOAT32 passiert )

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Wobei man ja beim Color_Attachment vom FBO den RGB Wert ja auch auf GL_RGB4 setzen kann - der Depth Wert ist ja entscheident... oder gehts noch geringer? ^^

Wie wär's mit Color Attachment weglassen? Oder halt nur als Renderbuffer, den man wiederverwendet.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also wenn ich bei meinem FBO das Color_Attachment weglasse und nur den Depthpart benutze läuft das Shadow Mapping nicht mehr wirklich rund

Er hat offensichtlich kein Problem mit den Vokabeln sondern mit dem Ausdruck und da bräuchten wir eher Informationen zum Aufbau
des Programms und der Szene. Im Moment muss ich vom "worst case" ausgehen und dort gibt es leider nur eine Antwort: vergiss es, Rechner sind
zu schwach für sowas!

_________________
Meine Homepage

Wenn ich auch nochmal was zur Schattenberechnung fragen darf:
In der Regel (zumindest so wie ich es kenne) geht man ja zur Sicht des Lichtes und guckt zu einem Punkt, dann Depth Textures erstellen etc.
Wie macht man es aber wenn das Licht nicht in eine bestimmte Richtung leuchten soll sondern quasi in alle?!

Rendern in eine Cubemap?

Mit dem Komprimieren meinte ich das man für die Texturen als Format zB GL_COMPRESSED_RGB verwendet. Das geht aber nur für die, die sich nicht verändern. Also nur ganz "normale" Texturen wie man sie von der Festplatte liest.
Benutzt du für deine Deferred Shading Texturen 32Bit Float Formate? Mir ist das eingefallen, weil Lord Horazont das erwähnt hatte. Für sowas sind Halffloats denke ich auch ausreichend und man spart die Hälfte an Speicher.

Deine Idee mit der Silhouette in der Textur ist vllt garnicht schlecht. Obwohl das nicht mehr viel mit Stencilschatten zu tun hat. Ich stell mir das so vor das man das ähnlich wie ein Raytracer macht. Man liest aus einem TBO oder einer Textur die Punkte der Dreiecke und berechnet ob sie die Strecke vom Pixel zum Licht schneiden. Um das ganze zu beschleunigen könnte man in einer niedrigauflösenden Textur speichern welche Dreiecke ungefähr in dem Bereich liegen der relevant ist. Also man hat eine Textur ähnlich einer Shadowmap, bloß das in jedem Texel keine Tiefe steht, sondern eine Liste von Indizes, die auf die Dreiecke zeigt, die den Texel schneiden.

genau so hab ich mir das vorgestellt .. aber ich denke das die Prüfung ob ein Fragment innerhalb eines belibigen Polygons ist, dürfte nicht allzuschnell sein.. Bzw weiß ich grad noch nich wie ich das machen könnte.. Ich hab die FBOs mal mit GL_RGB4 erstellst anstelle von 8.. hat sich am speicherverbrauch alerdings nix geändert?

Nochmal zu meinen Szenen etc.. Also es werden Bühnen für die Beleuchtungstechnik gerendert. Also rel viel Trussing, Menschen, etc.. Die Szenen sind zwar alle auf Polygonarmheit optimiert aber trozdem kommen da schonmal 250.000 zusammen. Ansonsten hab ich techniken wie FrustumCulling schon drin, allerdings machts wenig sinn, da meistens die Ganze Bühne sichtbar ist..

Allerdings brauch ich all diese Texturen die von FBOs vollgerendert werden.. hab schon schon rel. gut optimiert und machne wieder verwendet.. komme trozdem auf über 15 Texturen in Bildschirmauflösung.

Fehlerabfragen hab ich.. ich hab auch noch einen "ungültigen enumerationswert".. hab allerdings noch nicht gefunden wann und wo der auftritt..

Dein Problem
Du hast einen Bereich A in dem sich das Licht befindet und einen Bereich B den du ausleuchten willst. Wobei der Bereich A sich ,mit
hoher Wahrscheinlichtkeit, mit den Objekten in B nicht schneiden wird.

Lösungsvorschlag:
Wenn A weiß wie B aussieht, dann wissen auch alle Objekte in A wie die Objekte in B aussehen, Da dies auch Umgekehrt gilt, dürfte die
Anzahl der Objekte in A&B egal sein. Guckst du hier.

Fazit:
Performance gewinnt man am besten durch Spezialisierung

_________________
Meine Homepage

ehrlich gesagt weiß ich nicht was du meinst?! Die Beleuchtung wird mittels DFS gerendert, also komplette Szene einmal gerendert (natürlich nur Sichtbares > FrustumCulling).. Zu schattierende Objekte (bei normalen proj. Schatten) werden auch nur Objekte gerendert die sich im Lichtkegel befinden.. Bei DPSM Schatten MUSS ich alle Objekte in die Cubemap rendern, da die Lampe ja komplett rotieren kann, ohne das ich den Schatten neurendern muss..