Jump to content
  • Advertisement
Sign in to follow this  
yeoua

Texture maps and the Depth/Stencil Buffers

This topic is 4452 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

Ok, I know you can create a texture map with the depth/stencil buffer data using the glcopyteximage functions. But is it possible to write a texture directly into the depth buffer? I know you can do a read/write pixel command to write directly to the depth/stencil buffers, but I could not find anything about using a texture to do the same? The reason for this is that I'd like to be able to read from the depth buffer, copy the data to a set of textures for storage, then write the stored depth data from the textures back to the depth buffer. This would potentially be faster than using copypixel or read/write pixel.

Share this post


Link to post
Share on other sites
Advertisement
Direct access to the framebuffer (or depth buffer) is a bad idea. The framebuffer is located in the GPU memory, so it's too slow for the CPU to access it. Reading from the framebuffer could be 1000 times slower than reading from the main memory. It's much better to use the provided OpenGL pixel transfer functions. These functions are implemented in the graphics card driver, so they could take advantage of accelerated GPU/main memory transfers.

Share this post


Link to post
Share on other sites
The access I am talking about is texture to buffer, which is actually faster than the pixel functions.

So the idea is to draw onto a buffer, copy that to a texture directly, hold in gpu memory, and draw back into the buffer. This is easy for the color buffer, however I cannot find out if this is possible or not with the depth or stencil buffers.

Share this post


Link to post
Share on other sites
To speed up the depth copy you could use pixel buffer objects (PBOs) to allocate memory on the graphics card. You could then use GL's pixel read/write functions without the data leaving the card.

Alternatively (and I think better :)), you could use a framebuffer object (FBO) with a depth texture as it's depth buffer. You can then "copy" depth by just changing which depth texture is bound to the FBO.

Or you could use a fragment shader to read your depth from a texture and set gl_FragDepth in the shader. Drawing a single screen aligned quad would do the copy.

Hope those ideas help.

Share this post


Link to post
Share on other sites
So I'm guessing that it is not possible for a texture to affect the depth/stencil buffer like a texture would affect the color buffer...

Share this post


Link to post
Share on other sites
Quote:
Original post by deathkrush
Direct access to the framebuffer (or depth buffer) is a bad idea. The framebuffer is located in the GPU memory, so it's too slow for the CPU to access it. Reading from the framebuffer could be 1000 times slower than reading from the main memory. It's much better to use the provided OpenGL pixel transfer functions. These functions are implemented in the graphics card driver, so they could take advantage of accelerated GPU/main memory transfers.


I thought the pixel transfer functions ran on the cpu which makes them slow if used a lot?? Correct me if I'm wrong please.

Jon

Share this post


Link to post
Share on other sites
Quote:
Original post by jon723

I thought the pixel transfer functions ran on the cpu which makes them slow if used a lot?? Correct me if I'm wrong please.

Jon


It depends on the card and drivers. I worked with an NVidia card that was doing pixel transfers using the GPU, which is hundreds of times faster than doing the same thing using memcpy (think gigabytes versus megabytes). Anyway, I was under the impression that the OP wanted a direct access to the framebuffer via a pointer or something, so that's why I started rambling about pixel transfers being faster.

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!