Shadow Buffers? Bäh!

[MadManniMan]

naja, ganz sooo schlimm siehts nicht aus ;) aber im vergleich zu stencil shadows ists schon nicht allzu toll...

der screeny unten zeigt das problem der geringen texelanzahl, i.e. wenn die lichtquelle in extremen winkeln zum zu beschattierenden steht, sieht das ganze arg wurstig aus

[KiBa]

Genau deshalb wird diese Technik wohl nie im großen Stil in 3D-Spielen Einzug halten. Vielleicht nur die Models, aber niemals alles, da es immer zu Fehldarstellungen in bestimmten Situationen kommt. Auch ist diese Technik nicht "tiefengenau", die Shadowmap löst nur aus der Sicht der Lichtquelle genau auf, aus jeder anderen Perpektive wirds pixelig (Kanten mit Zacken), auch wenn die Map hochauflösend ist...

[MadManniMan]

und erst recht erschaudern tuts mir bei dem gedanken an cubic shadow maps...

[Unregistered]

Will ja nix sagen, aber ich denke, langfristig setzen sich eher die Shadowmaps durch als die Stencil Shadows. Stencil ist einfach viel zu teuer in Sachen Fillrate, erst recht, wenn man das ganze in echte Beleuchtungsmodelle integrieren will....

Wg. der Auflösung von Shadowmaps gibts jetzt auch neue Ansätze (frisch von der Siggraph 2002), "Perspective Shadow Maps" genannt, die sich genau um dieses Problem kümmern.

Das Thema ist noch lange nicht entschieden *g*

Pitchfork

[MadManniMan]

ich hab nun wirklich kein problem damit, wenn mal shadow maps verbessert... kann nur gut sein!

allerdings kann ich mir als laie momentan kaum vorstellen, wie man das prob ohne erhöhung der auflösung(und damit überproportionalen leistungsverlust) beseitigen will.

weiterhin kann ich mir einfach nicht vorstellen, daß es vernünftige lösungen für directional a.k.a. distant lights in form von shadow maps gibt. die bisherigen mögen notlösung sein, allerdings funktionieren diese so lange, wie es statische sind, bei derart großen texeln wäre das keine augenweide!

weiterhin setzt onkel carmack vorerst auf stencil shadows, was den shadow buffern vorerst das genick anknacksen könnte


BTW: kann es sein, daß beim wolfman 4*ms standartmäßig eingeschaltet ist? sieht mir ARG danach aus...

und wieso lassen einen die leutz bei nv dann nicht die möglichkeit, innerhalb einer techdemo zum GF4 promo zum bq-vergleich die aa möglichkeiten auswählen?

achja: Guten morgen miteinander!

[Iceman346]

Ich versteh zwar nicht wirklich was vom Thema ;) aber trotzdem:
Wie werden eigentlich die Schatten von Neverwinter Nights gemacht? Ich find die wirken ziemlich genial.

[KiBa]

Doppelpost gelöscht...

[KiBa]

Ich denke, in NWN wird auch mit Shadow-Volumes gearbeitet.
Und ich denke auch, dass sich diese Methode durchsetzen wird, die Tatsache, dass Doom3 diese verwendet, sollte eigentlich schon ausreichen... ;)
Die Fillrate kann man z.B. mit Oclussion-Culling verringern, außerdem werden die neuen Karten von NVidia ausreichend Fillrate haben. Und da auf NVidia zur Zeit vorzugsweise entwickelt wird, sehe ich keine Probleme mit der Verbreitung dieser Technik.

[Demirug]

Der Grund warum im Moment jeder Stencil Shadows benutzt ist das es mit fast allen Karten funktioniert. Karten mit Shadowbuffers sind in der Masse noch nicht verfügbar. Da man aber bei der verwendung von Shadowbuffers einiges an der Renderpipeline ändern muss lohnt es sich aussser für Techdemos noch nicht.

@KiBa:

Bei Shadow-Volumes bringt Oclussion-Culling nur sehr wenig (du hast mich da aber auf eine Idee gebracht die sich mit DX9 vielleicht realisieren läst). Die Stencilschatte gehen auch nicht auf die Fillrate sondern auf die Speicherbandbreite. Der Fillrateverlust entsteht nur dadurch das eben in der Zeit in der die Volumen durchgerechnet werden nicht gleichzeitig auch etwas durch die Fragment Pipeline läuft.

