Logarithmischer Depth Buffer

[Niki]

In meinem Terrain Editor benutze ich momentan Raycasting anstelle einer interaktiven 3D-Darstellung. In dieser Phase setze ich mich damit auseinander, wie ich ein Höhenfeld so erzeuge, dass es natürlich aussieht und auch spielbar ist. Das ist in sich schon schwer genug. Da kann ich nicht auch noch die Z-Buffer-Probleme und die eingeschränkte Sichtweite einer interaktiven 3D-Dartstellung brauchen. Also Raycasting. Und wenn ich dann wirklich mal interaktiv latschen will, dann öffne ich das Terrain in meinem Spiel.

Oder so dachte ich jedenfalls...

Ein natürliches, spielbares Höhenfeld zu erzeugen erfordert einen ungemeinen Forschungsaufwand. Deshalb bin ich momentan im Forum auch so stille, weil ich nichts anderes tue als zu forschen und zu testen. Wenn dann der Grid Tracing Algorithmus, mit Debugger im Hintergrund, mehrere Minuten braucht um ein Bild anzuzeigen, dann nervt das. Also Googeln nach Terrains mit großer Sichtweite und Z-Buffer Problemen. Und was finde ich? Logarithmic Depth Buffer (http://outerra.blogspot.de/2009/08/loga ... uffer.html). Für viele hier wahrscheinlich schon ein alter Hut.

Also mal schnell eingebaut. Für Direct3D bin ich da auf folgende Formel gekommen:

Code: Alles auswählen

position.z = log(C * position.z + 1) / log(C * farPlaneDistance) * position.w;

Ich bin mehr als nur begeistert, und echt dankbar für die Forschungsarbeit, die die Outtera-Jungs da reingesteckt haben. Sichtweite auf 200 km (!) gestellt. Ich konnte das gesamte Terrain sehen, ohne das mir auch nur ein Z-Artefakt aufgefallen wäre. Habe mir ein sichtbares Ziel ausgesucht und bin drauf losgelatscht. War etwa 50 km entfernt. 15 Minuten hat es gedauert da hin zu rennen. Null Z-Buffer Probleme, mit 24 Bit Tiefe und 8 Bit Stencil. Schalte ich den logarithmischen Z-Buffer aus, dann sind Hopfen und Malz verloren!

Einfach nur klasse!

[B.G.Michi]

Hab diese Formel in meinem Weltraum-Prototypen verwendet. Near-Plane: 0,1; Far-Plane: FLT_MAX (!), Einheiten in Meter und 32-Bit-Depth-Buffer. Keine Z-Artefakte :D

[Niki]

Ohne jetzt weiter drüber nachzudenken, aber das muss doch auch für Shadowmaps echt gut sein. Wenn ich soweit bin, dann muss ich mal ausprobieren ob man die Kaskaden auch einfach in die Tonne werfen kann!? Aber eins nach dem anderen :)

EDIT: Was ich auch noch rausfummeln muss, ist wie ich damit die Kamerakoordinaten eines Vertex aus dem Z-Buffer bekomme. Aber auch das erst später.

[B.G.Michi]

Meinst du Cascaded-Shadow-Maps? Hierbei geht es aber um die Verbesserung der XY-Auflösung nahe an der Kamera. Logarithmic-Z-Buffering verbessert die Z-Auflösung in großer Entfernung zur Kamera.

@EDIT: deine Funktion einfach nach dem rechten 'position.z' auflösen:

Code: Alles auswählen

// Division durch position.w wird implizit ausgeführt, "* position.w" fällt also weg:
depth_value = log(C * camera_space_position.z + 1) / log(C * farPlaneDistance) * position.w; // / position.w
=> camera_space_position.z = (exp(depth_value * log(C * farPlaneDistance)) - 1) / C;

[Niki]

Ja, ich meine die Cascaded Shadow Maps. Die Idee wäre einfach nur eine Kaskade mit maximaler X/Y-Auflösung zu nutzen. Aber wie gesagt, ich habe noch nicht im Detail drüber nachgedacht, und rede deshalb womöglich Unsinn!

