Tiefentest: Unterschied zwischen den Versionen
() |
|||
| Zeile 1: | Zeile 1: | ||
| − | Wenn im letzten Schritt der Grafikpipeline die 3D-Szene in den Framebuffer gerendert wird, muss OpenGL feststellen können, welche Teile der Grafik im Vordergrund stehen und welche Objekte ganz oder teilweise durch andere Objekte verdeckt werden. | + | Wenn im letzten Schritt der Grafikpipeline die 3D-Szene in den Framebuffer gerendert wird, muss OpenGL feststellen können, welche Teile der Grafik im Vordergrund stehen und welche Objekte ganz oder teilweise durch andere Objekte verdeckt werden. |
| + | |||
| + | == Funktionsweise == | ||
| + | Für den Tiefentest existiert der [[Tiefenpuffer]]. Dieser ist genauso gross wie der Framebuffer. Für jeden Pixel auf dem Bildschirm gibt es dann also einen weiteren Wert - den Eintrag im Tiefenpuffer. | ||
| + | |||
Im ersten Schritt wird der gesamte Tiefenpuffer auf den größtmöglichen Wert initialisiert (also die maximale Distanz). | Im ersten Schritt wird der gesamte Tiefenpuffer auf den größtmöglichen Wert initialisiert (also die maximale Distanz). | ||
| − | Sobald dann ein Objekt gerendert wird, wird für jeden Pixel überprüft, ob der Tiefenwert des Pixels dieses Objekts kleiner ist als der Wert im Tiefenpuffer. Ist dies der Fall, wird | + | Sobald dann ein Objekt gerendert wird, wird für jeden Pixel überprüft, ob der Tiefenwert des Pixels dieses Objekts kleiner ist als der Wert im Tiefenpuffer. Ist dies der Fall, wird dieses Pixel in den Framebuffer gezeichnet und der Tiefepuffer aktualisiert, ansonsten wird es verworfen. Der Test kann mittels [[glDepthFunc]] auch abgeändert werden. Zum Beispiel kann man dafür sorgen, dass auch gleich große Tiefenwerte akzeptiert werden. |
| + | |||
| + | |||
| + | == Nachteile == | ||
| + | Da der Tiefentest für jedes Fragment (auch für jene die nicht dargestellt werden) durchgeführt werden muss, ist der Tiefentest zwar eine exakte (auf Pixel basis) und einfache, jedoch inperformante Methode um zu verhindern, dass Objekte die hinter anderen Objekten stehen dennoch angezeigt werden. Jedoch muss bei dieser Methode (im Gegensatz zu den Alternativen) keine Tiefensortierung der 3ecke erfolgen. Es spielt bei der Verwendung des Tiefentests also keine Rolle, in welcher Reihenfolge die Objekte an die 3D-Pipeline übergeben werden. (Performantere Methoden findet man unter [[Techniken_und_Algorithmen#Raumunterteilungstechniken|Raumunterteilungstechniken]].) | ||
| − | |||
| − | + | == Transparenz und Tiefentest == | |
| + | Sobald Transparenz verwendet wird, kann der Tiefentest zumindest für diese Teile nicht mehr benutzt werden. Dies würde zu Fehlern führen, da das transparente Fragment ggfs. das durchscheinende, jedoch erst später an die Grafik-Pipeline gesendete und somit vom Tiefentest verworfene Fragment dahinter völlig verbirgt. Wenn man Transparente Fragmente nicht in den Tiefenbuffer schreibt, so können diese Fragmente von anderen, eigentlich weiter hinten liegenden, Fragmenten komplett überschrieben werden.<br> | ||
Aus diesem Grund sollten Transparente Objekte nach allen anderen Objekten an OpenGL geschickt werden und diese möglichst von hinten nach vorne sortiert sein. Das Sortieren kann durch einen Alpha Wert im [[Framebuffer]] umgangen werden, jedoch ist dieser nur selten in Hardware vorhanden, wodurch in den weit langsameren Softwaremodus gewechselt wird. | Aus diesem Grund sollten Transparente Objekte nach allen anderen Objekten an OpenGL geschickt werden und diese möglichst von hinten nach vorne sortiert sein. Das Sortieren kann durch einen Alpha Wert im [[Framebuffer]] umgangen werden, jedoch ist dieser nur selten in Hardware vorhanden, wodurch in den weit langsameren Softwaremodus gewechselt wird. | ||
Version vom 21. Juni 2005, 15:05 Uhr
Wenn im letzten Schritt der Grafikpipeline die 3D-Szene in den Framebuffer gerendert wird, muss OpenGL feststellen können, welche Teile der Grafik im Vordergrund stehen und welche Objekte ganz oder teilweise durch andere Objekte verdeckt werden.
Funktionsweise
Für den Tiefentest existiert der Tiefenpuffer. Dieser ist genauso gross wie der Framebuffer. Für jeden Pixel auf dem Bildschirm gibt es dann also einen weiteren Wert - den Eintrag im Tiefenpuffer.
Im ersten Schritt wird der gesamte Tiefenpuffer auf den größtmöglichen Wert initialisiert (also die maximale Distanz). Sobald dann ein Objekt gerendert wird, wird für jeden Pixel überprüft, ob der Tiefenwert des Pixels dieses Objekts kleiner ist als der Wert im Tiefenpuffer. Ist dies der Fall, wird dieses Pixel in den Framebuffer gezeichnet und der Tiefepuffer aktualisiert, ansonsten wird es verworfen. Der Test kann mittels glDepthFunc auch abgeändert werden. Zum Beispiel kann man dafür sorgen, dass auch gleich große Tiefenwerte akzeptiert werden.
Nachteile
Da der Tiefentest für jedes Fragment (auch für jene die nicht dargestellt werden) durchgeführt werden muss, ist der Tiefentest zwar eine exakte (auf Pixel basis) und einfache, jedoch inperformante Methode um zu verhindern, dass Objekte die hinter anderen Objekten stehen dennoch angezeigt werden. Jedoch muss bei dieser Methode (im Gegensatz zu den Alternativen) keine Tiefensortierung der 3ecke erfolgen. Es spielt bei der Verwendung des Tiefentests also keine Rolle, in welcher Reihenfolge die Objekte an die 3D-Pipeline übergeben werden. (Performantere Methoden findet man unter Raumunterteilungstechniken.)
Transparenz und Tiefentest
Sobald Transparenz verwendet wird, kann der Tiefentest zumindest für diese Teile nicht mehr benutzt werden. Dies würde zu Fehlern führen, da das transparente Fragment ggfs. das durchscheinende, jedoch erst später an die Grafik-Pipeline gesendete und somit vom Tiefentest verworfene Fragment dahinter völlig verbirgt. Wenn man Transparente Fragmente nicht in den Tiefenbuffer schreibt, so können diese Fragmente von anderen, eigentlich weiter hinten liegenden, Fragmenten komplett überschrieben werden.
Aus diesem Grund sollten Transparente Objekte nach allen anderen Objekten an OpenGL geschickt werden und diese möglichst von hinten nach vorne sortiert sein. Das Sortieren kann durch einen Alpha Wert im Framebuffer umgangen werden, jedoch ist dieser nur selten in Hardware vorhanden, wodurch in den weit langsameren Softwaremodus gewechselt wird.
