Depth-Test an oder aus?

[shadow]

Hallo ZFXler,

ich habe meinem 2D-Spiele-Framework, das bisher nur OpenGl 1 für PC unterstützt hat, gerade einen OpenGL ES 2.0-Renderer für Android spendiert und lese da immer viel bzgl. Performance-Problemen.

Überall wird empfohlen, statt mehrerer kleiner Texturen lieber wenige große Texturen zu verwenden und mit Texture-Atlas, also verschiedenen Sub-Bildern auf einer Textur, zu arbeiten. Die Performance-Engpässe scheinen wohl daher zu kommen, weil zu oft zwischen verschiedenen Texturen zu wechseln schlecht ist. Soweit noch kein Verständnis-Problem. Was ich mich allerdings gerade frage ist folgendes:

Bei meinem Framework ist der Depth-Test aktuell deaktiviert. d. h. das Bild baut sich in Zeichenreihenfolge auf. Ich habe vorher in anderen Frameworks schon auf diese Weise gearbeitet, deshalb habe ich mein eigenes Framework auch so konzipiert. Wenn ich jetzt den Depth-Test aktivieren würde, könnte ich Grafiken, die auf einer einzigen Textur liegen, sowohl für Hintergrund- als auch Vordergrund-Grafiken verwenden. Genau genommen müsste ich dann pro Render-Durchgang jede geladene Textur nur ein einziges mal ansprechen.

Konkrete Frage: Ist mein Denkansatz hier richtig, dass mir der Depth-Test einen Performance-Vorteil bringen müsste, weil sehr selten zwischen Texturen gewechselt werden muss? Oder ist ein aktiver Depth-Test noch Performance-kritischer?

Danke für Euer Feedback!

[Schrompf]

Ein Depth Test erhöht die Last auf dem Speicherbus, könnte also auf mobilen GPUs merklich langsamer sein. Probiere es aus :-)

Textur-Atlanten sind dagegen sehr wichtig. Du musst diese Optimierung allerdings nicht zu weit treiben. Weniger Texturwechsel sind eine gute Sache, sowohl auf PC als auch auf Mobil-Geräten. Aber der Hinweis ist primär an die Leute gerichtet, die noch mit D3DXSprite arbeiten oder ihr eigenes System haben, dass pro Grafik eine Winzig-Textur aufmacht. Bei diesen Systemen hast Du fast pro Sprite einen Texturwechsel, also viele hundert/tausend pro Frame. Das ist tödlich für die Performance. Mit Texturatlanten hast Du dagegen nur noch ein paar Dutzend Texturwechsel. Es macht dann fast keinen Unterschied mehr, ob Du da mittels DepthTest noch ein halbes Dutzend Wechsel einsparst. Die Hauptarbeit ist dann erledigt.

Meine Empfehlung zu diesem Thema also: entscheide nach Deiner internen Organisation, ob DepthTest Dir was bringt. Aus Performance-Gesichtspunkten hast Du getan, was nötig ist. Alles Weitere bringt nicht mehr viel.

[shadow]

Alles klar, danke für das Feedback! Ich werd Depth-Test erst mal aus lassen...

[Niki]

Schon einen Monat alt die Post. Hoffe es stört keinen wenn ich so spät noch meinen Senf dazu abgebe.

Die Antwort ist ein klares "Kommt drauf an!".

Wenn du viel Overdraw hast und deine Sprites ohne Grafikfehler von vorne-nach-hinten zeichnen kannst, dann sollte das Aktivieren des Depth-Buffer's schon ein klein wenig was bringen. Kommt halt auf die Overdraw-Menge an.

Sehr viel kann es bringen, wenn du komplexe Fragment-Shader benutzt, die pro Pixel wesentlich teurer sind als ein Tiefentest.

Aber wie gesagt, das ist auch eine Frage des "Könnens", denn wenn deine Sprites Alphamasken haben und sich teilweise mit dem Hintergrund vermischen, dann ist das Zeichnen von vorne nach hinten nicht mehr ganz so einfach.

[shadow]

Klar gerne!

Was bedeutet "ohne Grafikfehler von vorne-nach-hinten zeichnen" ?
Shader benutz ich aktuell gar nicht. Die eine Implementierung ist OpenGL1, die andere OpenGL ES 2.0 für Android, und hier nur Shader für die Texturen, also textured quads.

Überhaupt benutz ich lediglich Unmengen an Sprites, also PNGs mit Alpha...

[Niki]

Was bedeutet "ohne Grafikfehler von vorne-nach-hinten zeichnen" ?

Momentan hast du den Depth-Buffer ja deaktiviert. Daraus schließe ich, dass du deine Grafiken "von hinten nach vorne" zeichnet. Als Beispiel stell dir einen 2D Side-Scroller vor. Erst zeichnest du den Himmel ganz weit "hinten". Danach zeichnest du Berge über den bereits gezeichneten Himmel. Die Berge sind also optisch weiter "vorne" (näher an deinem Auge). Als nächstes zeichnest du dann vielleicht eine Straße noch weiter "vorne". Und schlussendlich zeichnest du auf die Straße ein Auto mit halbtransparenten blauen Fenstern. Du hast diese Szene jetzt von "hinten nach vorne gezeichnet". Durch die halbtransparenten Fenster des Autos siehst du was an der Stelle im Hintergrund ist (Straße, Berge, Himmel) - alles bläulich eingefärbt, da unsere Beispielfenster blau sind.

Nun stell dir vor du zeichnest in der umgekehrten Reihenfolge, also "von vorne nach hinten" (mit aktiviertem Depth-Buffer und Alpha-Testing). Deine halbtransparenten Autofenster werden also gezeichnet bevor der Hintergrund gezeichnet wird. Resultat ist eine blaue Fensterscheibe durch die du den Hintergrund nicht sehen kannst --> ein Grafikfehler.

EDIT: Auf mobilen Geräten solltest du ein "von vorne nach hinten"-Zeichnen mit Alpha-Testing nicht blind einsetzen ohne die Performance-Unterschiede gründlich zu testen. Auf iOS, z.B., sind Alpha-Testing und Sortieren eine schlechte Idee. Siehe hierzu: http://developer.apple.com/library/ios/ ... mance.html

[Niki]

Ich habe noch mal ein wenig gegoogelt um mehr über Android zu erfahren. Es sieht wohl so aus, dass Alpha-Testing (oder die "discard" Instruktion) auf einigen Geräten keine Probleme macht, während auf anderen Geräten die Performance hops geht. Also besser nicht benutzen, wenn's ohne geht.

Auch habe ich was bei nVidia gefunden, für Devices die einen Tegra Grafikchip haben: http://docs.nvidia.com/tegra/data/Optim ... Tegra.html

Tegra can reject fragments via depth-testing at a very high rate. As a result, applications that can render opaque parts of a scene, even roughly front-to-back with depth testing enabled, can see a performance improvement. This is especially true if possibly-occluded objects with expensive fragment shaders can be drawn last.

If the application uses particularly complex fragment shaders with a large amount of overdraw, then even if front-to-back sorting is not feasible, the application can see higher performance using an initial depth-only rendering pass with the color buffer masking set to GL_FALSE. It is important that for the depth-only pass all unnecessary load is removed from the vertex shader, otherwise the prepass is likely to be (unnecessarily) geometry limited.

[shadow]

Also besser bei "von hinten nach vorne" bleiben, mit deaktiviertem Depth-Test? Das mit den Grafikfehlern war mir bisher gar nicht so bewusst... ich dachte das wird schon alles so passen dann :D

[Niki]

Also besser bei "von hinten nach vorne" bleiben, mit deaktiviertem Depth-Test?

Das lässt sich leider nicht so einfach beantworten, da es von deinem Spiel abhängt. Wenn du viel Overdraw durch Sprites hast die keinerlei Transparenz haben, dann würde ich den Depth-Buffer aktivieren, danach die nicht-transparenten Sprites ungefähr von vorne nach hinten zeichnen, und danach transparente Sprites mit Alpha-Blending von hinten nach vorne. Hast du aber diesen Overdraw durch nicht-transparente Sprites nicht, dann würde ich wahrscheinlich ohne Depth-Buffer von hinten nach vorne zeichnen, da dann sowie fast jedes Sprite Alpha-Blending braucht (bis auf die nicht-transparenten Elemente die eventuell den Hintergrund ohne Overdraw bilden).