Super! Vielen Dank für das Code Snippet. Ein Ding weniger über das ich nachdenken muss :)

[Niki]

Mal Screenshots für die die es interessiert. Es geht nicht um Optik sondern um den Z-Buffer. Und, ja, der Berg ist viel weiter weg als es aussieht. Für beide Bilder gilt: 24 Bit Z-Buffer, Near=0.1, Far=200000.

(1) Normaler Z-Buffer. Optisch schon nach kurzer Distanz kaputt.


(2) Logarithmischer Z-Buffer. Null Probleme.

[Krishty]

Hast du das mal probiert? … kommt ohne zusätzlichen Rechenaufwand aus, falls dein Tiefenpuffer Gleitkommaformat hat:

You can regain most of the lost precision compared to W-buffering by switching to a floating point depth buffer. This way you get two types of non-linearities that to a large extent cancel each other out, that from Z and that from a floating point representation. For this to work you have to flip the depth buffer so that the far plane is 0.0 and the near plane 1.0, which is something that's recommended even if you're using a fixed point buffer since it also improves the precision on the math during transformation. You also have to switch the depth test from LESS to GREATER. If you're relying on a library function to compute your projection matrix, for instance D3DXMatrixPerspectiveFovLH(), the easiest way to accomplish this is to just swap the near and far parameters.

[Niki]

Hast du das mal probiert? … kommt ohne zusätzlichen Rechenaufwand aus, falls dein Tiefenpuffer Gleitkommaformat hat

Ich hab's grad probiert aber auf die Schnelle nicht hingekriegt. Ich wusste aber auch so schon, dass ein 32-Bit Float Reversed Depth-Buffer etwas besser ist als ein 24-Bit Logarithmischer Depth-Buffer. Entsprechende Vergleiche sind hier: http://outerra.blogspot.de/2012/11/maxi ... e-and.html

Aber mal davon abgesehen bin ich mir nicht sicher ob ich den Stencil-Buffer verlieren möchte. Und sowas wie D32_FLOAT_S8X24_UINT ist vielleicht etwas herbe.

[eXile]

Bevor ihr alle losrennt, und eure z-Buffer umstellt: Der konservative depth output reaktiviert nur die Hierarchical-Z-, nicht aber Early-Z-Optimierungen. Wie immer also gilt, nur das zu verwenden, wenn es zu einem Problem wird. Wenn man aber andererseits schon einen Z-Buffer in einem Gleitkommaformat benutzt, dann kann man near und far planes ohne Performanceverlust vertauschen und erhält eine bessere Tiefenverteilung; das ist also ein ziemlicher no-brainer, wenn man schon ein solches Format benutzt.

Um diesen Post noch etwas mit interessanten Sachen zu unterfuttern:

[CodingCat]

Bevor ihr alle losrennt, und eure z-Buffer umstellt: Der konservative depth output reaktiviert nur die Hierarchical-Z-, nicht aber Early-Z-Optimierungen. [...] Um diesen Post noch etwas mit interessanten Sachen zu unterfuttern:[...]

Woher kommt das? Wo liegt der Unterschied zwischen Z-Cull und Early Depth? Wieso benutzen die bei UAVs und/oder konservativen Tiefen kein [earlydepthstencil]? Wieso nutzen die ausgerechnet im Standardfall [earlydepthstencil], wo ich eine Erkennung desselben vollautomatisch erwarten würde? Beziehen die sich ausgerechnet da auf Stenciloperationen?!

Zu Outerras / Nikis logarithmischen Tiefen im Vertex Shader: Ich bezweifle sehr stark, dass die Interpolation des projizierten Z-Wertes hier korrekte Tiefen liefert; alles was man über die so erzeugten Tiefenwerte wohl sagen kann, ist, dass sie irgendwo zwischen Minimal- und Maximaltiefe des jeweiligen Dreiecks liegen?! Damit das hinhaut, müsste man die modifizierten Tiefen wohl pixelweise berechnen und rausschreiben.

