Jump to content
  • Advertisement
Sign in to follow this  
myers

Binding a floating point texture as an FBO depth attachment

This topic is 3751 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is it possible to do this? Specifically, I want to copy a depth renderbuffer to a colour texture. In order to do this, I'm trying to attach a floating-point texture as the depth part of an fbo, before using glBlitFramebufferEXT to do the copy. But attempting this binding yields an "incomplete fbo" error. Basically this:
glGenFramebuffersEXT(1,&framebuf);
glGenTextures(1,&fptex);
glBindTexture(GL_TEXTURE_2D,fptex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE32F_ARB, 1024, 1024, 0, GL_LUMINANCE, GL_FLOAT, NULL);

...

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT,framebuf);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, fptex, 0);

As I say, this results in framebuf being incomplete. I've tried with a 16-bit texture, too, and that doesn't work either. Perhaps you can't attach a colour texture to GL_DEPTH_ATTACHMENT? If not, is there another way to copy the depth renderbuffer into a colour texture? Thanks for any assistance.

Share this post


Link to post
Share on other sites
Advertisement
See here:
http://www.gamedev.net/community/forums/topic.asp?topic_id=500882


To make it work use a depth texture. You can later use this texture just as you would use a Luminance texture once you have rendered to it.

Share this post


Link to post
Share on other sites
Well, as Hardguy suggested, I've switched to using a depth texture instead of a luminance one, and the FBO is at least complete now. However, a weird issue's arisen.

The source renderbuffer (the one I'm trying to copy to the depth texture) is multisampled. This seems to complicate matters. If I use a non-multisampled buffer instead, the blit function works fine. But with a multisampled buffer, nothing seems to be copied - and in fact, if I don't also attach a colour buffer to the destination FBO, the whole thing turns into a slideshow. I thought this might be a driver bug, but I've updated and it's still happening.

Is it illegal to blit a multisampled depth renderbuffer to a depth texture? Will glBlitFrameBuffer not resolve a multisampled depth surface? If so, the only options I can see are to render directly to the depth texture in a second depth pass (which I can ill afford), or to abandon multisampling.

Share this post


Link to post
Share on other sites
What is that u are trying to do? To render to the actual screen frame buffer normally and then just have a depth buffer texture instead of the normal screen depth buffer?

If this is the case, then as far as I know, you need to bind a color buffer or texture to the frambuffer if you want to draw color to it. Using the normal screen color buffer and depth texture does not work in OpenGL as far as I know.

Also, when rendering to the a framebuffer multisampling does not work (for almost all cards/drivers that is, there might be some newer cards that support it).

Tell us what you are trying to do and it will be easier to give a more precise answer.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hardguy
What is that u are trying to do? To render to the actual screen frame buffer normally and then just have a depth buffer texture instead of the normal screen depth buffer?


No, I want a copy of the z-buffer that I can read in a fragment shader.

All scene rendering is done in HDR to an FBO, which has two FP16 colour renderbuffers and one depth renderbuffer (which is used for depth testing during rendering). All three surfaces are multisampled.

Once scene geometry has been rendered, I want to copy the depth renderbuffer to a texture, so that I can use it in various post-processing shaders. It's this part that isn't working.

The relevant code is this:

glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, msfbo.handle);
glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, depthfbo.handle);
glBlitFramebufferEXT(0, 0, depthfbo.width, depthfbo.height, 0, 0, depthfbo.width, depthfbo.height, GL_DEPTH_BUFFER_BIT, GL_NEAREST);






where msfbo is the multisampled FBO to which the scene has been rendered, and depthfbo is an FBO with only one attachment, a depth texture. msfbo's three surfaces are all the same size as depthfbo's depth texture. Both fbos have their read and draw buffers set to GL_NONE (so that only the depth attachments of the two fbos are read and written).

But for some reason, nothing is being copied to depthfbo. And in addition, the call to glBlitFramebufferEXT is horrendously slow, as if the blit is being done in software. If I attach a buffer to depthfbo's GL_COLOR_ATTACHMENT0 attachment point, then the blitting call runs at normal speed again - but still, nothing is copied.

If I set up msfbo's buffers as non-multisampled instead, and change nothing else, then everything's fine: the copy takes place and at a decent speed. Which leads me to believe I must be missing a point of etiquette when dealing with multisampled FBOs.

Quote:
Also, when rendering to the a framebuffer multisampling does not work (for almost all cards/drivers that is, there might be some newer cards that support it).


I'm using the GL_EXT_framebuffer_multisample extension, which (according to Realtech) has been supported since the Geforce 5200.

I should point out that, later in the pipeline, I also blit msfbo's colour buffers to textures for post-processing. This step works fine, even when the buffers are multisampled. It's only the depth copy that is causing me grief. So the extension seems to work, at least partially.

Share this post


Link to post
Share on other sites
I think that you should change your design a bit. As far as I know using a render buffer for the color is not really good since you need (as u say) use a blit to get the information, and blits are really darn slow.

I think that you should use textures for the instead of color buffers and use one FBO with floating point texture and a depth texture.

When it comes to this code:

glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, msfbo.handle);
glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, depthfbo.handle);



I do not think it is something is along the lines of the specifications and seems like something that will cause troubles. Check issue 42 in the FBo spec for more info but basically it says that only a single (read/write) taget is to be supported by the inital extension. I am not sure if there are some future extension out that supports it, but not as far as I know.

Share this post


Link to post
Share on other sites
You you know about the GL_NV_depth_buffer_float extension?
This one allows you to use a floating point depth texture


http://opengl.org/registry/specs/NV/depth_buffer_float.txt

I guess that is what you are after.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hardguy
I think that you should change your design a bit. As far as I know using a render buffer for the color is not really good since you need (as u say) use a blit to get the information, and blits are really darn slow.

I think that you should use textures for the instead of color buffers and use one FBO with floating point texture and a depth texture.


I don't think you can use multisampling when rendering to a texture. That's the whole reason I'm using renderbuffers. And the blit that works - the colour buffer one - is pretty fast.

So I'm now thinking it's not possible to resolve a multisampled depth buffer with a blit on current hardware. I've not been able to find anything that just baldly states this, so if anyone knows for sure whether this is possible, that would be very helpful.

Quote:
When it comes to this code:
*** Source Snippet Removed ***

I do not think it is something is along the lines of the specifications and seems like something that will cause troubles. Check issue 42 in the FBo spec for more info but basically it says that only a single (read/write) taget is to be supported by the inital extension. I am not sure if there are some future extension out that supports it, but not as far as I know.


Meaning what, exactly? You can only read and write from buffers that are attached to the same FBO? I hadn't really considered that - and if it's the case, it doesn't really solve my problem, because then how would I copy from one depth attachment into another?


Quote:
Original post by Basiror
You you know about the GL_NV_depth_buffer_float extension?
This one allows you to use a floating point depth texture


http://opengl.org/registry/specs/NV/depth_buffer_float.txt

I guess that is what you are after.


Hmm, would that allow me to resolve the multisampled depth buffer with a blit? Even if it does, I'd prefer a non-vendor-specific solution if one is available.

Share this post


Link to post
Share on other sites
It is possible to have multi sampling when rendering to a texture, but it something that is only supported on a few cards (ATI only I think, perhaps someone can give more info). Not sure what openGL extension is used to support it either (same here, perhaps someone knows this better than I).

So my advice is to skip the multisampling for now (unless u have the hardware and ogl the support) and use a single FBO with textures for color and depth.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!