[MadManniMan]

Originally posted by Demirug
Da man aber bei der verwendung von Shadowbuffers einiges an der Renderpipeline ändern muss lohnt es sich aussser für Techdemos noch nicht.


ncoh ein grund, der mir so ganz spontan (hehe) einfällt, wäre der, dass man für üblich in techdemos die optischen nachteile der angewandten technologien besser verschleiern kann als in apps direkt.

ich denke so zB nicht, daß jedem geforcegeilen (gut... ein bisschen bin ichs jetzt auch... aber nur ein bisschen! :D ) mal eben der gedanke kommen könnte "hey! da haben sich doch mal ein paar fuzzies drüber unterhalten, daß SB wohl besser als stencil shadows wären... - glaub ich nicht..." und sich dann über die texel der maps gedanken macht...

die einzigen demos(!), die mir im mom einfallen, was SB betrifft, sind der oben gezeigte wolfman, wo die üblichen schatten immer von etwa 75-80° von oben drübergeklatscht werden, sowie die islanddemos von ati, wo die lichtquellen ebenfalls wenig extrem positioniert sind.

[KiBa]

Originally posted by Demirug
Bei Shadow-Volumes bringt Oclussion-Culling nur sehr wenig (du hast mich da aber auf eine Idee gebracht die sich mit DX9 vielleicht realisieren läst). Die Stencilschatte gehen auch nicht auf die Fillrate sondern auf die Speicherbandbreite. Der Fillrateverlust entsteht nur dadurch das eben in der Zeit in der die Volumen durchgerechnet werden nicht gleichzeitig auch etwas durch die Fragment Pipeline läuft.

ähm, es wird doch normalerweise angenommen, dass stencil-schatten füllratenlimitiert sind, das hab ich bis jetzt immer gelesen (polygone des schattenvolumes rendern). speicherbandbreite wird doch nur beim schreiben in den framebuffer und beim lesen der stencil-values verbraucht.
das mit dem occlusion-culling hatte ich mir aber nicht richtig überlegt, das funktioniert auf herkömmliche weise natürlich nicht, da sonst der stencil-count durcheinandergeraten würde.
es sei denn, man könnte zu den gecullten (front/back) faces auch die dazugehörigen (back/front) faces cullen, mmmh...
Wär aber nicht schlecht, da imo viel füllrate gespart werden könnte. bitte erklär das nochmal, wie du das mit der speicherbandbreite meinst. die volumes rendert man natürlich ohne texturen etc, da sollte nicht viel speicherbandbreite draufgehen.
meine experimente mit schattenvolumen bestätigen auch die füllraten-limitiertheit...

[Demirug]

stencil-schatten können gar nicht füllrate limiert sein da die TMUs ja dabei gar nicht benutzt werden. Ich beziehe mich jetzt nur auf das Rendern der Volumen da das Render der Objekte mit Texture ja sowieso gemacht werden muss und nur um den Stencilcheck erweitert wird. Speicherbandbreite kostet die ganze Action weil man ja für jedes AA Sample welches beim Rendern der Volumen ensteht den Stencilwert erhöhen oder verringern muss (also immer einmal einlesen und wieder schreiben) und da du ja schon mit schattenvolumen experimente hast ist dir ja sicher bekannt welche fläche die einzelnen Polys einnehmen.

Es ist aber ohne Chip-Profiler fast unmöglich zwischen einer Füllrate und Speicherbandbreiten limitierung zu unterscheiden das beides eng zusammen hängt.

Das mit dem occlusion-culling würde schon gehen wenn das gesamte volumen eines Objects komplet durch andere Objecte verdeckt ist und deshalb vervorfen werden kann. Ich habe da wie gesagt eine Idee die mit DX9 vielleicht realisiert werden kann.

[Xmas]

Originally posted by Demirug
stencil-schatten können gar nicht füllrate limiert sein da die TMUs ja dabei gar nicht benutzt werden.
???
Was ist denn mit der Pixelfüllrate?

