I’m drawing to a texture using an FBO, as part of an update, then immediately sampling from that texture in a vertex shader to render the scene. But it seems that my FBO texture has not been updated when the first batch that depends on this texture is rendered. I suspect it’s not updated, in that if I issue the identical batch twice, consecutively, the second render is fine, as are all renders thereafter that frame.
I use the GL_RGBA32F_ARB format for my vertex textures, no mip mapping, nearest filtering, and clamp wrapping (I’ve tried all sorts of combinations, to be sure). But again, all is rendering perfectly, except for the first batch (a single triangle mesh) drawn after the FBO texture updates, which is at once untouched (clear value of zero) and strangely corrupted (assorted values, with no discernible pattern).
Operation is clean, no warnings or errors of any kind. I hope I’ve overlooked something, but after spending the better part of the day looking for it, I’m beginning to teeter.
Anyone seeing this?
Windows XP 32-bit SP2, NVIDIA GeForce 6800, Forceware 93.71 (and beta 93.81)
Yes, that’s a good idea, and I did try inserting a flush and finish in various places. I also tried repeatedly binding and unbinding the FBOs and textures, in an attempt to shake something free. The only thing that seems to work so far is issuing a drawing command.
By any chance are you using ping-ponging (read from the first texture, output to a second texture; then read from the second texture, output back to the first texture)? If so, it might be that you are reading from the first texture after the first pass, and nothing has been put into it yet.
Had I been ping-ponging, that would have been smashing indeed. Thanks very much for the interest.
To clarify things a bit, what I’m doing is updating several textures, each through its own unique FBO, then using them together as input to a vertex shader (GLSL). The update itself draws a full screen quad and executes a fairly simple vertex and fragment shader to produce the results. The next phase then binds two of these updated textures for use as input to a vertex shader for sampling. And again, this is all working perfectly, with the exception of the first rendered batch that makes use of the FBO textures.
However, I have recently noticed that if I use these updated textures in a fragment shader first instead, say for further processing, there doesn’t seem to be a problem at all; it’s only when rendering the initial results to the screen, directly, after the update, that the glitch is visually apparent.
I’m curious about the line “updating several textures, each through its own unique FBO.” This may seem like a dumb question, but you’re not sampling from the same texture you’re writing to, are you?
This is probably not the case. I imagine it’s something more like:[ul][li]Pick a texture. Say it has textureID 0.[*]Operate on the texture using a vertex and fragment shader, and output to the framebuffer color attachment glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);[/li]This color attachment is attached to a different textureID than the texture being sampled from, like textureID 1.[li]Now use textureID 1 (and the other textures updated in phase 1) as the input to your vertex shader.[/ul][/li]
Other than that, I can’t think of anything right now. It does seem strange that the error doesn’t appear if the textures are used in a fragment shader instead of being rendered directly to the screen.
No, I’m not sampling from the same texture I’m writing to.
Any yes, if I otherwise use the FBO texture in some way to render something, the update takes place.
If you’re interested, this is part of a geometry clipmap implementation I’m working on. I already have this working in HLSL, so I know it’s not the card itself.
Quite simply the only thing I can do to force a update, it seems, is to render something using the texture. The really strange thing is, all the other textures from the update are fine, but for the very first one (my first clipmap level is there but for the very first interior fill block - all zeroes).
I’ve done quite a bit of post processing with GLSL and FBOs (all sorts of FBO/shader interactions), and have had no trouble at all. So I’m beginning to suspect that the driver’s handling of vertex shader textures and FBOs in GLSL may be at the heart of this (winking knowingly).