View Full Version : fbo trouble.

11-04-2010, 06:47 AM

My last post got deleted because it was a cross-post and/or wasn't clear enough. If you are interested, it is here: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=285454#Post2854 54

So trying one last time, to the point.
Is there any undefined behavior for framebuffers that can result two different outputs for the samples below?

viewport(w, h)

viewport(w, h)

11-04-2010, 07:55 AM
These two would produce the same results under the canonical setup.
Things that could change the results:
-do the two framebuffers have the same/compatible formats, depth buffers.
-is the 'copy' right.

The basic approach outlined above is valid. So the problem must be in one of the details.

How are you doing the copy operation? I draw a quad and texture it with my framebuffer texture. Is this your approach?
It looks like a scaling issue, so I would suspect either the copy or the render viewport/matrix settings...
If it works with the nvidia cards but not the ati, that is weird and I can understand the frustration...

11-04-2010, 08:45 AM
Thanks for the reply.

Yes, i am doing the same, with a fullscreen quad.
It shouldn't be at copy phase since i can just output the result of attached textures into an image or i can just check all the textures i created. Textures attached that framebuffer same as the result i get copying it into main framebuffer.

Framebuffer got 2 textures attached, color and the depth. Also framebuffer is complete with no error, everything leads me to thing there is an undefined behavior at vertex clipping stage.
Not sure if it helps but i am using row-major/left-handed matrix layout for years without a problem. Here is a simple vertex shader:

[@I] vec3 vertex;
[@I] vec3 normal;
[@O] vec3 N;
[@U] mat4 mx_w, mx_vp;

void main()
mat3 W33 = mat3(mx_w[0].xyz, mx_w[1].xyz, mx_w[2].xyz);
N = normal * W33;

gl_Position = vec4(vertex, 1.0) * mx_w * mx_vp;

Note: since i am using row-major matrices the matrix/matrix and vector/matrix multiplying order is reversed.