Tiefentest: Unterschied zwischen den Versionen
(Verweis auf glDepthFunc) |
|||
Zeile 6: | Zeile 6: | ||
Hinweis: 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 durch die transparenz eigentlich 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> | Hinweis: 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 durch die transparenz eigentlich 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 [[ | + | 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, 13:23 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. Zu diesem Zweck wird ein Tiefenpuffer angelegt, der genauso gross wie der Framebuffer ist. 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 dieser Pixel in den Framebuffer gezeichnet, ansonsten wird er 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.
Da der Tiefentest für jedes Fragment (auch für die 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.
Hinweis: 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 durch die transparenz eigentlich 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.