Z-First Pass als zukünftiger Standard bei shaderlastigen Spielen?

[egdusp]

Hallo,

da bei shaderlastigen Spielen die Pixel immer teurer werden, also mehr Passes brauchen, stellt sich die Frage, ob das Doom3 Prinzip eines zuerst gerenderten Z/Stencil-Buffers zukünftig Standard wird.

Wieviele Next Gen Spiele werden nach diesem Prinzip programmiert (außer D3 und einigen wenigen Ankündigen zumeist osteuropäischer Spieleschmieden weiß ich von nichts) werden?

Ist das Prinzip nur bei geringen Polygonmengen sinnvoll? Würde Stalker als Beispiel einer Polygonschleuder mit diesem Prinzip nicht zurechtkommen?

Ich habe eben gelesen(glaube bei www.tommtisystems.com , bin aber nicht sicher), dass der 2 Sided Stencilbuffer wohl bei DX9 (oder PS 3.0?)Pflicht ist. Evtl. aber auch nur optional.

Wollte nicht der Deltachrome so eine Art Z-First per Hardware erzwingen, zumindest wurde so etwas mal angekündigt (auch hier gilt; bin mir nicht mehr sicher, dass es tatsächlich der DC war, aber von einem Grafikchip wurde so etwas behauptet).

mfg
egdusp

[zeckensack]

Original geschrieben von egdusp
Ist das Prinzip nur bei geringen Polygonmengen sinnvoll? Würde Stalker als Beispiel einer Polygonschleuder mit diesem Prinzip nicht zurechtkommen?Richtig gedacht. Der Z-Pass verbläst Geometrieleistung, und wenn man davon zu wenig hat, kann eine solche Optimierung ins Gegenteil umschlagen.
Was ein Z-Pass ausserdem noch verbraucht ist Z-Bandbreite und natürlich Füllrate.
Die zusätzliche Z-Bandbreite kann ein cleveres Hardware-Design vollständig wegoptimieren.
Der Kostenfaktor Füllrate bleibt.

Allgemein möchte ich behaupten, dass sich diese Technik lohnt, wenn
1)hoher durchschnittlicher Overdraw erzeugt wird (ca >=3)
und
2)die gefüllten Pixel "teuer" sind (viele Texturen und/oder lange Pixel Shader)
und
3)die Geometrieberechnungen "schnell genug"(TM) sind, was iA heisst, dass der Vertex Shader noch mehr Reserven übrig haben muss als der Pixel Shader

[Coda]

2)die gefüllten Pixel "teuer" sind (viele Texturen und/oder lange Pixel Shader)
und
3)die Geometrieberechnungen "schnell genug"(TM) sind, was iA heisst, dass der Vertex Shader noch mehr Reserven übrig haben muss als der Pixel Shader
Das wird in zukünftigen Spielen aber immer mehr der Fall sein

[Quasar]

Nicht umsonst hat nV beim nV36 das komplette VS-Array des nV35 übernommen.

[Blutgrätsche]

Das UND in 1)2)3) könnte man auch in ein ODER verwandeln. Noch besser wäre allerdings: Wenn hoher Overdraw, dann auch mit relativ kurzen Shadern. Wenn niedriger Overdraw, dann längere Shader. Es kommt weniger auf die mittlere Framerate an, sondern auf die minimale Framerate. Meinetwegen darf die mittlere fallen, wenn sich die minimale erhöht.

Zixel-Fillrate-Optimierungen in Chips sind inzwischen üblich. Das grösste Problem sind Alpha-Test-Texturen. Diese in Polygone umzuwandeln hilft nicht nur der Overdraw-Vermeidung, sondern auch Multisample-AA. Leider bedeutet dies erheblichen Mehraufwand für den Designer und den VS. Bei Spielen innerhalb von Gebäuden oder Höhlen lassen sich A-Texturen relativ leicht vermeiden, aber bei Landschaften wird es schwierig (Bäume, Blätter, Gräser usw.).

[egdusp]

Wißt ihr von angekündigten Spielen, außer auf D3 basierenden, die auch die Technik benutzen?

