[DX9] Ärger mit dem Z-Buffer

[ponx]

Hallo zusammen,
Ich will in meinem Spiel über meine 3D-Szene einige transparente Billboards zeichnen (Wolken, Explosionen). Die sind näher an der Kamera, und man sollte also die Objekte da also durchschimmern sehen. Das klappt auch grundsätzlich schön, solange ich den Z-Buffer ausschalte, nur sobald ich ihn aktiviere, krieg ich Probleme: Ein Teil der Modelle wird noch per als .x Meshes gezeichnet, die flackern heftig, sobald sie unter einem Billboard liegen. Auch wenn ich die Kamera ein bisschen gedreht habe, flackern die Modelle "in sich" irgendwie komisch, also es gibt kleine Clipping-Fehler. Der andere Teil der Modelle wird mit Assimp gerendert, und da flackert zwar nichts, allerdings werden die auch nicht mit den Billboards übermalt. Stattdessen sieht es so aus, als würden die Modelle über den Wolken liegen.
Ich hab jetzt schon mit SetRenderState(D3DRS_ZWRITEENABLE, D3DZB_FALSE); rumexperimentiert, und immerhin flackern die Billboards jetzt nicht mehr, wenn sie übereinader liegen. Nur die Modelle krieg ich nicht in den Griff. Das Flackern ist dabei von der Zoom-Stufe der Kamera abhängig: je nach Kamera-Abstand gucken andere Polygone durchs Billboard durch.
Mein AutoDepthStencilFormat hab ich auf D3DFMT_D16, muss da vielleicht was anderes hin ?
vielen Dank schonmal für eure Mühe !

andy / ponx

[Zudomon]

D3DFMT_D16 sollte reichen.
Die transparenten Billboards solltest dann mit deaktiviertem ZWrite zeichnen. Und das wichtigste, die musst du ganz zum Schluss rendern. Vielleicht löst das schon das Problem.

[ponx]

hallo und danke Sudo! Die Billboards zeichne ich schon mit deaktiviertem ZWrite, und die Reihenfolge stimmt auch. Gibts sonst noch irgendwelche Einstellungen ? Oder kann ich beim Rendern der (Assimp-)Modelle irgendwie schon was verpfuschen, was sodass dann später nicht mehr richtig überpinselt werden kann ?

[Zudomon]

Mit Assimp selbst kenne ich mich nicht aus, aber hier wird es einige geben, die dir diese Frage beantworten können.

Könntest du mal einen Screenshot von dem Fehler machen?

[Krishty]

Hi,

Auf welchen Entfernungen liegen Near- und Far-Clipping-Plane? Backface-Culling aktiviert? Welcher Öffnungswinkel der Kamera? Wie Zudomon schon frage, würdest du Screenshots posten?

Gruß, Ky

[ponx]

Es klappt !! (party)
das mit der Near- und Far View Pane war der entscheidende Tipp ! Ich hatte die Near View Pane irgendwann auf 0.0f gestellt, weil ansonsten nichts gerendert wurde.. und das hat wohl die Grafikfehler verursacht (so sahen sie aus). Das eigentliche Problem war, dass meine Far View Pane mit 100.0f viel zu knapp bemessen war. Hab wohl irgendwie meine Skala aus den Augen verloren...

Danke Krishty, danke Zudo, ihr habt mir mal wieder den Tag gerettet !
cheers,
ponx

[Zudomon]

So weit ich weiß, wird ja durch das Nearplane geteilt... also wäre 0 ziemlich tötlich... wichtig ist demnach die Anzahl der Dekaden... also 0.01 - 100 ist dann das gleiche wie 0.1 - 1000. Kommt dann ebend drauf an, wie die Geometrie skaliert ist.

[Krishty]

Ja, mit 0.0 schaltet man Depth-Buffering quasi aus (bzw. macht es unbrauchbar).