Es ist aber ohne Chip-Profiler fast unmöglich zwischen einer Füllrate und Speicherbandbreiten limitierung zu unterscheiden das beides eng zusammen hängt.
Durch getrenntes Übertakten von Core und Speicher kann man das problemlos unterscheiden.

[Demirug]

Originally posted by Xmas

???
Was ist denn mit der Pixelfüllrate?


OK ihr habt gewonnen und ich hab mich wohl gerade blamiert. Das Rendern der Stencilvolumen frist pixelfüllrate.


Durch getrenntes Übertakten von Core und Speicher kann man das problemlos unterscheiden.

Brutal aber es erfüllt den zweg :D

[Quasar]

Etwas weniger brutal könnte man ja auch untertakten... ;)

[MadManniMan]

Originally posted by Quasar
Etwas weniger brutal könnte man ja auch untertakten... ;)

unser quasar... ein sanfter kerl wie eh und jeh!

[KiBa]

jo, war wohl ein missverständis des begriffs füllrate, ich bin auch richtig ins grübeln gekommen... ;)
speicherbandbreite wird natürlich auch verbraucht, ist aber imo unwesentlich, da meist sehr effizient implementiert.
ich kann es ja verstehen demirug, dass du als entwickler geheimnisse hast, brauchst mir deine idee natürlich nicht zu erklären.
(vielleicht ein zwei stichworte? *bettel* ;) )
bin hobbymäßig sehr mit solchen sachen beschäftigt und immer interessiert an neuen ideen...

[Demirug]

@KiBa:

Ich bastle im Moment an zwei verfahren. Das eine ist aber nich so unausgegoren das icg darüber noch nicht reden möchte.

Das andere Verfahren ist sehr simple dürftte aver gerade in den Aussehenbereichen sehr viel bringen. Das Problem ist momentan das wir zuviele Fragmente in die Pipeline pumpen die durch den early Z aussortiert werden. Die erste massnahme wird es sein ein Hardwareocullusion culling einzufügen welches das Rendern der komplett verdeckten Objecte verhindert. Wir mussten allerdings erkennen das uns dieser Massnahme nicht reichen wird da wir immer noch zuviele unnötige Stencil ops für die schatten hätten. Die Datenanalyse hat aber ergeben das an denn stellen die viele lichtquellen enthalten in der Regel auch viele Gebäude sind die mit den Wänden auch Lichtquellen komplett verdecken. Als Konzequenz versögern wir das erstellen der Schatten Informationen (Stencil oder Buffer) solange hinausgezögert bis wir wirklich ein Polygone damit schatieren müssen. Das wird uns einige Stencilclears bzw SetRenderTarget und natrlich einiges an Bandbreite in der Pipeline einsparen.

Die Optimierunsarbeiten sind aber etwas zurückgestellt worden da war wir mit dem shader system mehr arbeit haben werden als ursprünglich geplant da uns die HSL von DX9 nicht ausreichen wird.

[KiBa]

thx für die ausführung.
ich habe nloß bis jetzt noch nicht mitbekommen, wo du arbeitest... ???

[Demirug]

Originally posted by KiBa
thx für die ausführung.
ich habe nloß bis jetzt noch nicht mitbekommen, wo du arbeitest... ???

Dazu habe ich mal eine schöne Antwort geschrieben die jemand als das länsgste Nein der Welt bezeichnet hat. Um es kurz zu machen der Laden ist noch absolute unbekannt und die PR will im Moment noch nichts öffentlich machen.

[tb]

Perpektivisch berechnete Shadow Maps sehen wesentlich besser aus, zumal die Auflösung(der Shadow Map) wesentlich besser ausgenutzt wird.
NVIDIA's Shadow Buffer ist ja im Grunde nur der normale Shadow Map Algorithmus, welcher bei der Auswahl der z-bias etwas hilft.

http://www-sop.inria.fr/reves/publications/data/2002/SD02/?LANG=gb

Gruß
Thomas

[MadManniMan]

kann man denn nicht eigentlich die texel irgendwie filtern? sicherlich würde da etwas genauigkeit flöten gehen, aber so scharfkantig beißt es sich einfach mit dem rest des bildes.

