ZFX + Developia

Hi!

Ich arbeite mich gerade in Schattentechniken ein. Nach meiner aktuellen Recherche gibt es Shadowmapping und Stencilbuffer. Ich gebe zu, ein tiefes Verständnis habe ich noch nicht erlangt, das wird aber auch nicht so schnell geschehen.

Also bei der Stencilbuffer-Methode mit Shadowvolumes scheint man ja die für das Licht relevanten Kanten kennen zu müssen, um das Shadowvolume zu berechnen usw. Für bone-animierte Körper hätte ich dann aber das Problem, dass sich diese Kanten permanent ändern, richtig? Dann müsste ich die ja permanent aktualisieren. Ist das performant machbar oder gibt es geschicktere Techniken?

Tut mir Leid, dass ich frage, während ich noch nicht auf der Höhe meines Lernprozesses bin. Ich würde mich halt gerne hauptsächlich in die Technik erstmal einarbeiten, die mir am meisten dient.

Vielen Dank :)

Hrhrhr, ich erinnere mich noch an die Diskussion zu Assimp hier, wo jemand Software Vertex Processing bewarb, weil er damit Stencil Shadows machen kann. Beides ist ja mehr oder weniger tot :-) Der offizielle Name für Stencil Shadows heißt übrigens meines Wissens "Shadow Volumes", falls Du danach mal googeln willst.

Du hast Dir das richtig zusammengereimt. Bisher haben alle StencilShadow-Nutzer Vertex Processing dann auf der CPU gemacht. Mit DX10 und dem Geometry Shader kann man das jetzt aber auch komplett auf der GPU machen lassen. Der Geometry Shader kennt ja die Nachbarflächen und deren Vertices und kann daher die Kanten bestimmen, die extrudiert werden müssen. Es gibt nach meinem Wissen auch ein Beispiel im Direct3D-SDK, das genau das tut. Bleibt dann eigentlich nur noch das Problem, dass Shadow Volumes nach meinem Wissen nicht zuverlässig weich zu kriegen sind, sie nicht für AlphaTest-Oberflächen funktionieren und man eine Menge Fillrate für leere Luft investiert.

Der letzte Nutzer war meines Wissens übrigens Quake4, aber praktisch alle Engines da draußen dürften dafür noch Support eingebaut haben. Es nutzt nur keiner mehr. Und das rate ich auch Dir.

Verstehe. Jetzt ist es nur so, dass ich wieder Mal brav abwärtskompatibel bleiben möchte, da mein Spiel zwar Schatten haben sollte, aber viele Benutzer meines Wissens noch keine Geometry-Shader auf ihren Karten unterstützen (beispielsweise auch nicht mein alter Laptop mit einem Grafikchip). Geometry-Shader klingen super, sollte ich dann aber Shadow-Volumes für die alten Karten nutzen oder was wäre da die Alternative? Ich meine, jedes auch ältere Spiel hat Schatten für die animierten Objekte, wie war das dort denn gelöst?

Was ich auch überlegt hatte: wie wäre es einfach mit runden Shadowmaps für Objekte unabhängig ihrer eigentlichen Form? Ich habe nie so auf Schatten geachtet, aber werden da vielleicht einfach immer solche runden Schatten genutzt? Für Häuser, Terrain oder alles statische lassen sich ja Shadowmaps generieren (wobei man den Schatten vom Terrain einfach über die Farbe mit einbringt, richtig?) und für bewegte Objekte nehme ich dann einfach runde Schatten bei alter Hardware und Geometry-Shader bei neuer Hardware.

Was haltet ihr von dem Ansatz? :)

Edit:
Auch interessant ist das bei Zelda Ocarina of Time für N64 (wie gesagt, ich messe mich nicht so an High-End-Grafik)
http://www.youtube.com/watch?v=TuEazJNUnEo
Da scheint Link nur Schatten für seine Beine zu haben? Die strecken und recken sich aber auch anständig. Ich vermute, da steckt ein Shadow-Volume-Ansatz für die Beine dahinter. Bei Gegnern hängt es wohl auch davon ab, aber man hat ja selten mehr als 3-4 Gegner gleichzeitig (und bei mehr sackt eh immer die Performance ein, hehe).