Nachtrag: Im Outerra-Blog findet sich hier ein wesentlich aktuellerer Post zum Thema, der auch auf die Interpolationsproblematik eingeht.

[Niki]

Bevor ihr alle losrennt, und eure z-Buffer umstellt: Der konservative depth output reaktiviert nur die Hierarchical-Z-, nicht aber Early-Z-Optimierungen.

Ich weiß nicht, in wie weit das stimmt, aber hier (http://mynameismjp.wordpress.com/2010/1 ... -features/) schreibt der Mann, dass die GPU weiterhin Early-Z benutzen kann, wenn man statt SV_Depth entweder SV_DepthLessEqual oder SV_DepthGreater nimmt.

Wenn man aber andererseits schon einen Z-Buffer in einem Gleitkommaformat benutzt, dann kann man near und far planes ohne Performanceverlust vertauschen und erhält eine bessere Tiefenverteilung; das ist also ein ziemlicher no-brainer, wenn man schon ein solches Format benutzt.

Ich benutze zwar Direct3D, aber es sieht wohl so aus, dass ein Vertauschen der Planes in OpenGL nix bringt, da -w < z < +w. Also ist die logarithmische Variante für OpenGL-User wohl die einzige Wahl, sofern man denn eine solche Wahl überhaupt treffen muss.

Zu Outerras / Nikis logarithmischen Tiefen im Vertex Shader: Ich bezweifle sehr stark, dass die Interpolation des projizierten Z-Wertes hier korrekte Tiefen liefert

Japp, das ist mir bekannt. Da muss noch Code in den Pixel Shader. Ich hatte in meiner ersten Post nur aus Versehen den falschen Link angegeben, und dann ein oder zwei Posts später den richtigen. Hast du wahrscheinlich nur übersehen (ist derselbe den du in deinem Nachtrag angegeben hast).

[Krishty]

Bevor ihr alle losrennt, und eure z-Buffer umstellt: Der konservative depth output reaktiviert nur die Hierarchical-Z-, nicht aber Early-Z-Optimierungen.

Ich weiß nicht, in wie weit das stimmt, aber hier (http://mynameismjp.wordpress.com/2010/1 ... -features/) schreibt der Mann, dass die GPU weiterhin Early-Z benutzen kann, wenn man statt SV_Depth entweder SV_DepthLessEqual oder SV_DepthGreater nimmt.

Verfasser:

My name is Matt, and I’m a graphics programmer for Ready At Dawn Studios

Verfasser von eXiles Grafik:

Nick Thibieroz (AMD) and Holger Grun (NVIDIA)

Bleibt dir überlassen, wem du lieber glaubst.

P.S.: Es ist eine Pest, dass diese Dokumente alle im PowerPoint-Format vorliegen. Echt mal, WTF?! Dass OpenOffice fürn Arsch ist weiß ich ja, aber zumindest PDF als de-facto-Standard könnte man benutzen …

[Niki]

Bevor ihr alle losrennt, und eure z-Buffer umstellt: Der konservative depth output reaktiviert nur die Hierarchical-Z-, nicht aber Early-Z-Optimierungen.

Ich weiß nicht, in wie weit das stimmt, aber hier (http://mynameismjp.wordpress.com/2010/1 ... -features/) schreibt der Mann, dass die GPU weiterhin Early-Z benutzen kann, wenn man statt SV_Depth entweder SV_DepthLessEqual oder SV_DepthGreater nimmt.

Verfasser:

My name is Matt, and I’m a graphics programmer for Ready At Dawn Studios

Verfasser von eXiles Grafik:

Nick Thibieroz (AMD) and Holger Grun (NVIDIA)

Bleibt dir überlassen, wem du lieber glaubst.

Mit "Ich weiß nicht, in wie wie das stimmt..." meinte ich nicht die Aussage von eXile, sondern die Aussage in dem von mir angegebenen Link. Klar habe ich mehr Vertrauen zu einer Aussage von nVidia oder AMD.

Letztendlich bleiben mir als D3D11-User aber sowieso nur drei Möglichkeiten: D24S8 logarithmisch, D32F_S8X24 reversed, oder D32F reversed in der Hoffnung, dass ich ohne Stencil auskomme. Die Reversed-Variante ist schöner, da ich hierfür keine Shader verändern muss. Aber da müsste ich mich entscheiden zwischen keinem Stencil-Buffer oder 64 Bit Depth-Stencil-Buffer. Ist beides irgendwie nicht schön.

EDIT:

P.S.: Es ist eine Pest, dass diese Dokumente alle im PowerPoint-Format vorliegen. Echt mal, WTF?! Dass OpenOffice fürn Arsch ist weiß ich ja, aber zumindest PDF als de-facto-Standard könnte man benutzen …

Und OpenOffice kann die PPSX-Datei scheinbar nicht öffnen, weshalb ich das nicht lesen kann ohne erst einen PowerPoint-Viewer zu installieren. Werde ich wohl nachher tun.

[Krishty]

Lässt die GPU intern tatsächlich 24 Bits ungenutzt? Ich könnte mir gut vorstellen, dass die erst angelegt werden, falls man den Puffer tatsächlich mappt. (Das ist jetzt aber keine rhetorische Frage.)

[Niki]

Zumindest Nick Thibieroz hat da was zu gezwitschert.... https://twitter.com/NThibieroz/status/2 ... 8388971520. Da fehlt mir aber irgendwie die Information von nVidia. Zu schade, dass man sowas twittern muss, wo doch ein PDF so viel einfacher zu finden ist.

[Krishty]

Das zeigt, dass es technisch möglich ist, die 24 ungenutzten Bits intern zu ignorieren. Dann würde es mich wundern, wenn Nvidia es nicht täte.

[Niki]

So... habe nun den Reversed Depth Buffer mit D32_FLOAT_S8X24_UINT richtig eingebaut. Klar, das ich in meinem ersten Versuch nichts gesehen habe, weil ich von LessEqual auf Greater, anstelle von Equal, gewechselt hatte. Das ist natürlich ein Problem wenn man einen Depth-Pre-Pass hat. Über den tatsächlichen Speicherverbrauch auf meiner nVidia GTX 590 kann ich nichts sagen. Performance-technisch merke ich jedoch keinen Unterschied. Ich denke ich lasse das jetzt einfach so.

[glassbear]

P.S.: Es ist eine Pest, dass diese Dokumente alle im PowerPoint-Format vorliegen. Echt mal, WTF?! Dass OpenOffice fürn Arsch ist weiß ich ja, aber zumindest PDF als de-facto-Standard könnte man benutzen …

Und OpenOffice kann die PPSX-Datei scheinbar nicht öffnen, weshalb ich das nicht lesen kann ohne erst einen PowerPoint-Viewer zu installieren. Werde ich wohl nachher tun.

Vielleicht mal ein Update davon machen. Hier oeffnet LibreOffice das alles problemlos :!:

[eXile]

Bevor ihr alle losrennt, und eure z-Buffer umstellt: Der konservative depth output reaktiviert nur die Hierarchical-Z-, nicht aber Early-Z-Optimierungen. [...] Um diesen Post noch etwas mit interessanten Sachen zu unterfuttern:[...]

Woher kommt das?

Dass der konservative depth output nicht die Early-Z-Optimierungen reaktiviert, liegt daran, dass man die Tiefenwerte im Pixelshader beliebig setzen kann, solange man die konservativen Bedingungen (beispielsweise SV_DEPTH_GREATER_EQUAL) einhält; ein Late-Z-Test ist somit immer notwendig, und ein Early-Z-Test könnte im Allgemeinen falsche Ergebnisse liefern.

Wo liegt der Unterschied zwischen Z-Cull und Early Depth?

Ich glaube, Z-Cull ist Nvidia-Slang (grün) für AMDs Hi-Z (rot). Ich hatte leider vergessen, die Quelle anzugeben. Siehe Krishtys Post. Auch noch einmal Dank dafür.

Wieso benutzen die bei UAVs und/oder konservativen Tiefen kein [earlydepthstencil]?

Kann man. Deswegen steht [earlydepthstencil] auch in einer anderen Zeile, nämlich über der Zeile, in welcher UAVs oder konservativer depth output angegeben sind. Wenn man [earlydepthstencil] angibt, landet man in jedem Falle ganz links.

Wieso nutzen die ausgerechnet im Standardfall [earlydepthstencil], wo ich eine Erkennung desselben vollautomatisch erwarten würde? Beziehen die sich ausgerechnet da auf Stenciloperationen?!

Nein, Zeilenumbrüche in den Zellen der Abbildung sind als logische Oder-Operation zu deuten. ;)

Die Frage ist eher, warum da ein „opaque primitves“ ganz links steht; das ergibt nun wirklich einfach keinen Sinn. :)

[CodingCat]

Dass der konservative depth output nicht die Early-Z-Optimierungen reaktiviert, liegt daran, dass man die Tiefenwerte im Pixelshader beliebig setzen kann, solange man die konservativen Bedingungen (beispielsweise SV_DEPTH_GREATER_EQUAL) einhält; ein Late-Z-Test ist somit immer notwendig, und ein Early-Z-Test könnte im Allgemeinen falsche Ergebnisse liefern.

Dass ein Late-Z-Test zusätzlich erforderlich ist, ist klar. Aber die konservative Bedingung wird doch genau dafür aufgestellt, dass durch die Bedingung definitiv verdeckte Geometrie bereits im Vorhinein ausgeschlossen werden kann. Eine Early-Z-Optimierung zusätzlich zum Late-Z-Test würde im Allgemeinen jedenfalls keine Fragmente fälschlicherweise ausschließen. Insofern erschließt sich mir der Aussagegehalt eines "deaktivierten Early-Z" nicht ganz - mir scheint eher, hier fliegen willkürlich gewählte Marketingbegriffe durcheinander, bei denen die Bedeutung überhaupt nicht mehr klar ist. Was sollten konservative Tiefen anderes bringen als ein vorzeitiges Ausschließen von Sichtbarkeit; unabhängig davon, ob es nun Hi-Z/Z-Cull oder Early-Z heißt?

Nachtrag: Dieses ATI-Papier kontrastiert Hi-Z und Early-Z als Low-Resolution-Tiled-Early-Z-Culling (hierarchischer Min-/Max-Buffer) und pixelgenauen Early-Z-Test, respektive. Verknüpft mit der von eXile exzerpierten Grafik heißt das wohl, dass ein pixelgenauer Early-Z-Test bei konservativen Tiefen nicht der Mühe wert war und in diesem Fall nur grobes tile-basiertes Early-Z-Culling durchgeführt wird.

Nachtrag 2: Jetzt habe ich auch endlich die entsprechende Quell-Powerpoint-Präsentation gesehen, die dies bestätigt. Mein Hauptproblem mit derlei Präsentationen ist übrigens nicht das Dateiformat, sondern die unglaubliche Streueung derselben sowie die oftmals extrem knappen und nichtssagenden Stichworte, nicht selten ohne jede weitere Erläuterung in den Notizen.

[CodingCat]

Ich benutze zwar Direct3D, aber es sieht wohl so aus, dass ein Vertauschen der Planes in OpenGL nix bringt, da -w < z < +w. Also ist die logarithmische Variante für OpenGL-User wohl die einzige Wahl, sofern man denn eine solche Wahl überhaupt treffen muss.

Die Clip Spaces sehen je nach API zwar leicht unterschiedlich aus, dennoch funktionieren beide analog. Bei OpenGl folgt nach der Projektion eben noch ein typisches Bias der Tiefenwerte von [-1, 1] auf [0, 1]. Tatsächlich erlaubt glDepthRange in der aktuellen OpenGl-API wie es aussieht sogar ein direktes Umkehren des Tiefenpuffers per State, ohne sonstige Eingriffe in den Render-Ablauf.

[eXile]

Eine Early-Z-Optimierung zusätzlich zum Late-Z-Test würde im Allgemeinen jedenfalls keine Fragmente fälschlicherweise ausschließen.

Ich glaube dann reden wir über unterschiedliche Dinge. So wie ich es verstanden habe, gibt es die ganzen drei Optimierungen (aus erstens Hi-Z/ZCull, zweitens early z-test und drittens late z-test) einmal als Test mit dem bestehenden Depth-Buffer, und einmal die letzten beiden (early z-test und late z-test) als Test mit anderen Fragmente "in flight" eines Pixels, der gerade berechnet wird. Beim ersten (dem Test mit dem Depth-Buffer) gibt es keine Probleme, da stimme ich dir voll und ganz zu. Beim zweiten (Test der in flight fragments) kann es sehr wohl Probleme geben. Wenn wir beispielsweise einen Pixel haben, auf dem zwei Fragmente gerade berechnet werden, und SV_DEPTH_GREATER_EQUAL annehmen, sieht die Situation ungefähr so aus:



A-priori kennen wir nur die iDepths und nicht die oDepths. Wir können keine der beiden Fragmente, die sich in-flight befinden, ausschließen, bevor wir nicht ihre oDepths kennen. D.h. der early z-test ist tatsächlich für die in-flight Fragments trotz konservativen depth output nicht zu gebrauchen, was sich mit der gleich folgenden Aussage „Because it relies on knowing actual fragment depth“ decken würde.

Nachtrag 2: Jetzt habe ich auch endlich die entsprechende Quell-Powerpoint-Präsentation gesehen, die dies bestätigt. Mein Hauptproblem mit derlei Präsentationen ist übrigens nicht das Dateiformat, sondern die unglaubliche Streueung derselben sowie die oftmals extrem knappen und nichtssagenden Stichworte, nicht selten ohne jede weitere Erläuterung in den Notizen.

Ja, diese Probleme habe ich auch. Aber wo deutet die Präsentation deren Faulheit Weglassen von Transistor-verschwendenden Tests an?

Ich habe nur gefunden:

• DX11 supports conservative depth output
• Allows programmer to specify that depth output will only be GREATEREQUAL or LESSEQUAL than current depth buffer depth
  • E.g. geometric decals, depth conversion etc.
• In this case EarlyZ is still disabled
  • Because it relies on knowing actual fragment depth
• But Hi-Z/ZCull can be leveraged for early acceptance or rejection

zusammen mit dem echt Bände sprechenden Kommentar „Conservative oDepth not well documented in DX11 API.“

So wie fast alles in der Computergraphik: Sobald man ins Metall schauen muss, ist alles ein rumstochern im Nebel. :?

Nachtrag: Erbitte Abtrennung der Posts durch Moderator. :3

Nachtrag: Für jeden, der hier tatsächlich PowerPoint benutzt: Man kann diese komischen PPSX-Dateien anständig anzeigen, indem man PowerPoint manuell startet, und dann Datei→Öffnen… wählt.

[Schrompf]

Ist abgetrennt ab Nikis initialem Freudenausruf. Den und den Folgebeitrag kopiere ich jetzt aber irgendwie nochmal in den Anti-Jammer-Thread rüber, sobald ich raushabe, ob und wie das geht.

[CodingCat]

So wie ich es verstanden habe, gibt es die ganzen drei Optimierungen (aus erstens Hi-Z/ZCull, zweitens early z-test und drittens late z-test) einmal als Test mit dem bestehenden Depth-Buffer, und einmal die letzten beiden (early z-test und late z-test) als Test mit anderen Fragmente "in flight" eines Pixels, der gerade berechnet wird.

Gibt es denn Anlass zur Vermutung, dass Pixel in-flight gegeneinander getestet werden? Von sowas habe ich bisher nirgends gelesen, habe mich allerdings auch nicht im Detail damit beschäftigt. Bisher ging ich davon aus, dass alle Tiefentests immer "atomar" gegen den bestehenden Z-Buffer stattfänden (atomar in dem Sinne, dass derlei Operationen pro Pixel sequenzialisiert würden).

Beim ersten (dem Test mit dem Depth-Buffer) gibt es keine Probleme, da stimme ich dir voll und ganz zu. Beim zweiten (Test der in flight fragments) kann es sehr wohl Probleme geben. Wenn wir beispielsweise einen Pixel haben, auf dem zwei Fragmente gerade berechnet werden, und SV_DEPTH_GREATER_EQUAL annehmen, sieht die Situation ungefähr so aus: [...]

Gegen vorläufige Tiefen in-flight zu testen ist ohne Frage unsinnig. Rein theoretisch weniger unsinnig wäre hingegen, konservative Eingabetiefen auch pixelweise gegen den bestehenden Tiefenpuffer zu testen ...

Ja, diese Probleme habe ich auch. Aber wo deutet die Präsentation deren Faulheit Weglassen von Transistor-verschwendenden Tests an?

... sofern es die Hardware zuließe und dies auch in der Praxis Gewinn brächte. Momentan wird nach Präsentation auf diese Weise nur das grobe Z-Culling vorgeschaltet, mehr findet sich dort dazu auch nicht.

[eXile]

Gibt es denn Anlass zur Vermutung, dass Pixel in-flight gegeneinander getestet werden? Von sowas habe ich bisher nirgends gelesen, habe mich allerdings auch nicht im Detail damit beschäftigt. Bisher ging ich davon aus, dass alle Tiefentests immer "atomar" gegen den bestehenden Z-Buffer stattfänden (atomar in dem Sinne, dass derlei Operationen pro Pixel sequenzialisiert würden).

Tja, da kann ich auch mit keiner Quelle antworten.

Moral von der Geschicht: Der Hierarchical-Z-Test Early-Z-Test ist bei konservativen Depth-Output deaktiviert (sagen die Slides), die Begründungen, warum das so ist, ergeben keinen Sinn, und es sind keine Gründe ersichtlich, warum man ihn nicht aktivieren könnte. ¯\_(ツ)_/¯

[CodingCat]

Moral von der Geschicht: Der Hierarchical-Z-Test ist bei konservativen Depth-Output deaktiviert (sagen die Slides), die Begründungen, warum das so ist, ergeben keinen Sinn, und es sind keine Gründe ersichtlich, warum man ihn nicht aktivieren könnte. ¯\_(ツ)_/¯

WAAS? Soweit gehen doch nicht mal die Slides, Hi-Z/Z-Cull ist laut Slides bei konservativem Depth-Output nach wie vor aktiviert. ;) Ganz sicher deaktiviert ist hingegen offensichtlich der pixelweise Early-Z-Test, d.h. Early-Z-Rejection passiert mit konservativem Depth-Output nur grob auf Tile-Basis.

[eXile]

Öhm, ja, genau das meinte ich. Sorry. Bin mal wieder durch den Wind und habs korrigiert. :oops:

[Krishty]

Die Erklärung wird ganz einfach sein:

Optimiert wird nur, was jeder macht.

Es gibt ganz ganz viele ganz ganz kluge Techniken mit denen sich Sachen klüger lösen lassen als bisher. Aber die sind trotzdem langsamer. Weil die Hersteller nur DIE Sachen optimieren, die OFT benutzt werden. Weil man begrenzte Ressourcen hat und nicht aus jeder Pipeline-Nische in jeder Situation alles rausholen kann sondern für häufige Situationen optimiert.

Conservative Z wird nicht oft benutzt. Es ist nicht einmal offiziell dokumentiert. Darum ist es langsam. So einfach ist das.

Egal, welche Gründe ihr dagegen findet. Weil die Welt ein Haufen Scheiße ist in dem gute Absichten und noch bessere Gründe einen Dreck bedeuten.