I have some old code that performs a glow effect by rendering to a pbuffer and
then ping ponging this texture between 2 pbuffers while running it thru a frag-
ment shader that performs a blur on the texture.
The obvious problem with this is that it requires a context switch for each
pass of the blur; ugly.
I’m trying to circumvent the issue by switching over to FBOs. As far as anyone
knows, can I bind a frame buffer object in order to render to it, while using
another FBO as a texture?
For whatever reason, it doesn’t seem to be working.
I once posted a small demo on this board that does a similar thing. It renders a few infinitely reflecting spheres by repeatedly rendering into the cubemap of one sphere while using the other cubemaps as textures.
The code is rather unstructured, it was just a quick hack to test FBO. Start it from the top source directory, not from the binary directory, else it will not find the texture and crash :rolleyes:
As far as I remember, I don’t even exclude the sphere with the currently rendered cubemap from rendering. It shouldn’t matter as long there are no texture lookups (and there are none in my case, thanks to backface culling), but it would propably be better to not render to and read from a texture at the same time…
Just a quick notice, that you don’t need to use two pbuffers. You can use the front/back buffer of a double-buffered pbuffer, thus eliminating the context-switch when pingponging
FBO seems to be the way to go in the long run, though.
Just a quick notice back at you hornet…
actually, how would that work?
you can’t render to a pbuffer context whilst it’s bound as a texture, right?
I would have to do a readpixels on the backbuffer into a texture then render it to the front buffer
then read the result back again for use in the back buffer…etc…right?
those readpixels should be far worse than a context switch.
All a moot point anyway I suppose, since pbuffers are on their way out anyway…
const GLenum pGLBuffer[2] = {GL_FRONT_LEFT, GL_BACK_LEFT};
const GLenum pWGLBuffer[2] = {WGL_FRONT_LEFT_ARB, WGL_BACK_LEFT_ARB};
int nCurBuffer = 0;
// pseudo code
void Render() {
wglBindTexImageARB;
for number of passes {
glDrawBuffer(pGLBuffer[!nCurBuffer]);
BindBuffer(pWGLBuffer[nCurBuffer]);
render();
nCurBuffer = !nCurBuffer;
}
wglReleaseTexImageARB;
}
// reading back the data
void ReadData() {
wglBindTexImageARB;
glReadBuffer(pGLBuffer[!nCurBuffer]); // ! because swapped one time too much in the loop
glReadPixels(...);
wglReleaseTexImageARB;
}
I posted this FBO demo under another topic, so you may have seen it. But it does the ping-ponging thing when it renders. http://www.reallyslick.com/src/fbo.zip
Originally posted by Aeluned:
[QB]Just a quick notice back at you hornet…
actually, how would that work?
What Kon said - except you don’t have to do the BindBuffer(…) (I assume it’s a wglMakeCurrent?) per iteration, you can do it outside the loop.
you can’t render to a pbuffer context whilst it’s bound as a texture, right?
You can’t render to a pbuffer-buffer, while it’s abound as a texture. Actaully you’re right, this is technically illegal, but it is “accepted” by nv/ati.
Originally posted by Aeluned: As far as anyone
knows, can I bind a frame buffer object in order to render to it, while using
another FBO as a texture?
Yes you can. The driver may perhaps be unhappy if you leave the FBO bound to a texture unit when you want to render to it, or bind it to a texture unit before changing FBO or something like that. Or it can simply be that you have trouble with left-over states that used to behave differently under pBuffers with their individual contexts. Several of my SDK samples require quite a bit of work cleaning up on various GL-states after porting over to FBOs. It’s very easy to get your mind stuck in pBuffer-land and expect old code to “just work”.
