OpenGL Stencil-Buffer: Warum 8 Bit und nicht nur 1 Bit?



  • Nabend,
    nur eine kleine Frage!
    Ich bin jetzt mal auf den Stencil-Buffer gestoßen. So wie ich das verstehe, dient er als Maske, bzw. Schablone, wie der Name schon sagt...
    Aber wozu braucht er dann 8 Bit?
    Schablone bedeutet für mich eher ja, oder nein, was das Zeichnen angeht. Irgendwie bin ich, wie es aussieht, noch nicht auf die richtigen Beispiele gestoßen.
    Also kann mir jamand evtl. das eine oder andere Beispiel für einen 8-Bit-Stencil-Buffer nennen!?

    Gruß
    OpenGL-Fifi



  • OpenGl-Fifi schrieb:

    Also kann mir jamand evtl. das eine oder andere Beispiel für einen 8-Bit-Stencil-Buffer nennen!?

    Paradebeispiel: Shadow Volumes
    Dabei wird das vom Licht geblockte Volumen aus Dreiecken gebaut, gerendert und dabei der Stencil Buffer verwendet, um zu zählen, wie oft ein Sichtstrahl das Volumen schneidet, bevor er auf ein Objekt trifft. Ist diese Anzahl gerade, ist der Punkt im Licht, ansonsten im Schatten...

    Edit: Eigentlich könnte das sogar mit einem 1 Bit Buffer klappen, wenn ich nicht grad was übersehe. Triviales Beispiel ist dann halt z.B. zum Zwecke von Profiling den Grad an Overdraw pro Pixel bestimmen...



  • Ja, für Stencil-Shadows braucht man nur 1 Bit.


  • Mod

    Stencilbuffer kam auf um tatsaechlich zeichnen mit schablonen zu simulieren. Bei einer schablone zeichnest du halt nur dort, wo die schablone nicht ist, im umkehrschluss bedeutet das, dass du alle flaechen mit schablone drueber unveraendert lassen kannst (also nicht neuzeichnen musst). Du konntest also z.b. Menues deines editierprogrammes lassen wie sie sind und hast jedes frame nur die 3d ansichten neuzeichnen.

    wieso konnte man sie lassen, bei doublebuffering geht das bild doch eh verloren?
    -frueher hattest du nicht wirklich den luxus des doublebufferings, bei zeichenprogrammen war es sogar gaengig dass du gesehen hast wie gezeichnet wurde, du hast also in denselben buffer gezeichnet, again and again. z.b. https://www.youtube.com/watch?v=BayZZQFFO_s

    Wieso nicht einfach im zbuffer die tiefe fuer menues auf 0 setzen?
    -es gab keinen zbuffer (zuviel speicherverbrauch und langsam). man kam drumherum indem nur wireframe gezeichnet wurde, manchmal bei solid flaechen wurde der [url=http://en.wikipedia.org/wiki/Painter's_algorithm]painter algorithmus[/url] verwendet und wenn du es richtig aufwendig wolltest, haben manche programme den scanline algorithmus verwendet.

    Schlussendlich ist denke ich es ziemlich offensichtlich weshalb gerade 8bit. Du kannst ja mehr als eine schablone uebereinander legen. z.B. bei einem flugsimulator wo du die 3d ansicht hinten hast, davor das cockpit wo du instrumente neuzeichnen kannst wenn noetig und davor steuerknueppel und davor menues etc.



  • Ah, Danke für die Anekdoten.
    Noch eine Frage an dot: Was ist "zum Zwecke von Profiling den Grad an Overdraw pro Pixel bestimmen" ??? Ähhhh...

    Naja als erstes dachte ich auch an Volumen-Schatten, wo man eigentlich, solange es keinen Überlauf, oder komplexere Figuren gibt, mit einem Bit auskommen sollte..
    Und auch das Zeichnen von Cockpits usw. müsste mit nur einem Bit machbar sein.

    Also wenn ich das richtig sehe, sind die 8 Bit sozusagen nur Luxus, damit man den Puffer nicht jedes Mal löschen muss, bzw. um nicht alles von der CPU berechen zu lassen.. Oder sehe ich das falsch?!

    Kennt denn wer Beispiele für die Zweckentfremdung des Puffers?? Nur weil er so heißt, muss man ihn ja nicht ausschließlich so verwenden..



  • ..Nettes Video. Das sieht doch garnicht mal so schlecht aus. Zumindest besser als es klingt. Hört sich so an, als hätte mein Lautsprecher nen Wackelkontakt...



  • OpenGl-Fifi schrieb:

    Kennt denn wer Beispiele für die Zweckentfremdung des Puffers?? Nur weil er so heißt, muss man ihn ja nicht ausschließlich so verwenden..

    Hat dot ja schon erwähnt: Overdraw bestimmen.

    OpenGl-Fifi schrieb:

    Noch eine Frage an dot: Was ist "zum Zwecke von Profiling den Grad an Overdraw pro Pixel bestimmen" ??? Ähhhh...

    Als "Overdraw" bezeichnet man es wenn man ein und den selben Pixel mehrfach zeichnet.
    Wobei mit "mehrfach zeichnen" entweder gemeint sein kann:
    A) Man zählt nur als Overdraw wo wirklich der Pixel-Shader mehrfach ausgeführt werden muss, weil mehrere Z-Tests positiv ausgefallen sind. Das ist denke ich die übliche Definition, bzw. der interessantere Wert, da der Z-Test meist ziemlich billig ist, und der Pixel-Shader meist eher teuer.
    😎 Man zählt alles was der Rasterizer raushaut als Overdraw, egal ob der Pixel-Shader laufen muss oder nicht.

    Der Wert ist logischerweise interessant, weil viel Overdraw = viel langsam. Für nix. Weil das Bild ja dadurch nicht schöner wird dass man erst eine total sinnlose Farbe für einen Pixel berechnet hat, die danach wieder deckend überschrieben wird.
    (Bei halbtransparentem Überschreiben ist es natürlich nicht sinnlos, aber Performance kostet es dennoch - sogar mehr als wenn man deckend überschreibt.)

    Jetzt stellt sich die Frage wie man draufkommen kann wie viel Overdraw man hat.
    Und da ist eben eine Möglichkeit den Stencil-Buffer mit glStencilOp(GL_KEEP, GL_KEEP, GL_INCR) zu verwenden. Also Stencil-Buffer inkrementieren wenn der Z-Test positiv war.

    Vor dem Rendern setzt man alle Pixel im Stencil-Buffer auf 0, dann rendert man mit glStencilOp(GL_KEEP, GL_KEEP, GL_INCR) und deaktiviertem Stencil-Test, und zum Schluss holt man sich den ganzen Stencil-Buffer, und bildet den Mittelwert.

    Schwupps und schon hat man den Overdraw-Faktor des Frames ermittelt.

    Damit man da halbwegs sinnvolle Werte bekommt, braucht man natürlich auch deutlich mehr als nur 1 Bit im Stencil-Buffer.


  • Mod

    OpenGl-Fifi schrieb:

    Also wenn ich das richtig sehe, sind die 8 Bit sozusagen nur Luxus, damit man den Puffer nicht jedes Mal löschen muss, bzw. um nicht alles von der CPU berechen zu lassen.. Oder sehe ich das falsch?!

    wie wuerdest du das ohne 8 bit stencilbuffer sonst machen?


Log in to reply