ZFX + Developia

Ahoi,

ich habe da mal wieder ein Problem. Ich versuche gerade ALPHA_TO_COVERAGE for unsortierte Transparenz an den Start zu bekommen. Die folgende OpenGL Demo habe ich dazu gefunden und auch korrekt am Laufen http://www.codesampler.com/oglsrc/oglsr ... ansparency nachdem ich 4xAA im Control-Panel aktiviert habe. Wenn ich aber versuche das in einem größeren Projekt zum Laufen zu bekommen wird die Transparenz einfach vollkommen ignoriert. Der Kontext über WGL ist mit Multisampling mit 4 Samples geholt wie in dem Beispiel.

Der einzige Unterschied den ich noch als solchen wahrnehme ist, dass ich einen FBO mit DEPTH_STENCIL und multiplen Color Attachments verwende. Kann das zu Problemen führen? Gibt es noch andere glStates die falsch gesetzt sein können, so dass die Transparenz nicht ankommt?

Ciao,
Stefan

Multisampling geht bei FBO's mit mehreren Color Attachments nicht soweit ich weiß. Ich habe alpha to coverage auch schon verwendet, allerdings nur im backbuffer und da gings einwandfrei. Es bleibt dir noch eine chance und zwar die extension EXT_framebuffer_multisample: http://www.opengl.org/registry/specs/EX ... sample.txt

MFG Ingrater

Danke das ist doch schon mal ein Hinweis :)

Da werde ich wohl morgen mal etwas mit spielen und schauen ob ich das zum Laufen bewegen kann.

Ciao,
Stefab

Argh!

Es sieht wohl so aus, als ob man an einen Multisample FBO keine Texture als Color-Attachment anhängen könnte. Ich müsste also in einen Render-Buffer rendern. Bekomme ich den Inhalt dieses Buffers dann relativ schmerzfrei (lies: SCHNELL) in eine Textur? Das Problem ist, dass wir die Color-Attachments an unserem FBO noch für diverse Dinge performancekritisch als Texturen einsetzen. Was nützt mir ein Multisample FBO wenn ich damit nicht arbeiten kann? :o

Hat jemand schon mal Multisample FBO ausprobiert und kann mir ein paar Hinweise geben? Die offizielle Dokumentation zu dem Kram ist ja eher theoretischer Natur :|

Ciao,
Stefan

Ich glaube allgemein ist das nicht so das ware, sonst gäbe es ja deferrend renderer mit gescheitem anti aliasing...

Ingrater hat geschrieben:Ich glaube allgemein ist das nicht so das ware, sonst gäbe es ja deferrend renderer mit gescheitem anti aliasing...

S.T.A.L.K.E.R. Clear Sky? Ich würde tippen, dass es ab D3D 10.1 möglich ist, aber sicher weiß ich das nicht ... d.h. selbst wenn das möglich ist und es eine Extension dafür gibt, kann man es auf Nvidia-Karten knicken.

Hi,

es geht hier ja um OpenGL und FBO. Ich habe aber geraade mit Erschrecken festgestellt, dass allein das Aktivieren von 4x AA die Framerate von 13 auf 4 killt noch bevor ich überhaupt etwas mit Alpha2Coverage anfange.

Ciao,
Stefan

Alpha to Coverage braucht viel Power. So wies aussieht geht das mit dem FBO Multisampling wirklich nur mit einem Renderbuffer und nicht mit Textur.

Stalker verwendet kein echtes Anti Aliasing. Sie haben einen Edge Detection Filter und lassen dann einen Blur nur über die dadurch errechneten Kanten laufen. Das ganze kann man in der online version von gpu gems 2 nachlesen die es kostenlos auf der nvidia developer seite gibt. Im gpu gems 3 (auch kostenlos auf der nvidia seite) gibt es einen ähnlichen Artikel zu anti aliasing in tabula rasa. Das ist im Prinzip das gleiche wie bei Stalker, allreings leichter zu implementieren und es ist ist Auflösungsunabhängig.

