i am playing around with the idea of creating a transparency-based z-buffer.
anyone know where to start looking function-wise for the pixel information of rendered primitives (along with a z-value for the pixel)? in other words, the information that the z-buffer itself stores?
what id like to do is after rendering (but not drawing) each primitive, i would like to store the normally z-buffered data in my own data structure. then evaluate all the transparency data within each pixel and finally draw it to the screen.
thanks for any help.
Not sure about this cos I’m a noobie too but maybe the answer you’re looking for is somewhere in the ray tracing area…
Corrections pls!!
What you’re trying to do is kind of tricky because you might have many objects covering the same pixel, so you need more than just a 2D buffer, you need a 2D array of lists. I don’t see how you can do this while still getting hardware acceleration from OpenGL. Why don’t you just sort all your polygons from back to front, and draw them that way? This way you’ll still have the proper transparency info.
You can read back the Z buffer from OpenGL using glReadPixels. However, this will not have all the information you need, only the highest Z drawn so far at each location. It’s also really slow.
For correct rendering, there’s one trick that avoids the need for sorting. It only works if your alphas are either 0 or 1. Simply, use glAlphaFunc so you don’t render any pixels with alpha < 1. This way you can still pass polygons in any order and get a correct image: if a pixel fails the alpha test, it doesn’t modify any buffer, but the only pixels which fail the alpha test are those that were transparent. (If you had no alpha test, even a pixel with alpha of 0 would overwrite the depth buffer value, and any solid pixels behind it might not be drawn).
depth sorting polygons fails in certain situations unless you further decompose those polygons (even in non-intersecting situations).
the work that i am doing does not “play well” with decomposition when polygons do not intersect.
therefore, depth sorting will not work for me.
final rendering speed is not a concern.
also, i need to be able to specify alpha from 0 to 1 in .1 units.
i will read up on glReadPixels. do you know if glReadPixels stores the “winning” z value? if so, how to access it?
thanks for your help!
As the others have stated, you need to handle multiple fragments covering the same pixel. About the only way I know how to deal with this would be to do some funky work with the stencil buffer. Each bit plane in the buffer would indicate (somehow, not sure exactly), the polygon that covered it.
Alternatively, you can go with some multipass rendering capabilty and shaders to encode a polygon id into one (or more?) output textures so that you can then composite the lot into the final colour buffer.