Jump to content
  • Advertisement
Sign in to follow this  
Green_Baron

<attachment> does not name an attachment when glInvalidateNamedFramebuffer

Recommended Posts

Posted (edited)

Hi.

So, i am doing my first framebuffer

glCreateFramebuffers( 1, &m_framebuffer );
bind( GL_DRAW_FRAMEBUFFER );
if( GL_TRUE != glIsFramebuffer( m_framebuffer ) ) {
	....

with a color

glCreateRenderbuffers( 1, &m_colorAttachment );
if( GL_TRUE != glIsRenderbuffer( m_colorAttachment ) )
	std::cerr << "Error creating color renderbuffer.\n";
glNamedRenderbufferStorage( m_colorAttachment, colorFormat, m_sizeX, m_sizeY );
glNamedFramebufferRenderbuffer( m_framebuffer, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, m_colorAttachment );

and depth

glCreateRenderbuffers( 1, &m_depthAttachment );
if( GL_TRUE != glIsRenderbuffer( m_depthAttachment ) )
	std::cerr << "Error creating depth renderbuffer.\n";
glNamedRenderbufferStorage( m_depthAttachment, depthFormat, m_sizeX, m_sizeY );
glNamedFramebufferRenderbuffer( m_framebuffer, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, m_depthAttachment );

attachment. Execute the "how we are we today"

if( GL_FRAMEBUFFER_COMPLETE != glCheckNamedFramebufferStatus( m_framebuffer, GL_FRAMEBUFFER ) )
...

and in the renderloop i bind the framebuffer, render into, bind it to read, the window buffer to draw, and copy the rendered image over.

This works (example taken from the Red Book):

// Render in the framebuffer first
m_framebuffer->bind( GL_DRAW_FRAMEBUFFER );
glClearColor( 1.0f, 0.0f, 0.0f, 1.0f );
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
//m_framebuffer->invalidateData();

// ... renderrenderrender...

m_framebuffer->bind( GL_READ_FRAMEBUFFER );
glBindFramebuffer( GL_DRAW_FRAMEBUFFER, 0 ); // or m_framebuffer->unbind()
glClearColor( 0.0f, 0.0f, 1.0f, 1.0f );
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glBlitFramebuffer( 0, 0, m_window->getWidth(), m_window->getHeight(),
                 0, 0, m_window->getWidth(), m_window->getHeight(),
                 GL_COLOR_BUFFER_BIT, GL_NEAREST );

// poll() and swap() and start all ove again ...

But if i stray from the tutorial path and use glInvalidate..() instead of glClear() i get an "invalid enum, <attachment> does not specify an attachment".

The method is trivial:

if( GL_TRUE == glIsRenderbuffer( m_colorAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_colorAttachment );
if( GL_TRUE == glIsRenderbuffer( m_depthAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_depthAttachment );

glInvaliate... cause the error.

Debug message (1280): Source: API; Type: Error; Severity: high; GL_INVALID_ENUM error generated. <attachment> does not specify a valid attachment.
 

What have i done wrong ? It is just, i read, invalidate may be faster than actually clearing the buffers to a colour.

 

Edited by Green_Baron

Share this post


Link to post
Share on other sites
Advertisement
35 minutes ago, Green_Baron said:

if i stray from the tutorial path and use glInvalidate..() instead of glClear() i

Invalidate and Clear are two different things.

36 minutes ago, Green_Baron said:

The method is trivial:


if( GL_TRUE == glIsRenderbuffer( m_colorAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_colorAttachment );
if( GL_TRUE == glIsRenderbuffer( m_depthAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_depthAttachment );

glInvaliate... cause the error.

Which call brings the error ? The first one, the second one, or both ?

Also, from this API doc, it seems you should not give the attachment name (id), but its enum matching (color, depth...), which should be the cause of your error.

Share this post


Link to post
Share on other sites

Hi,

yep, the invalidation apparently doesn't bother with overwriting, it just sees the contents as not worthy to preserve. Useful when one is about to overwrite the buffer anyway (beginning of the frame, or so).

There are two commands: glInvalidateFramebuffer (the one you linked that works on the currently bound fb) and glInvalidateNamedFramebufferDate (the ones i use that work on a buffer- and attachment name). Syntactically that should be (?) ok.

What confuses me, it renders to the buffer. Just teh two (both) invaliation calls cause the error.

clearbuffer actually does cost considerable time and framerate ...

Share this post


Link to post
Share on other sites
41 minutes ago, Green_Baron said:

There are two commands: glInvalidateFramebuffer (the one you linked that works on the currently bound fb) and glInvalidateNamedFramebufferDate (the ones i use that work on a buffer- and attachment name). Syntactically that should be (?) ok.

They both expect the same enum for the attachment.

44 minutes ago, Green_Baron said:

What confuses me, it renders to the buffer. Just teh two (both) invaliation calls cause the error.

As said in my previous post, you don't give the expected value to the attachment parameter, and this is the cause of your errors.

Share this post


Link to post
Share on other sites

Oops, yes, you are right.

Here's how it works for everyone else:

GLenum attachments[2]{ GL_COLOR_ATTACHMENT0, GL_DEPTH_ATTACHMENT };
if( GL_TRUE == glIsRenderbuffer( m_colorAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &attachments[0]);
if( GL_TRUE == glIsRenderbuffer( m_depthAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &attachments[1] );

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!