[shadow]

Ganz schön kompliziert :)

In meinem Fall handelt es sich auch nicht im ein konkretes Spiel, sondern eine Framework, mit dem ich verschiedene Spiele baue... Ich weiß jetzt auch nicht, wie ich die Sache angehen soll. Momentan funktioniert ja alles, ohne Depth-Test. Aber als dann Diskussionen über Performance aufkamen, und möglichst wenige Textur-Wechsel, da dachte ich, weniger Textur-Wechsel könnte ich mit aktiviertem Depth-Text erreichen. Aber selbst das ist ja auch noch nicht gesagt...

[Niki]

Ganz schön kompliziert :)

Ja! Also erst mal zusammenfassen.

Die erste Feststellung ist, dass Alpha-Testing (bzw. discard) keine gut Idee sind. Somit müssen alle Grafiken, die einen Alphakanal benutzen per Painter's Algorithmus gezeichnet werden(heißt von hinten nach vorne). Diese Aussage ist sicherlich nicht 100% korrekt, da zwei Sprites sich nicht notwendigerweise auf dem Bildschirm überlappen. Aber ich glaube das sollte man hier mal komplett ignorieren.

Die zweite Feststellung ist, dass i.d.R. in die meisten Grafiken einen Alphakanal haben. Ausnahmen sind meist nur Grafiken, die "ganz hinten" im Bild auftreten.

Beide Feststellungen zusammen bedeuten dann, dass der Depth-Buffer keine Pixel eliminieren kann und auch nicht wirklich zur korrekten Zeichenreihenfolge beiträgt (es sei denn du hast vor 3D Modelle in deiner 2D Welt darzustellen, was bei dir wohl nicht der Fall ist).

Fazit: Ohne Depth-Buffer mit Painter's Algorithmus zeichnen, so wie du es jetzt schon tust.

Die eigentliche Frage ist dann: "Wie minimiere ich die Anzahl der Texturwechsel und halte die Batches möglichst groß?". Das ist entweder leicht oder schwer, wobei ich jetzt natürlich davon ausgehe, dass deine gesamte Grafik nicht in einen einzigen Textur-Atlas passt.

Bei einem typischen Jump'n Run oder Shoot'em Up mit eventuellem Parallax-Scrolling ist es eher leicht. Da hast du mehrere übereinanderliegende Ebenen und weißt im Voraus, dass bestimmte Grafiken nur in bestimmten Ebenen auftreten. Da kann man seine Textur-Atlanten dann entsprechend der Ebenen anlegen. Das resultiert fast automatisch in einer geringen Menge an Texturwechseln.
Anders sieht das bei einem Isometrie-Spiel aus, wo die Bäume des Waldes an quasi beliebigen Positionen auftreten können. Wenn man mal vom Boden absieht wüsste ich aus dem Stehgreif nicht, wie ich da ohne komplexere Algorithmen die Texturwechsel minimieren würde.

Allerdings scheint mir eine generelle Unterteilung in Z-Ebenen sinnvoll zu sein. Beim Parallax-Spiel hast du viele solcher Ebenen (Viele Hintergrund-Parallaxebenen, eine "Spielebene" mit Monstern etc., und wenige Vordergrund-Parallaxebenen). Beim Isometrie-Spiel hast du nur wenige davon (Bodenebene, Isometrieebene, HUD-Ebene).

[shadow]

Super, danke für die ausführliche Erklärung!

Ok, bei Painter's Algorithmus bleiben! Das passt mir eh gut...

Das mit dem Jump'n'Run vs. Isometrie leuchtet mir auch ein... Da es es sich bei dem Projekt um ein Framework statt um die konkrete Implementierung eines Spiels dreht, muss ich hier noch bisschen Gehirnschmalz reinstecken. Zumindest ist es mir jetzt viel klarer. Danke nochmals dafür!

VG Stefan