Sollte nicht Kreed (oder Breed?) auch sowas benutzen? Jedenfalls das Spiel, wo es mal eine Techdemo gab vor min. 12 Monaten, in der man in einer Raumstation rumgehen konnte. Gab nicht viel zu tun, weiß nur noch, dass auf meiner Radeon 8500 die dynamischen Schatten nicht funktionierten, und es trotzdem teilweise geil aussah.

mfg
egdusp

[mapel110]

Du meinst Kreed, aber nach heutigen Massstäben ist das Game noch bestenfalls Durchschnitt.
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=117350&perpage=20&highlight=kreed&pagenumber=2
Ich hatte das Original.

Glaube kaum, dass das Game in irgendeiner Weise technologischen Fortschritt bietet. ;)

[aths]

Ich halte Z-Passes für ziemlich wichtig. Vertexshader-Leistung ist inzwischen reichlich da, und Vertex-Koordinaten gibt es nun mal weniger als Pixeldaten. Geile lange Pixelshader werden dank Early-Z-Occlusion überhaupt erst möglich, denke ich.

[egdusp]

Aber bisher kennt keiner von euch zukünftige Spieleengines außer D3 die darauf aufbauen?

Welche Grafikkarte sollte das gerüchteweise nochmal können?

So schwer kann die Technik doch nicht zu programmieren sein, wenn sogar schon ein Hobby Programmierer die hinbekommt (Quake, Tenabrae Mod).

mfg
egdusp

[Coda]

Naja, das Problem bei Spieleengines war schon immer es schnell hinzubekommen ;)
Und Tenebrae is bei mir ziemlich langsgam :)

[aths]

Original geschrieben von egdusp
Aber bisher kennt keiner von euch zukünftige Spieleengines außer D3 die darauf aufbauen?

Welche Grafikkarte sollte das gerüchteweise nochmal können?Early Z Occlusion gibts prinzipiell ab GeForce3. Allerdings mit unterschiedlicher Effizienz, gute Early-Z-Logik könnte eine Menge Z-Füllrate sparen.

[Quasar]

Tenebrae hat zwar Bump-Mapping und Echtzeit-Stencilschatten, aber ich höre hier zum ersten Mal, daß da ein Z-First-Pass erfolgt.

edit:
Ich meine mich zu erinnern, das TRAOD einen solchen nutzt. Bin mir da aber sehr unsicher.

[Demirug]

Original geschrieben von Quasar
Tenebrae hat zwar Bump-Mapping und Echtzeit-Stencilschatten, aber ich höre hier zum ersten Mal, daß da ein Z-First-Pass erfolgt.

edit:
Ich meine mich zu erinnern, das TRAOD einen solchen nutzt. Bin mir da aber sehr unsicher.

Stencil-Schatten setzen in der Regel einen Z-Pass vorraus.

[MadManniMan]

Ömm, fühlt sich da nicht eigentlich ein TBDR schön verarscht? :|

[zeckensack]

Original geschrieben von MadManniMan
Ömm, fühlt sich da nicht eigentlich ein TBDR schön verarscht? :| Nö. Ein TBDR kann auch bei einem Z-Pass noch Bandbreite einsparen. Die erzeugten Z-Werte müssen weder geschrieben, noch wieder eingelesen werden.

Bei Rendering ala Doom 3 sind die folgenden Passes zudem "dank" Blending auf einem IMR relativ bandbreitenintensiv. Die Beiträge der einzelnen Lichter werden dabei nacheinander aufaddiert => alte Farbe einlesen, addieren, zurückschreiben. Auch hier kann sich ein TBDR einen Grossteil der Speichertransfers ersparen.

Zu D3-Style-Rendering ist Fablemark ein recht guter Indikator, und wie die Kyro da im Vergleich abschneidet, sollte bekannt sein.

[Ailuros]

Original geschrieben von Demirug
Stencil-Schatten setzen in der Regel einen Z-Pass vorraus.

Schon aber Tenebrae ist wohl eher ein Fall wie man stencil-schatten nicht implementieren sollte. Anders kann ich mir die sehr schlechte Leistung auf allen Loesungen nicht erklaeren.

[Quasar]

Original geschrieben von Demirug
Stencil-Schatten setzen in der Regel einen Z-Pass vorraus.