...moment, die bei der werewolf demo sind ja gefiltert! ja wie denn nun?

[Demirug]

Bei der Geforce kann man ShadowBuffers filtern.

[MadManniMan]

so begeistert wie du von den shadow bufers zu seien scheinst... finden sie in eurer engine anwendung?

[ow]

AFAIK unterstuetzt D3D weder die Shadow Buffers der GF noch die der Radeon (heissen dort "priority buffers")

[Pitchfork]

Originally posted by ow
AFAIK unterstuetzt D3D weder die Shadow Buffers der GF noch die der Radeon (heissen dort "priority buffers")

Im Falle von GF ist das falsch. Es gibt nen wunderbares Papier von NV, wo genau erklärt ist, wie man die ShadowBuffer von NV unter GL und DX einsetzen kann. Das ganze läuft dort mittels spezieller Texturformate (D16 und D24S8).

Wobei es eine sehr interessante Variante des ShadowMappings gibt, die völlig ohne esoterischen Hardwaresupport auskommt. Man sortiert die Objekte nach Entfernung zur Lichtquelle und gibt ihnen anhand dieser Entfernung eine id. Nun wird mittels dieser id der Schatten berechnet und man die Präzisionsprobleme mit dem Z basierten Shadowbuffer nicht mehr, dafür aber (ohne weitere Tricks) kein Selfshadowing mehr.

Pitchfork

[ow]

naja, ich kann mich nur an eine Aussage in der c't erinnern, dass die Shadow Buffers inkompatibel zu D3D sind und deshalb in der naechsten Chipgeneration wohl wieder aus der HW verschwinden. SOwohl bei NV wie ATi.

Lasse mich aber gern eines besseren belehren.:)

[Pitchfork]

Originally posted by ow
naja, ich kann mich nur an eine Aussage in der c't erinnern, dass die Shadow Buffers inkompatibel zu D3D sind und deshalb in der naechsten Chipgeneration wohl wieder aus der HW verschwinden. SOwohl bei NV wie ATi.

Lasse mich aber gern eines besseren belehren.:)

Über ATI Priority Buffer Verfahren weiß ich nichts, aber NV sagt folgendes:

http://developer.nvidia.com/view.asp?IO=hwshadowmap_paper

Pitchfork

[Demirug]

Originally posted by MadManniMan
so begeistert wie du von den shadow bufers zu seien scheinst... finden sie in eurer engine anwendung?

Wird sehr wahrscheinlich als option verfügbar sein.

[tb]

Shadow Buffer sollen angeblich auch im SiS Xabre vorhanden sein, damit wären es schon 2 Hersteller.

Thomas

[Demirug]

Originally posted by ow
naja, ich kann mich nur an eine Aussage in der c't erinnern, dass die Shadow Buffers inkompatibel zu D3D sind und deshalb in der naechsten Chipgeneration wohl wieder aus der HW verschwinden. SOwohl bei NV wie ATi.

Lasse mich aber gern eines besseren belehren.:)

ow, inkompatibel ist so ein hartes Wort. Der Support von Shadow Buffers ist in DX nicht offiziel. Der NVIDIA Weg wiederspricht aber auch nicht der DX Norm.

[MadManniMan]

Originally posted by tb
Shadow Buffer sollen angeblich auch im SiS Xabre vorhanden sein, damit wären es schon 2 Hersteller.

Thomas

moooment... die r200 unterstützt KEINE sb?

ich dachte doch, daß die schatten der islands demos auf diese weise dargestellt werden!

[tb]

Nö, zumindest nicht so wie die GeForce 3/4 Karten. Dort rendert man per DX8 auf eine spezielles Textureformat....(so wird der GF3/4 klar, dass man die Shadow Buffer Einheit verwenden möchte, für Details siehe developer.nvidia.com), deswegen laufen auch die DX8 Shadow Buffer Beispiele nicht auf der Radeon 8500, aber eben vielleicht auf der SiS Xabre. Shadow Mapping ist auf allen problemlos möglich, da hier der Aufwand/Arbeit beim Programmierer liegt, nicht bei der Hardware.

Gruß
Thomas