Jump to content
  • Advertisement
Sign in to follow this  
spek

Copying texture/buffer data

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

Hi, I have a problem with FBO's. In part of my rendering stage, I render everything to a texture. First I do the opaque stuff, then the transparent stuff. Before I start with the transparent stuff, I need a screen capture. I use that captured texture for effects like water, deformations, glass, and so on. Normally I use "glCopyTexSubImage2D" for that, but it seems that this function is extremely slow when the FBO is active (somebody knows why?). So, I simply used the "target texture" (where everything is rendered on) also as an input texture for some of the transparent objects. This works, but with artifacts (dots, weird lines). I think this is because I use the same texture both as input and output. So I need a copy of that FBO texture. glCopyTexSubImage2D is way too slow (unless I'm doing something competely wrong), so I need another way. One possibility would be by "switching" the render target texture:
  targetTex = Texture where normally everything gets rendered on
  copyTex   = A copy of targetTex, used as input for transparent stuff
  
  1- Render all opaque stuff on "targetTex"
  2- Set the FBO render target to "copyTex", instead if "targetTex"
  3- Render a screen filling quad where "targetTex" is placed on
  4- CopyTex now has a copy of targetTex
  5- Switch the FBO render target back to "targetTex"
  6- Render transparent stuff with "copyTex" as input
I think this works... But isn't there a faster way? Now I need a pass between and render a quad that fills the entire screen. It's a simple pass though, but maybe it can be done smarter. Rick

Share this post


Link to post
Share on other sites
Advertisement
I am going out on a limb here and saying look at PBOs. Ask Phantom he is the man for questions on PBOs. :)

Share this post


Link to post
Share on other sites
PBO's... That's new for me :) I quickly readed a little bit info. As far as I understand now, PBO's are used to quickly read pixel data, right?

I use FBO's for rendering in the background. In my case I render to a floating point texture for HDR (in the end, this FBO texture is rendered to the normal output buffer with tonemapping). I also use it for making a "depth" texture for the DoF effect. In both cases, I also use "glReadPixels" for measuring average pixel values (luminance), or getting the depth at the center of the screen. I know glReadPixels isn't really fast, although I only read a few pixels. And now I also need a copy of the FBO texture, before I render transparent things that use this copy for refraction effects.

Should I do this background stuff on a PBO instead of a FBO? Or is is possible to "connect" the FBO to a PBO so that I can read the pixels quickly? And when I have my copy of the screen content in a PBO, how to use it (as a texture?) in my shaders that use refraction?

Maybe some of the questions are stupid, but I'm trying to understand how the PBO is used, since its completely new for me.

Thanks for helping,
Rick

Share this post


Link to post
Share on other sites
PBO's is not the solution. PBO is like VBO, but you can render to it and then use it as a VBO. You probably know it better as "render to vertex array" == RTVA

Back to the first post :
Do not render to a texture and sample it at the same time
and looks like you have the right idea
There is another extension for FBO blitting. I've never tried it.

Share this post


Link to post
Share on other sites
Thanks everyone!

But I'm a little bit confused now. Some say I should go for the PBO's, others say I shouldn't. From what I understand, PBO's can give fast access to pixel data, since its a direct link. And operations such as "glCopyTex" are using a similiar approach as well, if I'm right.

But V-man says I'd be better off not using PBO's. So, that means in my case I just render the scene to another FBO(texture), before doing my transparent stuff, and then switch back to the other FBO. Which basically means I do an extra pass between. Not a difficult one though, I just render a quad with a (floating point) texture on it.

greetings,
Rick

Share this post


Link to post
Share on other sites
The FBO blitting extension is currently only supported on G80 based cards afaik and isn't really an option here (I'm also pretty sure it's only for copying between areas of a framebuffer).

Define 'slow' when it comes to glCopyTexSubImage2D?

When it comes to avoiding this copy there are two ways you can go about this;
- Perform all your rendering to one texture and then re-render into another with a single quad thus giving you a copy
- Render to two textures at once using MRT, thus generating two copies of the data.

Personally, I'd take the first option, as the overhead of doing what is in effect a fast copy will probably out weight the bandwidth loss from trying to MRT (plus I'm pretty sure that'll require modifications of any shaders being used).

btw, PBOs aren't the solution here at all, while they do have more uses than RTVA this isn't one of them. Poor poor misunderstood extension [sad]

Share this post


Link to post
Share on other sites
>> Define 'slow' when it comes to glCopyTexSubImage2D?
With no FBO's, it's just fast. When a FBO is enabled (all the output is going to a 16F texture, and the snapshot is also taken from that texture), my framerate drops from 60 to 10 or something. Something really isn't going very well.

>> Perform all your rendering to one texture and then re-render into another with a single quad thus giving you a copy

I was indeed thinking about that. But I was wondering is there were faster methods. Therefore PBO's were suggested.

Everybody thanks for helping,
Rick

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!