Schatten im 3DMark05

[Quasar]

Die obere Hälfte des Bildes zeigt (Ausschnitte aus) Bild 610 aus dem Game-Test 3 'Canyon Flight' des 3DMark05 - die untere Hälfte zeigt entsprechende Teile von Bild 620. Inzwischen hat in der Shadow-Map offenbar ein Mip-Wechsel stattgefunden.

http://home.arcor.de/quasat/3DC-Pics/3DMark05%20-%20Schatten.png

Während die Bilder mit DST (links) eine weniger stark mit Banding behaftete Schattenkante zeigen, stellt die Schattentextur auf der rechten Seite ohne DST den Versuch dar, einen "weicheren" Verlauf zu zeichnen.

Was, meint ihr, ist die Variante mit der höheren Bildqualität?

[FPSn00b]

Insgesamt sieht`s mit DST ganz klar schöner aus (und weil es zudem ein deutliches Leistungsplus bringt, sollte es IMO in allen _nicht-Benchmark-Anwendungen_ benutzt werden, in denen es anwendbar ist). :)
Wobei es bei den hochaufgelösteren Varianten unten meiner Meinung nach unklar ist, welche besser/realistischer in einem Spiel wirken würde, denn der obere Schatten auf dem linken Bild ist schon ein wenig zu scharf, finde ich. - Solange man nicht ranzoomt, oder direkt davor steht, könnte deshalb vielleicht sogar die nicht-DST-Variante sauberer aussehen.

[Muh-sagt-die-Kuh]

Für was steht die Abkürzung "DST"?

[FPSn00b]

Für was steht die Abkürzung "DST"?
Depth Stencil Texture (http://www.beyond3d.com/forum/viewtopic.php?t=16960&start=0)
...
Wobei..ooops...dann sieht der Schatten nicht direkt wegen DST, sondern wegen PCF sauberer aus? :k

[Quasar]

Ja. Die Option "DST" bezieht sich nur auf die Benennung im 3DMark-Setup. Wenn man PCF auch noch über die Shader machen wollte (Texturfilterung), so würde das AFAIK noch einiges extra kosten.

[Xmas]

Wie erklärt sich dann der entfernungsabhängige Auflösungswechsel bsw. im 3DMark05? Mipmapping wäre für mich die naheliegendste Erklärung gewesen.

(Auskopplung aus einem anderen Thread)

Nach etwas Überlegung muss ich meine Behauptung aus dem anderen Thread zurücknehmen: Auch Shadow Buffer (DST) könnten Mipmaps gebrauchen, um Aliasing zu vermeiden. Mitunter gibt es da aber ein Problem bei der Mipmap-Erzeugung... DirectX lässt das nämlich, aufgrund dessen wie DST in die API "eingebaut" wurden, gar nicht zu, wenn ich das richtig sehe.

[Demirug]

Es könnte über auto erzeugte Mipmaps funktionieren. Allerdings werden diese vom Treiber für DST nicht unterstützt. Eine weitere Möglichkeit wäre es wenn man die Spec für StretchRect ein weiteres mal lockern würde.

[Xmas]

Es könnte über auto erzeugte Mipmaps funktionieren. Allerdings werden diese vom Treiber für DST nicht unterstützt. Eine weitere Möglichkeit wäre es wenn man die Spec für StretchRect ein weiteres mal lockern würde.
Ja, neben diesen beiden Möglichkeiten sind auch das "Von-Hand-Berechnen" per CPU (D24 ist nicht lockable) oder GPU (DST binden aktiviert automatisch den Tiefenvergleich) verwehrt.


Zur Anfangsfrage des Threads: Ich denke, dass hier anhand irgendeines Faktors dynamisch die DST-Auflösung reguliert wird. Die non-DST-Variante könnte Mipmaps unterstützen, aber es sieht so aus als würde bei beiden die gleiche Methode verwendet.