Einen Z-Pass, ok. Aber einen Z-First um so den gerenderten Overdraw gegen Null zu bekommen? Ist das nicht noch ein bißchen was anderes, als "nur" pro Lichtquelle die Stencils per Z machen zu müssen?

[Demirug]

Original geschrieben von Quasar
Einen Z-Pass, ok. Aber einen Z-First um so den gerenderten Overdraw gegen Null zu bekommen? Ist das nicht noch ein bißchen was anderes, als "nur" pro Lichtquelle die Stencils per Z machen zu müssen?

Wie meinen?

Für Stencilschatten rendert man zuerst den Z-Buffer (Z-Pass) dann für jede Lichtquelle die Schattenvolumen in den Stencilbuffer und die Farbe wir im Backbuffer hochsummiert.

Das mit dem Overdraw ist dabei ein willkommener Nebeneffekt.

[Quasar]

Original geschrieben von Demirug
Wie meinen?

Für Stencilschatten rendert man zuerst den Z-Buffer (Z-Pass) dann für jede Lichtquelle die Schattenvolumen in den Stencilbuffer und die Farbe wir im Backbuffer hochsummiert.

Das mit dem Overdraw ist dabei ein willkommener Nebeneffekt.
:gruebel:

Also gibt es keine Möglichkeit, Stencil-Schatten von "normalem" Z-Pass (sprich: Für normale per-pixel Ops, wie Texturing, Bump-Mapping etc.) zu trennen?
Das war es, was mir im Kopf rumgeisterte.

[MadManniMan]

Original geschrieben von zeckensack
Nö. Ein TBDR kann auch bei einem Z-Pass noch Bandbreite einsparen. Die erzeugten Z-Werte müssen weder geschrieben, noch wieder eingelesen werden.

Bandbreite gespart. Da freuter sich, der TBDR! :)

Original geschrieben von zeckensack
Bei Rendering ala Doom 3 sind die folgenden Passes zudem "dank" Blending auf einem IMR relativ bandbreitenintensiv. Die Beiträge der einzelnen Lichter werden dabei nacheinander aufaddiert => alte Farbe einlesen, addieren, zurückschreiben. Auch hier kann sich ein TBDR einen Grossteil der Speichertransfers ersparen.

Bandbreite gespart. Da freuter sich, der TBDR =)

Original geschrieben von zeckensack
Zu D3-Style-Rendering ist Fablemark ein recht guter Indikator, und wie die Kyro da im Vergleich abschneidet, sollte bekannt sein.

Foresysht! Sagenmarke(R) mach aber keinen Z-First zwecks nix ÜberMal(R).

Deshalb wird sich der TBDR immernoch Folgendes denken: "Scheiße hier! Ich bin so breit an Bandbreite, aber trotzdem is hier akuter Fall von FüllNix(R), weil nix zum Mitfüllen da. Ich bin ein TBDR, der non-Alpha-Overdraw gen Null schraubt. Aber dieser Ach-So-Tolle Vorteil ist jetz kaum mehr einer, weil JC auch IMs zumindest ähnlich wenig Overdraw vorsetzt... So, deshalb pfeif ich mir jetz n Elektrobier rein, randalier ne Transistortür ein und freu mich auf die Elektrobullen..."

Ich mein, muß doch voll deprimierend für so nen TBDR sein, der sein Ego über seine Effektivität aufbaut. Wenn da nun son alberner BruhtFohrß-IM ankommt und in der Engine seine Füllrate ebenso sinnig anbringt - na das geht doch voll aufs Ego!

:no:

[Demirug]

Original geschrieben von Quasar
:gruebel:

Also gibt es keine Möglichkeit, Stencil-Schatten von "normalem" Z-Pass (sprich: Für normale per-pixel Ops, wie Texturing, Bump-Mapping etc.) zu trennen?
Das war es, was mir im Kopf rumgeisterte.

Ich verstehe immer noch nicht ganz was du meinst.

Beim "normalen" Rendern wir die Farbe und der Z-Wert gleichzeitig berechnet.

