Hi Guys!
I´d like to implement a refraction like effect, and would like to warp the "background" of the object in some way.
As the object is marked as translucent it is rendered in a separate queue after the opaque objects - so it can be assumed that at this
stage the background has been fully drawn.
Is it possible to use the actual BackBuffer as Texture Input or do I have to render to the scene to a separate RenderTexture and perform the read from this texture ?
I would like to avoid the additional copying that is involved with that.
Thanks a lot,
Frederick
Use BackBuffer as Texture Input
You can't do this directly as you would be both reading from and writing to the same GPU-side resource at the same time, so you have two main options.
Option 1 is to use a framebuffer object, which is basically what you've just described. Yes, it has some additional overhead, but it's not too onerous. This is the tried and tested solution used by all modern games, whether they be using GL FBOs or the D3D equivalent, so you can safely and confidently use it.
There's no real additional copying involved with this, but you are effectively covering each pixel in a screen-sized rect twice. Expect to lose at most 25% of your performance if you're already GPU-bound; if you're CPU-bound you may not even notice it.
Option 2 is to draw as normal, then glCopyTexSubImage to a screen-sized texture. This one does involve extra copying and extra data traffic, so it's going to be slower than using an FBO, but it is handy to keep as a fallback for GL implementations that don't support FBOs.
Option 1 is to use a framebuffer object, which is basically what you've just described. Yes, it has some additional overhead, but it's not too onerous. This is the tried and tested solution used by all modern games, whether they be using GL FBOs or the D3D equivalent, so you can safely and confidently use it.
There's no real additional copying involved with this, but you are effectively covering each pixel in a screen-sized rect twice. Expect to lose at most 25% of your performance if you're already GPU-bound; if you're CPU-bound you may not even notice it.
Option 2 is to draw as normal, then glCopyTexSubImage to a screen-sized texture. This one does involve extra copying and extra data traffic, so it's going to be slower than using an FBO, but it is handy to keep as a fallback for GL implementations that don't support FBOs.
Hey thanks!
ok, when I think about it seems logical to me now
ok, when I think about it seems logical to me now
You can't do this directly as you would be both reading from and writing to the same GPU-side resource at the same time, so you have two main options.[/quote]
Of course I would read the background, warp it and then render the front of the object on top of it. Doing that at the same time can´t work on a logical level... did not quite see that before
I guess I will go with the framebuffers then, no problem at all when post effects are applied (at some point in the future). They need offscreen buffers anyway.
Thanks!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement