DepthTexture + Ati + FBO

Started by
11 comments, last by Yann L 16 years, 11 months ago
So, I've been doing some quick testing in Vista wrt some of the issues raised here;

- Firstly it appears that there is now access to a 24bit depth buffer paired with an 8bit stencil buffer;

	// Now setup the first texture to render to	glGenTextures(1, &depthTexture);	glBindTexture(GL_TEXTURE_2D, depthTexture);	glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8_EXT,                    width, height, 0, GL_DEPTH_STENCIL_EXT,                      GL_UNSIGNED_INT_24_8_EXT, NULL);	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);		// And attach it to the FBO so we can render to it	glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, depthTexture, 0);	glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_STENCIL_ATTACHMENT_EXT, GL_TEXTURE_2D, depthTexture, 0);	// Now set the render state correctly	glDrawBuffer(GL_FALSE);	glReadBuffer(GL_FALSE);	GLenum status = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);	if(status != GL_FRAMEBUFFER_COMPLETE_EXT)		exit(1);


on my X1900 that doesn't exit [smile] however as I'm not sure of the sanity of the rest of the code (it was doing strange things before but I've lost my good FBO based shadow mapping code) I can't comment on the quality.

- When it comes to the gl_FragCood.z value, well it doesn't return 0.5 all the time but I'm not sure what I'm seeing [grin]
I've some shader code which basically says if gl_FragCood.z > 0.95 frag color is green, else make it red; this results in a small section of the rendered polys being green close to the near plane and the rest being red.

I'd fiddle more but well, dissertation to complete so don't have the time [grin]

As noted, this is on Cat7.4 on Vista with an X1900XT card.
Advertisement
Quote:Original post by Yann L
Almost. The Position varying is not yet normalized, it's only in the unit cube clip space (as transformed by the vertex shader with ftransform). The normalization (ie. the transformation into normalized device space) is done by the homogeneous divide in the fragment shader (z/w). In the normal OpenGL transform pipeline, this divide is implicitely performed by dedicated circuitry outside of shader control, on all 3 coordinates. But we're only interested in z, so we only have one divide.

Then I transform the normalized device coordinates into window coordinates. That's basically applying the state controlled by glDepthRange. Again, this is usually done implicitely by the GPU. When using the default depth range, this transformation will simply map the normalized device coords in the -1..1 range into the 0..1 range.

Ah, I already know how all the transformations work, but for some reason I was under the mistaken impression that gl_DepthRange contained the actual near/far view-space plane values. It probably should have occurred to me that it was just mapping [-1,1] to the window-friendly [0,1] range (which is where the packing code makes sense [smile]), because how would OpenGL actually know what the near/far values are unless it went ahead and inverted the projection matrix and plugged in -1 and 1 to find out? But of course it wouldn't make sense to go through the trouble since you hardly ever need to know those values!
Quote:Original post by phantom
So, I've been doing some quick testing in Vista wrt some of the issues raised here;

Hmm, that's pretty good news. Seems that ATI really tries to keep up with their promises to do a better job on the Vista drivers. I wonder if AMD has anything to do with this...

Anyway, since you already have an ATI running under Vista, would you mind making a quick test ? Could you please try to read back a few pixels from a 24bit depth FBO renderbuffer (using glReadPixels), and check if they seem to contain reasonable values ? Thanks a lot !

This topic is closed to new replies.

Advertisement