Wie alt soll es denn noch werden? Nur zur Klarheit: Shadow Maps sind projezierte Texturen, in denen man den Abstand der Oberfläche vom Licht speichert. Man kann also beim Rendern der Szene dann anhand des Abstands zum Licht bestimmen, ob noch eine andere Oberfläche zwischen sich und dem Licht liegt oder nicht. Das ist eine sehr simple Technik, die seit DirectX8-Zeiten erfolgreich eingesetzt wird.

Es gibt zusätzlich aber noch eine richtig alte Technik namens Projected Shadows. Hier muss ganz genau getrennt werden, welche Teile Schatten werfen und welche Schatten empfangen. Beides zusammen von einer einzigen Lichtquelle geht nicht. Dann rendert man die schattenwerfenden Teile einfach schwarz auf weiß in eine Textur und projeziert diese Textur dann als Abdunklung auf die schattenempfangenden Teile der Szene. Der letzte große Nutzer dieser Methode war Half Life 2 und auch das von Dir verlinkte Zelda-Video sieht nach Projected Shadows aus.

Und da Du nach Meinungen gefragt hast:
Shadow Maps sind die einzig taugliche Methode aktuell. Shadow Volumes sind nicht weichzukriegen und kosten sehr viel Fillrate. Projected Shadows sehen nur bei sehr sehr sehr einfachen Szenen wie den drei Polygonen von Link auf der Wii gut aus, für alles andere sind sie einfach hässlich. Es führte auch vor fünf Jahren meiner Meinung nach praktisch kein Weg an Shadow Maps vorbei.

Okay, super, dann habe ich jetzt ja einen Plan. :) Vielen Dank!

Worauf mich eben noch ein Freund gebracht hat: weißt Du zufällig noch, wie man Tag/Nacht-Wechsel auf Terrains schattentechnisch löst? Wenn das weich wandern soll, kommt man um Geometry-Shader vermutlich nicht drum herum, oder? Oder gab es da auch mit älterer Hardware schon gute Möglichkeiten?

Eisflamme hat geschrieben:Worauf mich eben noch ein Freund gebracht hat: weißt Du zufällig noch, wie man Tag/Nacht-Wechsel auf Terrains schattentechnisch löst? Wenn das weich wandern soll, kommt man um Geometry-Shader vermutlich nicht drum herum, oder? Oder gab es da auch mit älterer Hardware schon gute Möglichkeiten?

Warum? Shadow Maps. Einfach nur Shadow Maps. Terrain ist auch nur ein Mesh. Oder viele Meshes. Oder wasweißich. Es ist scheißegal. Shadow Maps und fertig. Wenn Du Dich allerdings auf das Kindergarten-Niveau einer Wii herabbegeben willst, solltest Du evtl. das Terrain gar keine Schatten werfen lassen. Das spart ein bisschen Rechenzeit.

Die Splitterwelten machen ihren Tag/Nacht-Rhythmus auch mit Shadow Maps. Und bei uns scheint die Sonne manchmal auch von unten.

Auja, Schatten: Eins meiner Lieblingsthemen.

Also ich muss Schrompf 100% zustimmen. An ShadowMaps kommste nicht vorbei. Alles andere mag zwar auf den ersten Blick einfacher erscheinen bzw. „leichter“ zu implementieren sein, aber du handelst dir damit ne Menge „komische Programmlogik“ ein, die alles Mögliche steuern und sich merken muss und jede Menge Spezialfälle umschiffen muss. Außerdem machen ShadowMaps die CPU nicht so kaputt, wie Stencil Shadows. [Und die Bandbreite kannste ja auch mit Deferred Rendering verheizen. <-- Aber jetzt nicht thematisch zusammenwürfeln. War nurn Komentar ;-)]

