[OpenGL] Framebuffer-Erstellung scheitert

[Schrompf]

Mahlzeit.

Ich erstelle eine Textur als Rendertarget...

Code: Alles auswählen

glGenTextures( 1, &mTexturId);
glTextureImage2DEXT( mTexturId, GL_TEXTURE_2D, 0, GL_R32F, 1024, 1024, 0, GL_RED, GL_FLOAT, nullptr);
glTextureParameteriEXT( mTexturId, GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);

...und baue die in einen Framebuffer ein, um darin rendern zu können.

Code: Alles auswählen

glGenFramebuffers( 1, &mFrameBufferId);
glNamedFramebufferTextureEXT( mFrameBufferId, GL_COLOR_ATTACHMENT0, obigeTexturId, 0);
glNamedFramebufferRenderbufferEXT( mFrameBufferId, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, zBufferId);
GLenum fz = GL_COLOR_ATTACHMENT0;
glFramebufferDrawBuffersEXT( mFrameBufferId, 1, &fz);

auto status = glCheckNamedFramebufferStatusEXT( mFrameBufferId, GL_FRAMEBUFFER);

Und bekomme dort GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT als Status. Was wohl heißt, dass meine Renderziel-Textur irgendein Problem hat. Wenn ich das Programm in NSight laufen lasse, bekomme ich API-Error-Warnungen für jeden DrawCall in dieses Renderziel, aber ich kriege den Bernd nicht dazu, dass er mir mal den Wortlaut des Fehlers preisgibt. Die Textur existiert anscheinend und wird auch in späteren DrawCalls gebunden, aber wenn ich sie mit NSight anschauen will, stürzt Visual Studio ab.

Detailfrage: woran könnte es liegen, dass ich die Textur nicht in einem Framebuffer verwenden kann.
Allgemeinfrage: wie sichert man sich bei OpenGL allgemein gegen solche Probleme ab? Wie sieht eine vernünftige Fehlerbehandlung bei OpenGL aus? Rückgabewerte gibt es ja keine, und glGetError() soll angeblich einen Sync mit dem Treiberthread auslösen, was jede Performance ruinieren würde.

[xq]

Das hier schon gelesen?
https://www.opengl.org/wiki/Framebuffer ... mpleteness

Mehr fällt mir leider grade auch nicht ein

[Schrompf]

Danke für den Link. Nach meinem Verständnis erfüllen obige paar Zeilen aber alle Bedingungen, die dort aufgelistet sind. Hm. Ich suche weiter.

[Sternmull]

Zum konkreten Problem mit der Textur hab ich nichts hervorzubringen. Als Entwicklungs-Debug Hilfe für OpenGL bin ich eigentlich mit der Debug-Extension ganz glücklich geworden. Sofern die vom Treiber angeboten wird (bei NVIDA ja, bei ATI bestimmt auch, bei onbaord-Intel bei mir aber nicht), kann man eine Callback-Registrieren die bei Fehlern und Warnungen aufgerufen wird. Zumindest mein NVIDIA-Treiber war bisher informativ genug um Probleme frühzeitig erkennen zu können. Ich finde die Callback auch ganz gut weil ich da einen Breakpoint rein setzen kann und dann auch im Debugger ganz genau sehe auf welchem Weg ich Mist gebaut hab.

[Schrompf]

Nutze ich auch schon. Aber DEBUG_OUTPUT_SYNCHRONOUS_ARB war mir so noch nicht bewusst, das könnte nützlich werden.

[Schrompf]

Ok, mit dem synchronen Error-Callback habe ich herausgefunden, dass ich Texturen ohne Initialinhalt aus Versehen mit Größe 0 erzeugt habe. Das lehnt der Framebuffer völlig zu Recht ab. Danke!

[Spiele Programmierer]

"GL_DEBUG_OUTPUT_SYNCHRONOUS_ARB" wird technisch bedingt sicherlich auch eine Synchronisation mit dem Treiber Threads auslösen.

Enabling synchronous debug output greatly simplifies [...], but may potentially result in drastically reduced driver performance.

Nützlich ist es im Debug-Mode natürlich trotzdem.