Das mit den Dekaden zieht u.a. nach sich, dass man für bessere Z-Präzision zuerst darüber nachdenken sollte, die Near-Clipping-Plane ein paar Zentimeter wegzuschieben – das bringt dann genauso viel Präzision wie das Bewegen der Far-Clipping-Plane um ein paar hundert oder gar tausend Meter. Indem man kontrolliert, wie nah und fern man die Planes tatsächlich braucht (umliegende Objekte analysieren) kann man sogar mit relativ niedriger Z-Buffer-Auflösung viel abdecken.

In Zeiten von 32-Bit-Gleitkomma-Z-Buffern wird das aber immer nebensächlicher und damit das Rendern einfacher :)

[Zudomon]

Man könnte noch die Aufteilung dynamisch machen, indem man einfach bei jedem Fame entscheidet, wie weit die weitesten Objekte und wie nah die nahsten liegen. So hätte man eigentlich immer am besten ausgenutzt. Das man mal den Nearplane nahe braucht kommt ja selten vor.

Eine weitere Methode wäre noch, die Szene in 2 Regions aufzuteilen. Und dann doppelt rendern. Einmal die entfernten Objekte, einmal die Nahen. Die Objekte, die in beide Regions eintauchen einfach 2 mal zeichnen. Dadurch kann man dann schon ziemlich endlose Landschaften zeichnen.

[Krishty]

Man muss aber auch beachten, dass die Objekte in sich selbst Overdraw haben … oder auf Distanz möglichst Overdraw-freie LoDs zur Verfügung stellen. Wenn man die Objekte ganz weit weg noch ohne Z-Fighting haben will, muss man die Far-Clipping-Plane üblicherweise noch weiter hinten platzieren, damit die Objekte in Z-Bereiche mit ausreichender Auflösung rutschen … da wird es dann komplex, wie ich gerade bemerke :D

Am besten wird das immernoch ein Mensch beurteilen können, also könnte man die Planes ja auf per-Sektor-Basis vom Artist vorschreiben lassen. Der muss sich ja eh um Nebel etc. kümmern.

[dv]

Ebenfalls zu beachten ist, dass es möglich ist, die Far-Plane ganz loszuwerden, bzw. sie ins unendliche zu verschieben. Gewöhnliche Projektionsmatrizen projizieren einen Ausschnitt der Szene in einen Würfel. Durch w dividiert kriegt man Koordinaten im Würfel, der von x -1 y -1 z -1 bis x 1 y z 1 reicht (bei Direct3D ist das erste z nicht -1, sondern 0). Alles ausserhalb dieser Post-Projection-Koordinaten wird geclippt. Bei den Z-Tiefen gibt es ebenfalls einen Punkt, ab dem z >= 1 ist, das ist die Far Plane. Es gibt Projektionsmatrizen, die z auf eine asymptotische Funktion mappen, d.h. z wird nie >= 1, und die Far Plane ist somit "im Unendlichen". Eine Beschreibung dieser Matrix gibt es in diesem Paper: http://developer.nvidia.com/object/robu ... lumes.html auf Seite 4. (Achtung, die Matrix da ist für OpenGL, da z auf [-1, 1] bzw. [-w, w] gemappt wird!)

[Stefan Zerbst]

Ja, mit 0.0 schaltet man Depth-Buffering quasi aus (bzw. macht es unbrauchbar).

[klugscheiß :twisted: ]
Nein. Korrekt ist, dass bei allen Standard-Matrizen zur perspektivischen Projektion mit zn in der dritte Spalte der vierten Zeile multipliziert wird. Folglich erzeugt man sich durch Setzen von zn auf 0 an dieser Stelle der Matrix auch eine 0 was eben für unbrauchbare Werte im Ergebnis sorgt. Bei der orthogonalen Projektion ist so etwas dagegen vollkommen legal und führt zu dem gewünschten Ergebnis.

Siehe auch http://msdn.microsoft.com/en-us/library ... S.85).aspx :)

[/klugscheiß :roll: ]