   "Linear" Depth-Buffer in Ortho Mode
  hi,The thread title is probably confused, since I'm not really sure how to describe what I'm trying to do. I'd like to use a 24bit depth-buffer as 2^24 unique "layers" for a 2D game.If the camera is in ortho mode and pointing along the z-axis, it seems like it should be possible to generate z values such that each unit of z corresponds directly to a unit written into the depth-buffer. For instance, z=1 will write 0x000001, z=2 will write 0x000010, etc.. this way no precision is lost, I can use all 2^24 planes of depth.Since 32bit floats have 24bits of mantissa, it seems like I should be able to use integer values 1..2^24 -- or possibly 0..((2^24)-1) --  as my z values. Would I then just use zNear=1, zFar=2^24? Or zNear=0.5? This seems similar to trying to get pixel-perfect sprites working, in that you need to be aware of rounding/etc that goes on behind the scenes.Basically I don't know where to start, as far as I can tell the solution should boil down to setting up zNear/zFar appropriately, and then taking care to assign specific z values. Ideally the depth buffer bits would correspond exactly to the mantissa bits. Is this possible to acheive? I thought I'd ask here rather than blindly stabbing in the dark; sadly I don't really know the proper words for describing what I'm trying to do, thus Google has been little help. Any advice would be greatly appreciated!thanks,raigan   
  2.5D??   ;  Sorry if this wasn't clear -- this is for a 2D game, let's say it's sprite-based so I'm just drawing screen-aligned quads. There is likely to be significant overdraw, so I'll be rendering front-to-back with depth-testing to avoid drawing any occluded pixels, and I'd like to make sure that there are no z-fighting problems. All verts of a polygon will be drawn with the same z value so that each polygon has a unique depth value in the depth buffer. At least, this is what I'd like to happen..   ;  Try setting near to 0 and far to 1. Use z as layer / static_cast<float>(1 << 24).;  Do you really need 16777216 different layers? I don't think so. Define how many layers do you think you'll need and define the near and far values accordingly. The internal difference between values will be enough to avoid any problems.Besides Z-fighting normally is a problem in 3D because the Z isn't the same accross the entire polygon. In a case like yours, the Z value is the same for the entire sprite. If there's Z-fighting, the sprite will either be entirely over or under the value it's fighting against, nothing more. And probably will have always the same effects given the same values (on the same hardware set up, that is), so players will never see weird Z-fighting situations that look bad.   ;  You're right, I don't need all those layers, but I _would_ like to know that polygons are guaranteed to be at unique depths and not the same depth. This holds for 1024 layers or whatever I end up needing -- I need to know that the depth buffer values are unique.Maybe this is a bit anal, but I'd rather not just hope that magically the depth buffer values are going to be unique per polygon, I want know for a fact that there won't be any "collisions" where two unique z values produce the same depth-buffer value. By "define the near and far values accordingly" do you mean using zNear=1, zFar=N+1, and use integer z values of 1 through N? Would this be sufficient to guarantee that two z values aren't mapped to the same depth-buffer value? I can't find any info on the exact formula/spec for ortho transformation and how the depth-buffer values are determined.. I'd just like to base my solution on actual knowledge and not just wishful thinking! ;)thanks again,raigan   ;  So, according to this: http://www.songho.ca/opengl/gl_projectionmatrix.html:let n = zNear, f = zFarinput coordinate: (0,0,z) normalized coordinate: -(2z + f + n) / (f-n)Apologies if the following is obvious, I'm just trying to work through things and make sure I understand what's happening:We're mapping a volume in worldspace (the rectangular prism bounded by [l,t,n],[r,b,f]) to the normalized cube bounded by [-1,-1,-1],[1,1,1].Considering only the z component:The midpoint of the rectangular volume, which will be mapped to the origin in normalized space, is 0.5*(f+n) The worldspace value of the unit vector in normalized space is 0.5*(f-n)So given a point located at z in worldspace, its position relative to the center of the rectangular prism is: z - 0.5*(f+n)And to transform it into normalized space: (z - 0.5*(f+n)) * (1 / 0.5*(f-n)) = 2z - (f+n) / (f-n) = -(-2z + f + n) / (f-n)So, there's a sign error coming from somewhere (the site gives -(2z + f + n) while I get -(-2z + f + n)). But aside from that: now what?!   ;  Why don't you just remove z-testing entirely since you're already ordering them? Just draw back to front. If the order of drawing is the only thing that determines "depth", then there will never be any conflicts. Sure, you'd be drawing unused fragments, but IIRC that won't waste much. A shader could change their z-depths, so they can't be optimized out very early, which means that you gain little by rendering front-to-back. (Someone please correct me if I'm misremembering this.)   ;  I should mention that I'm using openGL 1.2, just the fixed-function pipeline (no shaders). There will be significant over-draw, most polygons will be totally opaque, and it just seems preferable to draw front-to-back with the depth buffer.At this point it's mostly curiosity since it seems like there should be a good solution which would provide an exact mapping from z to depth-buffer-bits.   ;  What exactly are you drawing? Because if you're relying on the zbuffer rather than drawing back-to-front that means you can't have any blending and so your sprites are going to look like crap.   