Woah, tatsächlich Brute-Force drauf los? Die SDK-Demo geht bei mir schon bei acht simultanen Stencil-Schatten in die Knie, dann möchte ich von der Performance garnichts hören :D Dann sind es aber auch keine Soft-Shadows mehr, sondern einfach nur viele viele Lichtquellen mit Hard-Shadows. So kann das ja jeder ;)
Nagut, dann mal zurück zum ursprünglichen Problem. Schatten, deren Schärfe man als pixelgenau bezeichnen würde, sind in der Realität kaum anzutreffen, denn die meisten Lichtquellen sind großflächige Strahler (die Sonne ist noch die Lichtquelle mit der größten Schärfe, also dem höchsten Verhältnis von Helligkeit zu scheinbarer Größe, alle anderen sind noch verschwommener!). Leider sind immernoch alle Engines darauf getrimmt, ausschließlich die Sonne und künstliche Lichtquellen zur Beleuchtung zu nutzen. Fenster und Türen als Lichtquellen wären für Indoor-Szenen ein gewaltiger Fortschritt, und da sind die Schatten nochmals viel, viel weicher – oft
so weich, dass man nicht einmal mehr direkt am Berührungspunkt des Occluders mit dem Boden sowas wie einen harten Schatten erkennen kann. Indoor-Szenen mit fünf bis zehn weichen Lichtquellen auszustatten kann einen netten Global-Illumination-Look erzeugen, nur viel günstiger – da liegt der größte Nutzen von Soft-Shadows. Mit Stencils dürfte das aber problematisch werden.
In diesem Zusammenhang wäre es interessant zu wissen, wieviele Texel einer Shadow-Map weniger als einen Pixel geblurt werden (also wirklich pixelgenau gefordert sind) – ich wette, es sind höchstens um die fünf Prozent. Das sieht man auch gut an deinen Beispielen – die Schattenkante, die vielleicht fünfzig Meter lang ist, ist nur auf den ersten beiden Metern so scharf, dass Stencils sich lohnen würden. Wann immer man einen oder mehr Texel in jede Richtunng blurt, ist die Shadow-Map nicht mehr als quantisiert zu identifizieren (Shannon-Nyquist?), und ich würde darauf tippen, dass darunter ein Großteil aller Schattenflächen fällt.
Zudomon hat geschrieben:Man müsste nur einen Weg finden, Alphatexturen zu realisieren und eine Möglichkeit, den schnell weich zu bekommen.
Und für Shadow-Mapping müsste man nur einen Weg finden, unendlich hoch aufzulösen … das ist eine Schwäche des Konzepts und nichts, was man mal schnell durch eine besonders kluge Implementation aus dem Weg räumen kann. Für sowas gibt es nichts anderes als Hybridansätze und viel, viel Trickserei.
Schrompf hat geschrieben:Für eine Parallellichtquelle: ja, es muss 32Bit-Float sein.
Stimmt, drei Zentimeter sind bei sowas wirklich viel zu grob. Aber bei Floats habe ich da immer Skrupel – man verschenkt ein ganzes Bit wegen dem verdammten Vorzeichen … :/
Schrompf hat geschrieben:Für eine Punkt- und Kegellichtquelle: ja, da könnte man 16Bit-Floats benutzen. Hier kommt jetzt aber eine Eigenheit der modernen Grafikkartenwelt zum Tragen: NVidia-Karten können keine Rendertargets mit 16Bit pro Pixel benutzen.
Ich weiß, dass ihr mich dafür hasst, aber: D3D9 gehört nicht zur „modernen Grafikkartenwelt“ ;)
Schrompf hat geschrieben:Weiß nicht... das, was ich bisher von der Verteilung auf Rendertargets im GeometrieShader gelesen habe, sprach davon, dass es bislang eher langsamer als die 6Pass-Lösung sei. Scheint wohl eine Eigenheit der aktuellen GeometrieShader-Implementationen zu sein. Hat da jemand Erfahrungswerte aus erster Hand dazu?
Würde mich auch mal interessieren … schließlich sollten die Kinderkrankheiten langsam ausgemerzt sein. Bei meinen Sternen funktioniert „aus eins mach sechs“ sehr gut, aber das ist wohl leicht was Anderes. Übrigens hat D3D10 mit Stream-Out einen weiteren Vorteil für das Rendern von Schatten.
Zudomon hat geschrieben:Ich weiß jetzt die richtige Formel nicht und eigentlich gibt es ja auch keine richtige Formel. Denn das ausgesendete Licht richtig sich ja nach der Fläche. Klar könnte man nun eine Formel benutzen, die die Lichtquelle als Kugel darstellt. Aber wenn man mal einen leuchtenden Schriftzug hat, muss man andere Wege gehen.
Die richtige Formel lautet „projeziere die Welt aus Sicht des Pixels auf eine Halbkugel und intergriere darüber“ ;) Es wäre ein Anfang, Lichtquellen als Kugeln darzustellen. Rechtecke wären auch nützlich, dann hätte man 95% der Fälle (von Glühbirnen über Neonröhren bis zu Türen und Fenstern) abgedeckt. Letzten Endes braucht man aber ein Abbild der Lichtquelle, das man als Filter benutzt, am besten nicht auf eine einzelne Map, sondern auf viele verschiedene. Das nähert sich Global Illumination an, aber wenn ich sehe wieviele Lichtquellen du für den Stencil-Screenshot platziert hast, ist das schon garnicht mehr soo abwegig ;)