Für Stencil Schatten braucht man beim Rendern der Farbe einen Stencilbuffer indem gespeichert ist wo licht und Schatten ist. Zum Berechnen dieses Buffers ist es aber erforderlich das im Z-Buffer bereits die Z-Werte für die gesamte Szene gespeichert sind. Aus diesem grund muss man das Berechnen des Z-Buffer von Berechnen der Pixelfarbe trennen.

[ow]

.

[ow]

.

[Demirug]

Original geschrieben von ow
Gilt das immer?
Also auch für Q3 mit cg_shadows "2"?
Oder die Kyro Demos "Softshadows" oder "Fablemark"?

Was wäre denn dann so neu an der Doom3 engine?

Die beiden Kyro Demos wurden doch programmiert nachdem JC öffentlich gesagt hat wie DOOM III rendern wird.

Beim Fabelmark bin ich mir jetzt nicht ganz sicher aber Softshadows rendert den Z-Pass zusammen mit dem Ambientpass. Da das ambiente Licht ja nicht von Schatten betroffen ist kann man das machen.

Was cg_shadows = 2 genau macht weiss ich nicht AFAIK ist das aber eine Form von Projektionsschaten.

[Demirug]

Original geschrieben von ow
Ich versteh jetzt auch gar nix mehr. :(

Heisst das, dass immer dann, wenn man zB. ein D24S8 Format nutzt, die Applikation automatisch einen Z-only pass macht?

Nein, natürlich nicht. Das Format des Z-Buffers hat damit gar nichts zu tun.

[ow]

.

[Demirug]

Man kann den Stenciilbuffer auch für andere Sache als für Schatten benutzten.

Das ein Stencilbuffer benutzt wird heisst nicht das man auch einen Z-Pass braucht.

Der Z-Pass ist aber zwingend erforderlich für das volumenschatten Stencilbuffer Verfahren.

Paperstorm braucht einen Z-Pass. Rendert dabei aber gleich wieder das Ambient Licht mit. Ist also kein Z-Only Pass.

[Quasar]

Original geschrieben von Demirug
Ich verstehe immer noch nicht ganz was du meinst.

Beim "normalen" Rendern wir die Farbe und der Z-Wert gleichzeitig berechnet.

Für Stencil Schatten braucht man beim Rendern der Farbe einen Stencilbuffer indem gespeichert ist wo licht und Schatten ist. Zum Berechnen dieses Buffers ist es aber erforderlich das im Z-Buffer bereits die Z-Werte für die gesamte Szene gespeichert sind. Aus diesem grund muss man das Berechnen des Z-Buffer von Berechnen der Pixelfarbe trennen.

Ich habe das so verstanden, daß beim normalen Rendern eben die Engine für das Sortieren verantwortlich ist. Was reinkommt, wird gerendert, auch wenn's später verdeckt ist. Dann kommt der Z-Buffer, bzw. der Z-Check ins Spiel und bestimmt am Ende, was alles sichtbar ist, und was nicht.

Bei moderneren Grafikkarten läßt sich das zu einem gewissen Grad durch Early-Z bzw. HyperZ umgehen, auch wenn die Engine B2F-Sorting macht.

Beim Z-First-Pass, um eben beim endgültigen Rendern Null Overdraw zu haben, habe ich das so verstanden, daß erstmal ein Durchlauf ohne Pixel-Rendering gemacht wird, (keine Ahnung: Nur Blending oder gar Wireframe-Abbildung intern?). Dann hat man die endgültigen Z-Werte und anhand derer wird bestimmt, welche Teile von welchen Objekten sichtbar sein werden und welche nicht.

Die sichtbaren Teile werden dann gerendert.

Und das sagte mein Posting aus, AFAIK. Du hast dann angefangen, daß Stencil-Schatten einen Z-Pass voraussetzen. Das habe ich dann (fälschlich?) auf "meinen" Z-First-Pass bezogen, der den Overdraw komplett killen soll.
Daraus ist dann diese Diskussion bzw. Fragestunde hervorgegangen.

[Demirug]

Original geschrieben von Quasar
Ich habe das so verstanden, daß beim normalen Rendern eben die Engine für das Sortieren verantwortlich ist. Was reinkommt, wird gerendert, auch wenn's später verdeckt ist. Dann kommt der Z-Buffer, bzw. der Z-Check ins Spiel und bestimmt am Ende, was alles sichtbar ist, und was nicht.

Ganu.

Bei moderneren Grafikkarten läßt sich das zu einem gewissen Grad durch Early-Z bzw. HyperZ umgehen, auch wenn die Engine B2F-Sorting macht.

Ja, der Pixelshading teil wird unterdrückt.

Beim Z-First-Pass, um eben beim endgültigen Rendern Null Overdraw zu haben, habe ich das so verstanden, daß erstmal ein Durchlauf ohne Pixel-Rendering gemacht wird, (keine Ahnung: Nur Blending oder gar Wireframe-Abbildung intern?). Dann hat man die endgültigen Z-Werte und anhand derer wird bestimmt, welche Teile von welchen Objekten sichtbar sein werden und welche nicht.

Gerendert werden die Pixel schon allerdings eben nur in den Z-Buffer (Z-Only-Pass).

Die sichtbaren Teile werden dann gerendert.

Es wird nochmal alles gerendert aber durch Early-Z erreicht alles was nicht sichtbar ist den Pixelshader nicht.

Und das sagte mein Posting aus, AFAIK. Du hast dann angefangen, daß Stencil-Schatten einen Z-Pass voraussetzen. Das habe ich dann (fälschlich?) auf "meinen" Z-First-Pass bezogen, der den Overdraw komplett killen soll.
Daraus ist dann diese Diskussion bzw. Fragestunde hervorgegangen.

Wenn der Z-Pass für die Schatten als Z-Only ausgeführt wird kommt es ja auch auf das gleiche heraus.

[Quasar]

Original geschrieben von Demirug
Wenn der Z-Pass für die Schatten als Z-Only ausgeführt wird kommt es ja auch auf das gleiche heraus.

Ja, aber ich meinte eben einen (oder mehrere) Z-First Pass für die komplette Szene, wie es "dieser eine Chip" in Hardware gehabt haben sollte (vielleicht kommt's ja noch).

[Demirug]

Original geschrieben von Quasar
Ja, aber ich meinte eben einen (oder mehrere) Z-First Pass für die komplette Szene, wie es "dieser eine Chip" in Hardware gehabt haben sollte (vielleicht kommt's ja noch).

Genau das macht man doch. Alle Objekte die in der Szene auftauchen werden einmal in den Z-Buffer gerendert und dann nochmal mit dem richtigen Shading.

Bei der Hardwarelösung von der du hier sprichst wird der Z-Pass über die gesamte Geometrie erzwungen was aber letzte Endes auf das gleiche hinaus läuft.

[ow]

.

[Quasar]

Original geschrieben von Demirug
Genau das macht man doch. Alle Objekte die in der Szene auftauchen werden einmal in den Z-Buffer gerendert und dann nochmal mit dem richtigen Shading.

Ja, so dachte ich, läuft es. Deswegen kann ein Z-First Pass eine Menge Shaderleistung sparen.

Aber der Knackpunkt: Ist dieser Z-First-Pass zwingend nötig, sobald Stencils ins Spiel kommen? Ich dachte, daß ist nicht so.
Klar, man braucht Z-Passes für die Stencils, aber wird dabei notwenig auch schon ein HSR gemacht, oder kann man, wenn man halt nicht drauf achtet, auch das komplette Shading schon mit reinnehmen, mit dem "Erfolg", daß dann die verdeckten Objekte eben auch geshadert werden müssen?

[Demirug]

Original geschrieben von Quasar
Aber der Knackpunkt: Ist dieser Z-First-Pass zwingend nötig, sobald Stencils ins Spiel kommen? Ich dachte, daß ist nicht so.
Klar, man braucht Z-Passes für die Stencils, aber wird dabei notwenig auch schon ein HSR gemacht, oder kann man, wenn man halt nicht drauf achtet, auch das komplette Shading schon mit reinnehmen, mit dem "Erfolg", daß dann die verdeckten Objekte eben auch geshadert werden müssen?

Wenn du das Schading vor dem Stencilpass durchfürst hast du ein Problem. Alle Pixel haben dann die Farbe die sie hätten wenn es keinen Schatten gibt. Nach dem Stencilpass hast du dann im Stencilbuffer die Information welche Pixel im Schatten liegen. Nun könnte man diese Pixel ja mit einem zusätzlichen Pass schwarz setzten bzw durch Alphablendig abschwächen. Dieses Verfahren wurde auch schon benutzt. Im DX-SDk gibt es ein Beispiel das genau das macht. Das Verfahren hat jedoch zwei Nachteile.

1. Man verbraucht tendenziel zu viel Füllrate.

2. Das ganze funktioniert nur mit einer einzigen Lichtquelle.

Sobald man 2 Lichtquellen hat gibt es 4 möglichkeiten für jeden Pixel

1. Der Pixel wird von beiden Lichtquellen beleuchtet.
2. Der Pixel wird von keiner der beiden Lichtquellen beleuchtet.
3. Der Pixel wird nur von Lichtquelle 1 beleuchtet.
4. Der Pixel wird nur von Lichtquelle 2 beleuchtet.

Würde man nun beim Z-Pass gleich das Schading mitrendern und dann erst diue Schatten volumen könnte man die Fälle 1 und 2 abdecken. Aber wie soll man bei den Fällen 3 und 4 den Farbanteil der anderen Lichtquelle wieder herausbekommen? Unter umständen liese sich das ja noch machen aber dafür müsste man diesen Anteil ja nochmal errechnen.

Sobald man also mehr als eine Lichtquelle hat kann man das Schading nicht mehr komplett in einem Pass berechnen sondern muss es nach Lichtquellen gtrennt rechnen. beim Z-Pass kann man aber wie schon erwähnt das Ambiente Licht mitrechnen weil dieses ja niemals im Schatten liegen kann.

[Quasar]

Ok, und wie macht Tenebrae das nun? :D

[Demirug]

Original geschrieben von Quasar
Ok, und wie macht Tenebrae das nun? :D

Keine Ahnung. Von dem Quellcode lasse ich die Finger. Da war schon das Original sehr unleserlich.

[loewe]

Original geschrieben von MadManniMan
Ich mein, muß doch voll deprimierend für so nen TBDR sein, der sein Ego über seine Effektivität aufbaut. Wenn da nun son alberner BruhtFohrß-IM ankommt und in der Engine seine Füllrate ebenso sinnig anbringt - na das geht doch voll aufs Ego!

:no:

Ganz so schlimm ist es nun wieder auch nicht. ;)

Der einzige TBDR den ich kenne, die von PowerVR, definieren sich natürlich weitgehend über Effektivität. Aus diesem Grunde werden alle z-Tests und auch alle Stencil-ops im ISP durchgeführt und dieser arbeitet parallel zum TSP. Somit wird durch den z-only Pass keine Füllrate verbraucht, während die IMRs hier ihre Pipeline bemühen müssen.

[MadManniMan]

Original geschrieben von loewe
Ganz so schlimm ist es nun wieder auch nicht. ;)

Der einzige TBDR den ich kenne, die von PowerVR, definieren sich natürlich weitgehend über Effektivität. Aus diesem Grunde werden alle z-Tests und auch alle Stencil-ops im ISP durchgeführt und dieser arbeitet parallel zum TSP. Somit wird durch den z-only Pass keine Füllrate verbraucht, während die IMRs hier ihre Pipeline bemühen müssen.

Ha! Also doch Füllratensparen! :bounce:
Ja, nagut schonen wir den Begriff TBDR und machen S3/S5 draus, ok? Ich gebs ja zu...

Zwei Begriffsklärungen wünsche ich: ISP und TSP. Letzteres ist zwar eines meiner Lieblingslieder von Muse' aktuellem Album "Absolution", aber das hat gewiß wenig mit PVR zu tun. Naja, obwohl... heißt ja "The Small Print"... Kacheln ahoi...

:D

[Demirug]

ISP = Image Synthesis Processor: Dieser teil des Chips entscheidet welche Pixel wirklich sichtbar sein werden.

TSP = Texture Shading Processor: Dort werden die vom ISP bestimmten Pixel dann gerendert.