Hab mich EWIG mit Schatten beschäftigt (so seit 2008) und muss sagen, dass ShadowMaps, wenn sie einmal laufen, relativ robust sind und recht viel Skalierungs-/Verbesserungspotential haben (je nach dem, wieviel Hardware du verheizen willst: filtern etc.). Wenn du die wichtigsten "Modi" implementiert hast, ist es dem SHADOWMAPPER EGAL, WIE die GEOMETRIE AUSSIEHT. Den interessieren EH NUR Pixel im Buffer; egal, wie du die da reinbekommst.

Ich spiele gerade übrigens Skyrim. Da sieht mans schön, dass alles Shadow Maps sind – auch die Sonne (mutmaßlich Cascaded Shadow Maps oder sowas). Um „Flackern“ und „wuselnde Filterprobleme“ zu vermeiden, schieben die die Sonne nicht kontinuierlich hin und her, sondern alle paar Sekunden ein sichtbares Stück weiter. Wirkt zwar im ersten Moment „komisch“, aber es dient meiner Meinung nach der Schattenstabilität.

Achso: ICh kenn übrigens kein Spiel (mir fällt zumindest kein ein!), wo das Terrain - also NICHT Bäume oder Felsen - sondern das Terrain SELBST Schatten wirft. Lighting ja, Shadowing nein... Jedemal das riesen Terrain-Mesh dadurch zu schicken halte ich nicht für soo sinnvoll: Du bekommst ne Menge Shadow Acne, hast Leistungsverlust und die Schatten wird u.U. keiner vermissen...

Beste Grüße

Shadowvolumes sind Pixelgenau

Ja, Shadow-Mapping für wanderndes Sonnenlicht bei einem Terrain hielt ich bzgl. Shadowmaps für sehr aufwendig, daher meine Frage, ob das dafür genutzt wird. Sprunghaft ok, aber weiche Übergänge permanent? Oder lässt sich da irgendwas interpolieren?

Aber wieso sind die Schatten bei Terrains so unwichtig? Ich finde, das sieht schon sehr gut aus, zumal bei einer statischen Sonne - wie ich sie vorhabe - ja eine simple Vorberechnung zu einer einzigen Shadowmap führt, was dann ja überhaupt kein Aufwand mehr ist. Wieso nicht?

Eisflamme hat geschrieben:Ja, Shadow-Mapping für wanderndes Sonnenlicht bei einem Terrain hielt ich bzgl. Shadowmaps für sehr aufwendig, daher meine Frage, ob das dafür genutzt wird. Sprunghaft ok, aber weiche Übergänge permanent? Oder lässt sich da irgendwas interpolieren?

Ich habe keine Idee, wie das gehen könnte ... nichtmal nen Ansatz.

Eisflamme hat geschrieben: Aber wieso sind die Schatten bei Terrains so unwichtig? Ich finde, das sieht schon sehr gut aus, zumal bei einer statischen Sonne - wie ich sie vorhabe - ja eine simple Vorberechnung zu einer einzigen Shadowmap führt, was dann ja überhaupt kein Aufwand mehr ist. Wieso nicht?

Ich denke, die Sonne bewegt sich? Siehe oben? Sonst kannste doch den Schatten für ne Statische Sonne in die Bodentextur mit einbacken. Oder seh ich das falsch? Dann kannste dir das komplette Shadowmapping sparen fürn Boden.

Eisflamme hat geschrieben:Ja, Shadow-Mapping für wanderndes Sonnenlicht bei einem Terrain hielt ich bzgl. Shadowmaps für sehr aufwendig, daher meine Frage, ob das dafür genutzt wird. Sprunghaft ok, aber weiche Übergänge permanent? Oder lässt sich da irgendwas interpolieren?

Außer zwischen den beiden "Sprüngen" zu interpolieren fällt mir dazu auch nichts ein. Das sähe immerhin noch besser aus als in Gothic3 wo man die Schatten wirklich springen sieht.

Eisflamme hat geschrieben: Aber wieso sind die Schatten bei Terrains so unwichtig? Ich finde, das sieht schon sehr gut aus, zumal bei einer statischen Sonne - wie ich sie vorhabe - ja eine simple Vorberechnung zu einer einzigen Shadowmap führt, was dann ja überhaupt kein Aufwand mehr ist. Wieso nicht?

