Schatten - wie wirds gemacht?

[Buzzler]

Mich würde mal interessieren, wie Schatten in Spielen gerendert werden. Das mit den Shadow Maps (http://en.wikipedia.org/wiki/Shadow_mapping) hab ich soweit verstanden. Das ist der ressourcenschonende Weg, um Echtzeitschatten zu erzeugen, ja? Funktioniert das analog mit mehreren Lichtquellen?

Was wird bei aufwendigeren Schatten benutzt? Shadow Volume (http://en.wikipedia.org/wiki/Shadow_volume)?

Was ist bei Spielen mit statischer/dynamischer Beleuchtung gemeint?

[Gast]

Mich würde mal interessieren, wie Schatten in Spielen gerendert werden. Das mit den Shadow Maps (http://en.wikipedia.org/wiki/Shadow_mapping) hab ich soweit verstanden. Das ist der ressourcenschonende Weg, um Echtzeitschatten zu erzeugen, ja? Funktioniert das analog mit mehreren Lichtquellen?

Was wird bei aufwendigeren Schatten benutzt? Shadow Volume (http://en.wikipedia.org/wiki/Shadow_volume)?

Was ist bei Spielen mit statischer/dynamischer Beleuchtung gemeint?
in aktuellen spielen wirst du fast ausschließlich shadow mapping finden.
shadow volumes sollten vor allem aus doom3-engine spielen (doom3, prey, quake4, et:qw) bekannt sein. darum haben alle models dort vergleichsweise wenig polygone, sonst wär die erzeugung der shadow volumes dafür einfach zu rechenaufwendig.

statische beleuchtung bezeichnet einfach eine situation in der die lichtquellen und beleuchteten objekte feste positionen haben. in diesem fall kann licht/schatten im voraus berechnet werden und muss dann beim eigentlichen rendern nur noch dargestellt werden. ein einfaches beispiel wär die level-beleuchtung bei spielen auf der quake3-engine: dort wird die beleuchtung beim kompilieren der map berechnet und von der engine dann einfach als zusätzliche graustufentextur über die umgebung gelegt.

[Buzzler]

Danke erstmal!

Nochmal zum Verständnis: Die Unterschiede beim Ressourcenhunger der Schatten-Berechnung (shadow volumes ausgenommen) ergeben sich dann daraus, wieviele Lichtquellen es gibt, wieviele/welche Objekte Schatten werfen sollen, mit welcher Auflösung die Schatten berechnet werden und wieviel Aufwand getrieben wird, die Schatten am Ende weicher/realistischer zu bekommen?

Shadow Maps nehmen zumindest pro Lichtquelle nur zwei Werte an, oder? Im Zusammenspiel mehrerer (ggfs. unterschiedlich heller) Lichtquellen können sich dann aber grundsätzlich auch fein abgestufte Schatten ergeben?

Achso, muss jetzt "nur" eine Shadow Map pro Lichtquelle berechnet werden oder eine pro Lichtquelle und Objekt?

[Coda]

Eine pro Lichtquelle. Die Shadowmap enthält die Entfernung von der Lichtquelle.

[Spasstiger]

Ich werfe mal noch Ambient Occlusion (http://en.wikipedia.org/wiki/Ambient_occlusion) als Stichwort ein (alternativer, deutscher Artikel: klick (http://de.wikipedia.org/wiki/Umgebungsverdeckung)). Wird z.B. beim Spiel "Kane & Lynch" eingesetzt und sorgt dafür, dass diffuse Reflexionen des Lichtes näherungsweise berücksichtigt werden.

[LIVI@HOME]

Schattenberechnung in Open-GL

http://wiki.delphigl.com/index.php/Volumetrische_Stencilschatten

übrigens sehr gute seite für Leute die selber ein bisschen in die Materie einsteigen wollen, nicht nur wissen wie es geht...

[del_4901]

Eine pro Lichtquelle. Die Shadowmap enthält die Entfernung von der Lichtquelle.
Das sind spezielld die Depth Map Shadow Algorithmen (PCF, VSM, und das komische neue da, mein ShaderX6 ist leider nicht zur Hand)
Ich wusse auch nicht das es noch andere (In meinen Augen Komplizierte) Variante wo Occluder/Reciever extra berechnet werden und daraus dann geschlossen wird, wo Schatten liegt.

Ähm PS: Ihr wisst aber schon, das Shadow Volumes Tot sind. (zumindestens Halbtot)

[ScottManDeath]

Es gibt noch Cascaded Shadow Maps in denen es pro depth range eine eigene Shadow map gibt um das Aliasing zu verringern. Crysis macht dies auch.

http://delivery.acm.org/10.1145/1290000/1281671/p97-mittring.pdf?key1=1281671&key2=8230230911&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=6184618

[SavageX]

Ähm PS: Ihr wisst aber schon, das Shadow Volumes Tot sind. (zumindestens Halbtot)

Nun, für *harte* Schatten gibts ja kaum was besseres ("perfekte" Präzision - und spart auch noch Shaderleistung in beschatteten Bereichen). Sobald es es "weich" werden soll taugt das ganze natürlich nicht. Je nachdem, welche Ästhetik man haben will, können Stencilschatten einem exakt das geben, was man haben will - oder eben exakt das Gegenteil.

[Aquaschaf]

Nun, für *harte* Schatten gibts ja kaum was besseres.

Höchstens wenn man gleichzeitig nicht besonders viele Polygone hat.

[SgtTynis]

Höchstens wenn man gleichzeitig nicht besonders viele Polygone hat.

Kann man nicht für die Schattenberechung auf ein weniger detailreiches 3D Modell des beschatteten Objekts zurückgreifen? Id Tech 4 machts ja nicht so, was sich in den doch auffällig niedrig-polygoniegen 3D Modellen zeigt.

[SavageX]

Höchstens wenn man gleichzeitig nicht besonders viele Polygone hat.

Das stimmt wohl. Aber kann man jetzt nicht auf den neueren Karten die Schattenvolumengenerierung, die üblicherweise mehr oder weniger komplett auf der CPU abläuft, effizient per Geometry Shader erledigen?

[Coda]

Kann man nicht für die Schattenberechung auf ein weniger detailreiches 3D Modell des beschatteten Objekts zurückgreifen?
Dann ist Self-Shadowing fucked up und es sieht imho komisch aus.

Das stimmt wohl. Aber kann man jetzt nicht auf den neueren Karten die Schattenvolumengenerierung, die üblicherweise mehr oder weniger komplett auf der CPU abläuft, effizient per Geometry Shader erledigen?
Shadow Volumes sind nicht nur deshalb tot.

[Aquaschaf]

Kann man nicht für die Schattenberechung auf ein weniger detailreiches 3D Modell des beschatteten Objekts zurückgreifen?

Dann hast du Schatten die nicht mehr richtig zum Objekt passen, je nachdem kann es natürlich noch korrekt genug aussehen. Sonst spricht gegen shadow volumes z.B. noch dass sie ja nur die Geometrie sehen, d.h. Oberflächen die alpha test benutzen funktionieren damit nicht. Weiterhin muss die Geometrie dafür auch geschlossen sein; ein Objekt aus mehreren zusammengesteckten Teilen bauen die (dann am Ende nicht sichtbare) Löcher haben geht nicht.

[Gast]

was ist denn mit sowas wie "radiosity"?

was braucht es dafür (zb welche HW)
durch welche HW könnte dies alles gelöst werden und werden wir das irgendwann mal sehen? evtl. wie lange?
bzw. gibt es alternativen die in naher zukunft ähnliche qualität bringen?

das thema interessiert mich schon sehr, weils im prinzip ein enormer fakto für realistische darstellung ist. bzw. der wichtigste punkt neen auflösung und bildtiefe

[Gast]

Wie macht Crysis das denn in Wald und Wiesen?

Die Engine soll ja angeblich auch Dynamic Ambient Occlusion können, das soll aber wohl deaktiviert worden sein, da die GPU Leistung noch zu jämmerlich ist. :)

[Spasstiger]

was ist denn mit sowas wie "radiosity"?

was braucht es dafür (zb welche HW)
durch welche HW könnte dies alles gelöst werden und werden wir das irgendwann mal sehen? evtl. wie lange?
bzw. gibt es alternativen die in naher zukunft ähnliche qualität bringen?

das thema interessiert mich schon sehr, weils im prinzip ein enormer fakto für realistische darstellung ist. bzw. der wichtigste punkt neen auflösung und bildtiefe
Radiosity gibts bisher in Spielen nur vorberechnet, ein Raytracer berechnet dabei die Beleuchtung. Eine Vorstufe hin zu Echtzeit-Radiosity wäre das oben von mir erwähnte Ambient Occlusion.
Falls du Echtzeit-Radiosity mal live erleben willst:
- http://homepages.paradise.net.nz/nickamy/realtimerad/realtimerad.html
- http://dee.cz/rrb/
- http://lightsprint.com/demo.html

http://dee.cz/rrb/rrbugs_hint.jpg

Ich denke, allzulange kann es nicht dauern, bis wir solches Rendering auch in Spielen sehen.

[SavageX]

Weiterhin muss die Geometrie dafür auch geschlossen sein; ein Objekt aus mehreren zusammengesteckten Teilen bauen die (dann am Ende nicht sichtbare) Löcher haben geht nicht.

Jein. Man kann auch für nicht-geschlossene Faces ein "korrektes" Volumen berechnen (wird in Nexuiz auch gemacht).

Wenn man sich aber auf geschlossene Meshes beschränkt, dann kommt man oft damit weg, das Mesh nochmal in die Szene zu stellen, alle dem Licht "abgewandten" Vertices gaaaaanz weit "nach hinten" zu schieben - und schon hat man sein Billigschattenvolumen.

[SavageX]

Shadow Volumes sind nicht nur deshalb tot.

Schattenvolumen sind billig und recht robust, wenn auch altmodisch. Ich denke, man wird sie noch öfters hier und da noch zu Gesicht bekommen.

[del_4901]

Nun, für *harte* Schatten gibts ja kaum was besseres ("perfekte" Präzision - und spart auch noch Shaderleistung in beschatteten Bereichen). Sobald es es "weich" werden soll taugt das ganze natürlich nicht. Je nachdem, welche Ästhetik man haben will, können Stencilschatten einem exakt das geben, was man haben will - oder eben exakt das Gegenteil.
Naja das halte ich aber für ein Gerücht das hier Shaderleistung gespaart wird. SV eats Fillrate like Hell! Und da ich auch noch jedes Licht in einem extra pass machen MUSS zweifel ich das doch stark an. Zumal dabei jedesmal der transformationsteil laufen muss und ich meine Szene zum aber millionsten mal durch die Pipe quetsche.
Schattenvolumen sind billig und recht robust, wenn auch altmodisch. Ich denke, man wird sie noch öfters hier und da noch zu Gesicht bekommen.
Das mit dem billig ist auch totaler ranz. (siehe oben) SV sind total GPU "unfreundlich". Und robust ... naja man muss trotzdem ständig zwischen reverse und normal umherschalten, das kann ich mir bei SM spaaren.

[del_4901]

Wo ich persöhnlich SVs eingesetzt habe, war im Weltraum. da kann man das machen, und aufgrund der geringen Objektdichte lohnt sich das sogar. (nur heutzutage spielt keiner mehr solche Spiele)

[Gast]

Wird z.B. beim Spiel "Kane & Lynch" eingesetzt und sorgt dafür, dass diffuse Reflexionen des Lichtes näherungsweise berücksichtigt werden.
Naja sie sind eigentlich nur ein Helligikeitsfaktor, der vom Prozentsatz der in der direkten Umgebung freien Hemisphere bestimmt wird.
Von diffusen Reflektionen könnte man zwar eigentlich den Helligkeitswert mit einfließen lassen, wird aber in der Regel nicht gemacht.
Allein den Helligkeitsfaktor zu berücksichtigen ist schon eine der gröbsten Näherungen, die möglich sind.

[SavageX]

Naja das halte ich aber für ein Gerücht das hier Shaderleistung gespaart wird. SV eats Fillrate like Hell! Und da ich auch noch jedes Licht in einem extra pass machen MUSS zweifel ich das doch stark an. Zumal dabei jedesmal der transformationsteil laufen muss und ich meine Szene zum aber millionsten mal durch die Pipe quetsche.

Ja selbstverständlich sparst Du Shaderleistung im Schatten. Rate mal, was Du im abgeschatteten Teil *nicht* ausführst...

Dass stattdessen Füllrate draufgeht, ist klar. Und wie viele Lichter willst Du eigentlich auf die Szene loslassen - und inwiefern sind Shadowmaps da auch nur einen Tick sparsamer?

(Und wie oft stößt man heutzutage tatsächlich auf ein Limit beim Geometriedurchsatz?)



Das mit dem billig ist auch totaler ranz. (siehe oben) SV sind total GPU "unfreundlich". Und robuiust ... naja man muss trotzdem ständig zwischen reverse und normal umherschalten, das kann ich mir bei SM spaaren.

"Carmack's Reverse" implementierst Du einmal und gut ist.

Shadowmaps sind nicht billig, wenn man es mit einem Mindestmaß an Qualität machen will. Man handelt sich die typischen Abtastprobleme ein und muss einen Kompromiss bei der Auflösung schließen - und dann lese ich doch dauernd irgendwas davon, dass man dann auch noch aufwendig samplen/filtern muss, um das ganze ansehnlich zu bekommen.

Also ganz so klar finde ich das ganze nicht.

[Spasstiger]

Schaut mal, was die Shadowmaps bei Half-Life 2 Episode 2 fressen. Während HL2 noch deutlich genügsamer als Doom 3 war, ist Episode 2 ein richtiger GPU-Fresser geworden und bringte insbesondere GeForce-7-Karten schwer ins Schwitzen, wenn man mal die Taschenlampe anwirft. Auf andere schattenwerfende, dynamische Lichtquellen hat Valve bewusst verzichtet. Bei 4-5 dynamischen Lichtern, die allesamt dynamische Schatten werfen, ist nämlich mit heutiger Hardware Schicht im Schacht (kann man leicht in Garry's Mod oder mit dem SDK nachprüfen).

[del_4901]

Ja selbstverständlich sparst Du Shaderleistung im Schatten. Rate mal, was Du im abgeschatteten Teil *nicht* ausführst...
Dafür kann ich dann auch branching nutzen, das ist mindestens genauso schnell.


Dass stattdessen Füllrate draufgeht, ist klar. Und wie viele Lichter willst Du eigentlich auf die Szene loslassen - und inwiefern sind Shadowmaps da auch nur einen Tick sparsamer?

Lichter ändern sich nicht so häufig wie die Kamera. Und solange sich das Licht nicht ändert, kann ich meine SM behalten.


(Und wie oft stößt man heutzutage tatsächlich auf ein Limit beim Geometriedurchsatz?)

Wenn man's richtig machen will muss man das eh alles vernünftig cappen, und da macht ganz schnell die cpu schlapp. Mental Images hat da zwar einen GS Shader für, aber ich da nicht wirklich so überzeugt von. Der ist nämlich auch ein ganz schöner Klopper.



"Carmack's Reverse" implementierst Du einmal und gut ist.

Solange man eine NV_CLAMP_FAR extension nutzen kann ist die Welt noch halbwegs in Ordnung. (Btw: Unendlich Projektion finde ich persöhnlich nicht die Lösung aller Probleme).
Deswegen wechselt man ja auch normalerweise nur zu "Carmack's Reverse" wenn es absolut notwendig wird.


Shadowmaps sind nicht billig, wenn man es mit einem Mindestmaß an Qualität machen will. Man handelt sich die typischen Abtastprobleme ein und muss einen Kompromiss bei der Auflösung schließen - und dann lese ich doch dauernd irgendwas davon, dass man dann auch noch aufwendig samplen/filtern muss, um das ganze ansehnlich zu bekommen.

Wiso, ich bin mit VSM und deren Erweiterungen (im X6 gibs sogar was, was drauf aufbaut und kein light-bleeding mehr hat) recht zufrieden.
512er SMs sind schon Luxus. Das SAT Sampling kostet zwar 3 Passes, die dafür aber sehr GPU freundlich sind, und "null" CPU Leistung kosten. (zumal ich das nicht häufig machen muss)
Die Schatten sind dann aber schön soft.
Man kann sogar AA beim generieren nutzen und noch AF drauf ballern.
Die Abtastprobleme sind dann eigentlich Geschichte.

[del_4901]

Schaut mal, was die Shadowmaps bei Half-Life 2 Episode 2 fressen. Während HL2 noch deutlich genügsamer als Doom 3 war, ist Episode 2 ein richtiger GPU-Fresser geworden und bringte insbesondere GeForce-7-Karten schwer ins Schwitzen, wenn man mal die Taschenlampe anwirft. Auf andere schattenwerfende, dynamische Lichtquellen hat Valve bewusst verzichtet. Bei 4-5 dynamischen Lichtern, die allesamt dynamische Schatten werfen, ist nämlich mit heutiger Hardware Schicht im Schacht (kann man leicht in Garry's Mod oder mit dem SDK nachprüfen).
Wenn das alles schone Pointlights sind die umherfliegen, dann ist bei SM und SV leider Schicht im Schacht. Da kann man nur schnell mal auf "billig-SH-Lightning" umschalten, und hoffen das es keinem aufgefallen ist :uconf:

Außerdem ist es dann eh so hell, das man keinen Schatten mehr braucht. :P

[SavageX]

Dafür kann ich dann auch branching nutzen, das ist mindestens genauso schnell.


Jein. Ich würde branching verhindern wollen, wo immer möglich. Besser, als alles durchzukauen, ist es jedoch allemal.



Lichter ändern sich nicht so häufig wie die Kamera. Und solange sich das Licht nicht ändert, kann ich meine SM behalten.


Wenn sich das Licht nicht ändert, kann man auch das Schattenvolumen behalten.


Wenn man's richtig machen will muss man das eh alles vernünftig cappen, und da macht ganz schnell die cpu schlapp. Mental Images hat da zwar einen GS Shader für, aber ich da nicht wirklich so überzeugt von. Der ist nämlich auch ein ganz schöner Klopper.


Man müsste sich beim GS wirklich mal anschauen, was der kostet.



Wiso, ich bin mit VSM und deren Erweiterungen (im X6 gibs sogar was, was drauf aufbaut und kein light-bleeding mehr hat) recht zufrieden.
512er SMs sind schon Luxus. Das SAT Sampling kostet zwar 3 Passes, die dafür aber sehr GPU freundlich sind, und "null" CPU Leistung kosten. (zumal ich das nicht häufig machen muss)
Die Schatten sind dann aber schön soft.
Man kann sogar AA beim generieren nutzen und noch AF drauf ballern.
Die Abtastprobleme sind dann eigentlich Geschichte.

Gut zu hören, dass inszwischen die gröbsten Probleme gelöst sind.

[del_4901]

Wenn sich das Licht nicht ändert, kann man auch das Schattenvolumen behalten.

Aber nicht deinen Stencil-Buffer, das ist das traurige an der Geschichte.


Man müsste sich beim GS wirklich mal anschauen, was der kostet.

Man könnte sich das GS-Volumen vllt. über StreamOut merken. (GF8+)
Für mich lohnt es sich nicht diesen Testballon steigen zu lassen.

[Aquaschaf]

Lichter ändern sich nicht so häufig wie die Kamera. Und solange sich das Licht nicht ändert, kann ich meine SM behalten.

Aber auch nur wenn man keine Kamera-abhängige Projektion wie LiSPM oder PSM verwendet.

[del_4901]

Aber auch nur wenn man keine Kamera-abhängige Projektion wie LiSPM oder PSM verwendet.
Firlefanz, braucht man nicht :)

[Gast]

Bei 4-5 dynamischen Lichtern, die allesamt dynamische Schatten werfen, ist nämlich mit heutiger Hardware Schicht im Schacht (kann man leicht in Garry's Mod oder mit dem SDK nachprüfen).

bei der source-engine vielleicht, stalker oder auch diverse UE3-spiele haben damit kein großes problem.

[MadMax@]

Firlefanz, braucht man nicht :)

PSM liefert sehr anschprechende Ergebnisse wie ich finde darauf zu verzichten halte ich nicht unbedingt für sehr schlau.

[del_4901]

PSM liefert sehr anschprechende Ergebnisse wie ich finde darauf zu verzichten halte ich nicht unbedingt für sehr schlau.

http://developer.download.nvidia.com/SDK/10/opengl/src/cascaded_shadow_maps/doc/cascaded_shadow_maps.pdf finde ich persöhnlich besser

[Expandable]

Lichter ändern sich nicht so häufig wie die Kamera. Und solange sich das Licht nicht ändert, kann ich meine SM behalten.


Wie soll das performant gehen? Sagen wir bei sich nicht ändernden 4 Point-Lichtern in der Szene brauchst du 4 Cubemaps mit einer Auflösung von mind. 2048x2048, damit's einigermaßen gut aussieht. Selbst wenn du nur das R16-Format verwendest, hast du doch dann allein 200 MByte VRAM mit den Shadowmaps voll (huu? Das kommt mir grad sehr viel vor, hab mich eventuell beim Überschlagen vertan).

Da kann man Schattenvolumen wohl effizienter cachen.

[Aquaschaf]

Mindestens 2048² damit es einigermaßen gut aussieht? Das ist leicht übertrieben.

[del_4901]

Wie soll das performant gehen? Sagen wir bei sich nicht ändernden 4 Point-Lichtern in der Szene brauchst du 4 Cubemaps mit einer Auflösung von mind. 2048x2048, damit's einigermaßen gut aussieht. Selbst wenn du nur das R16-Format verwendest, hast du doch dann allein 200 MByte VRAM mit den Shadowmaps voll (huu? Das kommt mir grad sehr viel vor, hab mich eventuell beim Überschlagen vertan).

Da kann man Schattenvolumen wohl effizienter cachen.

Du hast die letzten Jahre einfach verschlafen, außerdem ist Oversampling ganz und gar nicht toll.

[Expandable]

Du hast die letzten Jahre einfach verschlafen, außerdem ist Oversampling ganz und gar nicht toll.

Dann lass dich doch bitte von deinem hohen Ross hinab und klär mich auf (Stichpunkte genügen): Welche Verfahren, wieviele Shadow Maps cachst du, in welcher Auflösung?

[SavageX]

Bei genauerer Überlegung fällt mir übrigens auf, dass ich gar nicht verstanden habe, wie man die Shadowmap von statischen Lichtern cachen kann. Bei jeder Veränderung der Szene wird doch eine neue fällig, nicht nur, wenn sich das Licht bewegt.

Kann man mich bitte in die richtige Richtung stupsen, ich bin gerade geistig blockiert.

[del_4901]

http://www.punkuser.net/vsm/

[Aquaschaf]

Bei genauerer Überlegung fällt mir übrigens auf, dass ich gar nicht verstanden habe, wie man die Shadowmap von statischen Lichtern cachen kann. Bei jeder Veränderung der Szene wird doch eine neue fällig, nicht nur, wenn sich das Licht bewegt.

Das geht natürlich nur wenn sich die Objekte in der Szene auch nicht bewegen.

[SavageX]

Das geht natürlich nur wenn sich die Objekte in der Szene auch nicht bewegen.

Dann sind aber Schattenvolumen etwas besser zu cachen. Da wird ja pro Objekt /Licht-Kombination entschieden, ob sich was getan hat.

(Andererseits gibt es bei n Lichtern und m Objekten natürlich n * m Volumen, während es bei den Shadowmaps ja nur auf die Anzahl der Lichter ankommt, wobei ich schon davon ausgehe, dass für fast jeden Frame praktisch alle Shadowmaps fällig sind.)

[del_4901]

Man kann auch dynamische und statische Objekte getrennt voneinander betrachten. Und für jede Art ne extra SM. Ist nur die Frage ob die gespaarte Leistung den Mehrverbrauch beim Speicher aufwiegt. Da muss man viel Feintuning betreiben.

[Buzzler]

das thema interessiert mich schon sehr, weils im prinzip ein enormer fakto für realistische darstellung ist. bzw. der wichtigste punkt neen auflösung und bildtiefe
Ack. Klar, Polycount und Texturenauflösung werden in Zukunft weiter steigen, das ist aber IMHO nichts mehr wovon einem die Kinnlade runterfällt. Es ist jetzt immer mehr die Summe der Details und wie "vernünftig" sie eingesetzt werden, letzteres braucht ja immer ein bisschen. Als BumpMapping aufkam, hatte ich teilweise den Eindruck, die Entwickler hätten das nur eingesetzt, um laut "Guck mal, unsere Engine kann BumpMapping!" zu schreien. ;)

Danke jedenfalls für die Links zu den WhitePapers - ein paar hab ich schon gelesen, ein paar hab ich noch vor mir. :) Da ich kaum in der Materie drin stecke, finde ich es schon interessant, dass es eigentlich kaum darum geht, neue bahnbrechende Techniken zu entwickeln, sondern eher darum, lange bekannte Sachen, so zu implementieren, dass man sie auf existierender Hardware auch in Echtzeit einsetzen kann.

Ambient Occlusion finde ich sehr interessant, einerseits weil es subjektiv sehr realistisch aussieht (auch wenn es physikalisch vielleicht nicht annähernd korrekt ist), bei dem Bildvergleich im WP zur CryEngine2 mit dem dunklen Tunnel mit den Rohren an Wänden ist der Effekt jedenfalls ziemlich gut. Andererseits sieht man da vermutlich das "echte" Potential von RayTracing, also dass es eben nicht den großen Schritt zum RayTracing gibt, der sämtliche Engines und Grafik-Hardware der vergangenen Jahre obsolet werden lässt (*), sondern dass es sich "klammheimlich einschleicht" und Spezialaufgaben übernimmt, die damit einfach besser aussehen...

* - Übrigens wundert es mich schon, dass Intel in der Öffentlichkeit so auftritt, als würden sie daran tatsächlich glauben.

[_DrillSarge]I[]

Man kann auch dynamische und statische Objekte getrennt voneinander betrachten. Und für jede Art ne extra SM. Ist nur die Frage ob die gespaarte Leistung den Mehrverbrauch beim Speicher aufwiegt. Da muss man viel Feintuning betreiben.
das sollte man nicht machen, da es wie "pre-doom3" aussieht. eine absolute gleichbehandlung jeglicher geometrie ist viel wichtiger als bspw. soft-shadows oder die möglichst hohe auflösung einer shadow-map.

afaik sind shadow maps bei großen schatten (sprich wenn man zB ein ganzes feld, was meinetwegen durch niedrigen sonnenstand hervorgerufen wird, in schatte tauchen will). entweder braucht man eine sehr hoch aufgelöste sm (verbraucht sinnlos leistung) oder eine gröbere (sieht auch mit filter mies aus).
bei sowas wären sc angebrachter.
wie siehts eigentlich mit alphatest/blend objekten und stencil-schatten aus?
kann man da jetzt (?) doch was machen? theoret. ja nicht

[Aquaschaf]

I[;6407572']das sollte man nicht machen, da es wie "pre-doom3" aussieht.

Die Schatten können trotzdem konsistent aussehen.

[_DrillSarge]I[]

Die Schatten können trotzdem konsistent aussehen.
wie das? andere behandlung (wie auch immer) ist für mich anderes aussehen, auch wenn man nochsoviel (am content?) trickst

[Aquaschaf]

I[;6407629']wie das? andere behandlung (wie auch immer) ist für mich anderes aussehen, auch wenn man nochsoviel (am content?) trickst

Wenn mit den Inhalten der shadow maps das gleiche angestellt wird und die Auflösung ungefähr gleich ist, dann sieht es auch gleich aus.

[del_4901]

I[;6407629']wie das? andere behandlung (wie auch immer) ist für mich anderes aussehen, auch wenn man nochsoviel (am content?) trickst
Die werden doch beide gleich behandelt, nur nicht gleich häufig.

[_DrillSarge]I[]

Die werden doch beide gleich behandelt, nur nicht gleich häufig.
und? (verstehs jetzt echt nicht)

[del_4901]

I[;6407642']und? (verstehs jetzt echt nicht)
Das da für dich überhaupt nichts Anders aussieht, das bekommt man nicht mit.

Wenn mit den Inhalten der shadow maps das gleiche angestellt wird und die Auflösung ungefähr gleich ist, dann sieht es auch gleich aus.
Ich würde das sogar vorraussetzen, wenn nicht explizit anders verlangt.

[_DrillSarge]I[]

Das da für dich überhaupt nichts Anders
ich glaub schon;) selbst in crysis seh ich "fehler" (oder vereinfachungen zugunsten der leistung) in den schatten *mir auf die schulter klopf" ;D. bspw. dass der figurenschatten sich nur nach einer (der stärksten/globale) lichtquelle richtet oder schatten nicht ganz korrekt auslaufen/brechen

€: schatten die man sieht (also nix weggeculltes) sollte man alle gleich behandeln/ "updaten", sonst wirkts komisch

€2: ich kapiers immer noch nicht richtig, willst du (man) die schatten einfach bspw. nur alle 5 frames aktualisieren?

[del_4901]

I[;6407660']ich glaub schon;) selbst in crysis seh ich "fehler" (oder vereinfachungen zugunsten der leistung) in den schatten *mir auf die schulter klopf" ;D. bspw. dass der figurenschatten sich nur nach einer (der stärksten/globale) lichtquelle richtet oder schatten nicht ganz korrekt auslaufen/brechen

€: schatten die man sieht (also nix weggeculltes) sollte man alle gleich behandeln/ "updaten", sonst wirkts komisch

€2: ich kapiers immer noch nicht richtig, willst du (man) die schatten einfach bspw. nur alle 5 frames aktualisieren?
Wenn sich an einer Stelle in der Szene nichts ändert, wiso, soll ich dann nicht meine ShadowMap, wiederverwenden dürfen? Ich weiß doch was ich in der Szene gemacht habe, und muss demzufolge nur die neuen Sachen nachberechnen.

[_DrillSarge]I[]

man hat doch immer neue "sachen", wenn man nicht gerade in einer komplett statischen umgebung absolut regungslos rumsteht, oder?

[del_4901]

I[;6407692']man hat doch immer neue "sachen", wenn man nicht gerade in einer komplett statischen umgebung absolut regungslos rumsteht, oder?
Die Kamera darf sich doch bewegen, da liegt der Denkfehler. Nur das Licht und/oder Geometrie nicht.

[_DrillSarge]I[]

Die Kamera darf sich doch bewegen, da liegt der Denkfehler. Nur das Licht und/oder Geometrie nicht.
okay, aber bleibt ja die einschränkung, dass sich dr level nicht ändern darf und dass ist bei aktuellen spielen ja oft gar nicht mehr der fall.
sowas war vielleicht vor paar jahren noch 100%ig zutreffend, aber es wird ja alles dynamisch

[del_4901]

I[;6407718']okay, aber bleibt ja die einschränkung, dass sich dr level nicht ändern darf und dass ist bei aktuellen spielen ja oft gar nicht mehr der fall.
sowas war vielleicht vor paar jahren noch 100%ig zutreffend, aber es wird ja alles dynamisch
Man benutzt ja nicht eine Shadowmap für die ganze Szene. Und auf die Frames gerechnet lohnt sich das schon.
Sozusagen, wenn Bedarf nach einer neuen neuen Shadowmap besteht, gibs die natürlich sofort.
Solange die Alte noch Gültigkeit besitzt, gibt es keinen Bedarf.

[_DrillSarge]I[]

aha, stellt natürlich auch einen (erheblichen?) "prüfaufwand" dar. siehe deinen post weiter oben.

[del_4901]

I[;6407764']aha, stellt natürlich auch einen (erheblichen?) "prüfaufwand" dar. siehe deinen post weiter oben.
Wiso, wenn sich was bewegt muss ich doch eh wissen wo sich das befindet, dann noch zu schauen welches Licht auf den Körper scheint, ist 1. eh notwendig und 2. nichtmehr wirklich so aufwändig. Dann habe ich doch alles was ich wissen muss.

[_DrillSarge]I[]

ergibt natürlich sinn. mann kann dann die sm aber ja nicht einfach verwerfen

[Coda]

Warum sollte man das nicht können?

[_DrillSarge]I[]

ich denk man brauch die dann später noch?