Ab DirectX 10.1 ist das möglich, da man kompeltten zugriff auf den Multisample Buffer per Shader hat. Ich weiß nicht ob es eine Extension dafür gibt, da es Nvidia karten aber meines Wissens nach noch nicht unterstüzen und Ati karten schlechten OGL support haben, dürfte das sehr unwarscheinlich sein.

Was renderst du das du bei 14 FPS bist? Bzw auf was für einer Grafikkarte?

Edit: Es gibt doch eine Extension: http://www.opengl.org/registry/specs/NV ... sample.txt
Damit könntest du es vielleicht doch irgendwie hinkriegen. Allerdings nur Nvidia, wie meistens bei OGL

Ingrater hat geschrieben:Alpha to Coverage braucht viel Power.

Oooohja. Das Bild wird mit Samples nur so überschwemmt … der Vorteil von MSAA gegenüber SSAA, dass nicht das ganze Bild gesupersampled wird, geht mit Alpha to Coverage fast komplett den Bach runter … wenn es irgendwie möglich ist, sollte immernoch sortiert werden.

Ingrater hat geschrieben:Stalker verwendet kein echtes Anti Aliasing.

Clear Sky ist der zweite Teil mit D3D-10.1-Support und echtem AA.

Krishty hat geschrieben:Clear Sky ist der zweite Teil mit D3D-10.1-Support und echtem AA.

Stimmt, sorry hatte ich überlesen. Denke aber das sie die alte Methode immer noch drinhaben, weil heutzutage nicht viele eine DX 10.1 Karte haben

Stefan Zerbst hat geschrieben:Argh!

Es sieht wohl so aus, als ob man an einen Multisample FBO keine Texture als Color-Attachment anhängen könnte. Ich müsste also in einen Render-Buffer rendern. Bekomme ich den Inhalt dieses Buffers dann relativ schmerzfrei (lies: SCHNELL) in eine Textur? Das Problem ist, dass wir die Color-Attachments an unserem FBO noch für diverse Dinge performancekritisch als Texturen einsetzen. Was nützt mir ein Multisample FBO wenn ich damit nicht arbeiten kann? :o

Bist du schon auf die komplementäre Extension zu GL_EXT_framebuffer_multisample gestoßen? Mit http://www.opengl.org/registry/specs/EX ... r_blit.txt kann man einen Multisample-Renderbuffer in einen normalen kopieren, um das Multisampling vorm Benutzen als Texture explizit aufzulösen.

Hi,

@14 fps
Es handelt sich um Meshes mit Millionen von Dreiecken plus "Kleinkrams", 3D- und 2D-Overlay, blabla ... auf FX1700 Karten unter Vista (und es muss auch auf kleineren Mobile Karten noch flüssig laufen) :)

@yonibear
Stimmt das wäre eine Option. Aber dummerweise macht das die Sache wieder recht kompliziert. Wir eiern jetzt schon am Rande des VRAM rum und wenn ich mir zwei FBO für 24" Widescreen halte frißt mir das wieder VRAM weg den ich nicht habe :(

Letzten Endes hatte ich gedacht mit A2C eine schnelle Lösung für Transparenz bei unsortierten Meshes einbauen zu können ohne Depth Peeling und Shader benutzen zu müssen. Aber allein die Notwendigkeit das 4x AA im Treiber zu aktivieren und damit die Performance zu Dritteln ist schon das KO-Kriterium. Dass der FBO das nicht mitmacht, bzw. man einen zweiten bräuchte ist das so als ob der Boxer noch auf den bereits KO'en Gegner weiter einschlägt :mrgreen:

Und da es sich wie gesagt um Meshes mit Millionen von Dreiecken handelt (nein, die Datenmenge darf nicht reduziert werden) ist auch eine Sortierung nicht drin. Die Meshes werden zwar bereits grob in einen Box-Tree unterteilt und dieser Front-To-Back sortiert, aber eine Box enthält u.U. noch Zehntausende von Dreiecken.

Es sieht wohl so aus, als ob mir nur der sauer Depth Peeling Apfel über bleibt :(

Ciao,
Stefan