Wenn du eh nur eine statische Sonne hast, würde ich dein Terrain auf jeden fall Schatten werfen lassen (precomputed). Allerdings finde ich, dass diese dann sehr weich sein sollten, damit man sie wirklich nur dort sieht wo es sinn macht. Unter einem Felsvorsprung z.B.

Andre hat geschrieben: Außer zwischen den beiden "Sprüngen" zu interpolieren fällt mir dazu auch nichts ein. Das sähe immerhin noch besser aus als in Gothic3 wo man die Schatten wirklich springen sieht.

Naja, das Problem ist ja nicht, die Position der Sonne sanft zu interpolieren bzw. vorsichtig weiterzuschieben,
sondern das durch das "ständige Geschiebe" die resultierenden "großen Schattenpixel auf dem Endbild" ja unter Umständen unschön rumwabbeln... Oder hab ich nun nen Denkfehler?

Andre hat geschrieben: Wenn du eh nur eine statische Sonne hast, würde ich dein Terrain auf jeden fall Schatten werfen lassen (precomputed). Allerdings finde ich, dass diese dann sehr weich sein sollten, damit man sie wirklich nur dort sieht wo es sinn macht. Unter einem Felsvorsprung z.B.

Ja, seh ich auch so. Das einzig "Unschöne ist, dass sobald ne figur Unter dem Stein steht, sie natürlich nicht schattiert wird. Wobei ein überstehende Stein bei mir nicht als Terrain gilt [--> Heightmapping], sondern ein eigenes Objekt wäre, was ja sowieso dynamischen Schatten wirft. Und beim eigentlich Heightmap/Quadtree-Basierten Terrain, wie es viele haben, macht das Schattenwerfen nicht IMMER Sinn. Da reichts meist statisch, wenn die Sonne statisch ist oder eben nur Lighting ohne Schatten.

Top-OR hat geschrieben:

Eisflamme hat geschrieben:Ja, Shadow-Mapping für wanderndes Sonnenlicht bei einem Terrain hielt ich bzgl. Shadowmaps für sehr aufwendig, daher meine Frage, ob das dafür genutzt wird. Sprunghaft ok, aber weiche Übergänge permanent? Oder lässt sich da irgendwas interpolieren?

Ich habe keine Idee, wie das gehen könnte ... nichtmal nen Ansatz.

Ich würde einfach das Terrain einmal orthogonal projiziert mit der Shadowmap ausrendern lassen, plus noch mal das gleiche bloß mit Sonnenstand +30sek oder so. Dann hat man zwei "Lightmaps" des Terrains, zwischen denen an dann in den 30sek interpolieren kann. Bestimmt nicht perfekt, aber immer noch besser als das gewabbere einer sich ständig verändernden Sonnenposition.

Eisflamme hat geschrieben: Naja, das Problem ist ja nicht, die Position der Sonne sanft zu interpolieren bzw. vorsichtig weiterzuschieben,
sondern das durch das "ständige Geschiebe" die resultierenden "großen Schattenpixel auf dem Endbild" ja unter Umständen unschön rumwabbeln... Oder hab ich nun nen Denkfehler?

Ich meinte eher die Interpolation zwischen zwei Shadowmaps. Also praktisch das sanft überblenden der zwei Bilder.

Eisflamme hat geschrieben: Ja, seh ich auch so. Das einzig "Unschöne ist, dass sobald ne figur Unter dem Stein steht, sie natürlich nicht schattiert wird. Wobei ein überstehende Stein bei mir nicht als Terrain gilt [--> Heightmapping], sondern ein eigenes Objekt wäre, was ja sowieso dynamischen Schatten wirft. Und beim eigentlich Heightmap/Quadtree-Basierten Terrain, wie es viele haben, macht das Schattenwerfen nicht IMMER Sinn. Da reichts meist statisch, wenn die Sonne statisch ist oder eben nur Lighting ohne Schatten.

Dass du eine Heightmap benutzt wusste ich nicht. ;) Ich war bei Mesh-Terrain bzw. Voxel-Terrain.
Man kann übrigens auch statische Schatten auf seine dynamischen Objekte ziehen. Mehr dazu hier: http://blog.wolfire.com/2010/04/Catching-baked-shadows

