Da der Beitext zu Feedback-Forum sich über zu wenig Feedback beklagt und ich zufällig über etwas gestolpert bin,
weil ich mir die Fehlerabfrage geklaut habe

Zwei kleine Dinge müssten vielleicht berichtigt werden:

1. glGetIntegeri(GL_MAX_COLOR_ATTACHMENTS_EXT, @maxbuffers);

2. Der Bezeichner GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT in der Fehlerabfrage ist nicht gültig.
Bei mir ist der Bezeichner nicht bekannt, in der Spezifikation steht auch warum.

Auszug aus der Spezifikation:



Schönen Abend....Weiter so!

Danke fürs Feedback (Dachte schon der Hinweis wird übersehn und ich sollte mal ein lautegebenden Flashlayer einfügen. ).
Bin sicher Deathball wird sich der Sache annehmen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich nehme mal an dass es um einiges schneller ist als glCopyTexImage2D, oder?
Wäre es möglich noch ein paar Worte über die Performance zu verlieren?


Im Abschnitt "Mehrere Texturen in einem FBO" ist noch nen Tippfehler bei "COLOR_ATTATCHMENT".

Aber ansonsten sehr ausführlich und verständlich. Mal sehen wann ich das implementiere...


gruß

damadmax

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Danke für die Hinweise - ich werde mich gleich hinsetzen und sie verbessern...


über die Performance: Genaues kann ich leider nicht liefern. Ich habe noch kein Performance Check gemacht, kann mich also nur auf das verlassen was in Foren oder in Whitepapern steht.

Simon Green (http://download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/OpenGL_FrameBuffer_Object.pdf meint das die Benutzung von mehreren FBO's gegenüber mehreren Pixelbuffern viel Performance bringen dürfte, weil das sehr teure switchen der Contexte entfällt (mit wglMakeCurrent). Jedoch meint er auch das RenderToTexture sehr schnell sei.

glCopyTex(Sub)Image2D kann laut gamedev.net sehr schnell sein, es sei denn man nimmt riesige Texturen. Soll heißen - unter Umständen sind FBOs gar nicht schneller als glCopyTex(Sub)Image2D.

Auch erinnere ich mich das Sascha Willems glaub ich mal die Performance von Pixelbuffern und Framebufferobjects verglichen hat und zu dem Schluss kam das gar nicht so viel unterschied zwischen den beiden ist (der Thread müsste hier im Forum gewesen sein).

Leider hab ich jetzt keine Zeit mehr weiter zu schreiben, da ich weg muss. Wenn ich Zeit hab such ich noch ein paar Quellen oder versuche mal selbst nen Vergleich von RenderToTexture und FBO's zu machen.

Rein theoretisch sollten FBOs schneller sein als Pixelpuffer, da man wie gesagt die aufwendigen Kontextwechsel vermeidet. Allerdings haben Pixelpuffer durch den eigenen Kontext den Vorteil dass man auch eigene States hat, wenn man jetzt z.b. mehrere Szenen in FBOs rendert und man jedesmal aufwendige bzw. viele Statechanges durchführen muss kann dies logischerweise mehr Performance kosten als der Kontextwechsel eines Pixelpuffers. Ausserdem sind FBOs noch ne recht neue Sache, die wohl mit neueren Treibern noch optimiert werden.
Das direkte in die Textrur Kopieren (RTT) sollte eigentlich am schnellsten sein (auch hier wieder an die Zahl der Statechanges denken), hat aber logischerweise den Nachteil dass man damit nur Texturen bis zur Größe des Kontexts in die Textur bekommt (der jenseitige Bereich ist undefiniert, und je nach Implementation reichts auch wenn ein anderes Fenster nen Bereich überdeckt um diesen undefiniert zu machen).

Ob man sich also für Pixelpuffer, FBOs oder direktes RTT entscheidet hängt stark vom Anwendungsfall ab. Pixelpuffer sind halt von der API her recht unschön, und wirken irgendwie auf aufgesetzt, aber bei vielen Statechanges würd ich immernoch auf Pixelpuffer setzen, und bei kleinen zu rendernden Bereichen auf direktes RTT.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)