Ich habe ja keine Ahnung von der Materie, aber könnten bei einer statischen Sonne Schattenvolumen nicht wieder Sinn machen? Da könnte man doch im Shader die Schattenvolumen (die ja statisch bleiben, und somit eine überschaubare Grösse haben sollten) gegen die Geometrie der dynamischen Objekte schneiden, und dann das Resultat schattieren.

[youtube]M1GyE1-4j4E[/youtube]
[youtube]yaMDm_Af5kc[/youtube]

Gefällt mir. :)

@Andre: Du hast übrigens nicht wirklich mich zitiert; nur, weil das in den Quoteboxen als Überschrift steht. ;)

Oh, hab das wohl beim herrumkopieren durcheinander gebracht. ;)

@Zudomon: Solche Schatten sind was feines... Gibt es da mehr Informationen zu?

Andre hat geschrieben:@Zudomon: Solche Schatten sind was feines... Gibt es da mehr Informationen zu?

Ich weiß nur noch, dass ich da zwischen den Shadowmaps interpoliert hatte.

Hi,

hat jemand für mich ein gutes Shadowmapping-Tutorial? Ich habe das hier gefunden:

http://www.paulsprojects.net/tutorials/smt/smt.html

Da gibt es drei Rendervorgänge, aber ich finde, es wird schlecht beschrieben, was in jedem einzelnen geschieht. Also ich weiß, dass im ersten aus Lichtperspektive Schatten in eine Textur geschrieben werden, die später dann über Multitexturing verwendet wird. Aber das scheint ja eine große Shadowmap für ALLES zu sein. Also für die gesamte, sichtbare Szene, allein das finde ich schon schwierig. Dann sind da so Finessen drin wie dass Near und Far Plane fast zusammenhängen. Bei meinen ersten Versuchen führt das dazu, dass überhaupt nichts angezeigt wird... usw. usf. lauter kleine Problemchen.

Dann habe ich noch das hier gefunden:

http://fabiensanglard.net/shadowmapping/index.php

Beim Starten der exe sagt er, er könne die Shader nicht kompilieren, ist also auch schon Mal raus.

Wo kann ich mich gut informieren, jemand eine Idee? Danke!Will wie gesagt Abwärtskompatibilität haben, also keine Geometry-Shader... einfache Vertex- oder Fragmentshader sind aber willkommen. :)

Eisflamme hat geschrieben:Da gibt es drei Rendervorgänge, aber ich finde, es wird schlecht beschrieben

Wie du schon schreibst, im ersten Renderpass wird die Szene aus der Sicht der Lichtquelle in eine Tiefentextur (aka Shadowmap) geschrieben. In einem zweiten Renderpass wird dann die Szene beleuchtet, wobei die Tiefentextur verwendet wird, um zu entscheiden, ob ein Pixel beleuchtet ist, oder nicht. Belassen wir es der Einfachheit halber erst mal nur bei einer Lichtquelle.

Eisflamme hat geschrieben:Aber das scheint ja eine große Shadowmap für ALLES zu sein.

Ja, man rendert i.d.R. für Punktlichtquellen für die ganze Szene eine Shadowmap. Das bringt das Problem mit sich, wie man das eigentlich rendert: Standardansätze sind das Rendern der Tiefentextur als Cubemap, oder als Dual-Paraboloid-Map, um irgendwie das ganze Sichtfeld in eine Textur zu kriegen. Das macht das ganze natürlich komplizierter, deswegen wäre es gut, wenn du uns sagst, wofür du das brauchst: Punktlichtquellen, Richtungslichtquellen oder Spotlights?

Ein anderes Problem ist Aliasing, da die Auflösung der Tiefentextur zu gering ist. Dafür gibt es dutzende (Pseudo-)Lösungen, beispielsweise Variance Shadow Mapping, Summed-Area Variance Shadow Maps, Parallel-Split Shadow Maps, und noch viele andere. Um weiche Schatten zu erhalten, gibt's beispielsweise Shadow Mapping mit Percentage-Closer Filtering. Dies alles ist mitunter noch aktuelles Forschungsgebiet.

Eisflamme hat geschrieben:Beim Starten der exe sagt er, er könne die Shader nicht kompilieren, ist also auch schon Mal raus.

Etwas mehr Ehrgeiz, bitte! ;) Wie denkst du die Welt jemals voranbringen zu können, wenn du bei der ersten Schwierigkeit bereits aufgibst? :)

Eisflamme hat geschrieben:Wo kann ich mich gut informieren, jemand eine Idee?

Ein non-bullshit Tutorial für Spotlights mit Percentage-Closer Filtering mit funktionierendem Code findest du hier

Okay, das sind sehr viele nützliche Informationen, danke. :)

Da werde ich mich auf alle Fälle Mal noch etwas ein- und durch- und später hoffentlich etwas Vernünftiges ausarbeiten.

Ich bin jetzt gerade noch an dem Originaltutorial, wo es nur um einfaches Shadowmapping bzgl. Pointlights geht.

Und jetzt frage ich mich, wie ich das bei direktionalem Licht mache. Das ist ja immer gleich, aber die Shadowmap zeigt nur einen Ausschnitt. Soll ich das dann so machen, dass das Licht quasi dem Spieler folgt, sodass der Schatten dann eben einfach immer gleich fällt? Ich kann ja schlecht das gesamte Terrain shadowmappen, dann bräuchte ich ja eine rieeeeeesige Map.

Stichworte: Perspective Shadow Map, Cascaded Shadow Maps

dot hat geschrieben:Stichworte: Perspective Shadow Map, Cascaded Shadow Maps

Für aktuelle Abwandlungen siehe auch meinen vorherigen Post ;) Man kann sich auch mal dieses Sample reinziehen.

Danke, habe mir da Mal angesehen und denke, das kriege ich hin. :)

Voraussetzung dafür ist aber, dass meine aktuellen PointLight-Shadows klappen. :( Ich habe das Beispiel jetzt fast abgetippt (nur ohne diese glut-Modelle, aber vielleicht baue ich da auch bald ein). Die ShadowTexture enthält den Schatten korrekt, wenn ich ihn nämlich einfach auf eine Plane rendere, sehe ich ihn (sehr schwach, aber ich sehe ihn). Sobald ich aber das ganze Gedöns mit EyeLight-Position usw. anwerfe wie in Paul's Tutorial beschrieben, sehe ich nichts mehr, d.h. einfach dass der gesamte belichtete Pass gerendert wird ohne die Schatten halt auszulassen. -.-

Jemand eine wilde Eingebung oder Idee? Hilft Code?

Das ist üblicherweise irgendwo ein Minuszeichen in einer der Koordinatentransformationen - da hilft Dir Code überhaupt nix. Nimm einen gescheiten Debugger und schau Dir die Zwischenstufen in der GPU an, steppe mal durch den Shader eines Pixels usw. Nimm notfalls eine ordentliche GrafikAPI anstatt OpenGL, in der das Debuggen einfacher ist.

Tschuldigung, der letzte Satz war wertend. Ich nehm alles zurück und behaupte nur politisch korrekte Schein-Aussagen.

Also eigentlich geht das Debugen von OpenGL unter Windows ganz easy -> http://code.google.com/p/glintercept/ . Hat bei mir super geklappt und hat mir schon viele Stunden Fehlersuche erspart :)

Guter Hinweis. Ich finde es sehr wichtig, dass man versteht, wie die Koordinatensysteme genau aufgebaut sind. Das ergibt sich die Kette aus Transformationen und alle heimlichen Minuszeichen hier und da von selbst.

Jeason hat geschrieben:Also eigentlich geht das Debugen von OpenGL unter Windows ganz easy -> http://code.google.com/p/glintercept/ . Hat bei mir super geklappt und hat mir schon viele Stunden Fehlersuche erspart :)

Ich hab die 0.5er Version früher viel genutzt, aber dann wurde gDEBugger kostenlos und das ist imo ein deutliche besseres Tool:
http://www.gremedy.com/