   Fighting Z in planet rendering
  I am currently working on an elite-like simulator where you can fly through space and land on planets.Since the z-distances vary from a scale of 1 (ship touched the ground) to 10^10 (e.g. sun from earth), I quite struggle with my z-buffer as you can imagine.If a planet is very far away, it starts flickering even WITH face culling. It starts getting background-black randomly, so it might be the depth test (LEQUAL in my case with buffer filled with ones before drawing). I guess it might also be a problem with the far clipping plane. Any ideas?Any ideas how I turn off the far plane in opengl? I read something about the possibility to do so and to clip the z-value to 1. How can I do that?Any other ideas for varying-scale planet renderings? 
  I don''t think it''s possible to turn it off as all depth is being clamped from 0 to the max bepth buffer value (which stands for z-far). So this will cause detail to be lost. You could try setting it to MAX_DOUBLE (if you''re using doubles, else MAX_FLOAT) i have no idea if that works, you can try it. ;  You can use an infinite projection matrix, but this will give you atrocious depth resolution for far objects. You could also use NV_depth_clamp.  Another possibility would be to render in multiple passes.  The first pass uses a distant near clipping plane and very distant far clipping plane, the second pass uses a close near clipping plane and a distant far clipping plane.  Add passes as required.Enigma ;  At the moment, I''m turning depth testing off for far objects and use a big nearPlane and a huge farPlane. Most planets are convex enough and don''t produce artefacts when the z-buffer is turned off.  But unhappily, some (e.g. the moon Mimas) are not. And unfortunately, far-plane-clipping seems still to be done even with disabled depth test.Using two passes would solve the problem if done properly, but has the disadvantage that I have to clear the depth buffer twice (which is not too bad, but also insignificant). But still better than artifacts, right? I''ll see. Thanks.Hey, I could also use z-range 0.0 to 0.5 for the first pass and 0.5 to 1.0 for the second one. That would solve the clear problem but give me less accuracy.How do I turn the NV_depth_clamp thing on? Probably, my opengl.h file doesn''t know the DEPTH_CLAMP constant (I can''t look it up at the moment), so can I just pass the hex-number to glEnable? Will it work on graphics hardware other than NVIDIA? Does it work on my GF2 MX400?When do we have the 128 bit z-buffer???;  To use NV_depth_clamp, just glEnable(GL_DEPTH_CLAMP_NV), but be sure to check the extension string to find out if it''s actually supported.  You''ll need a copy of glext.h, or you might want to grab a copy of Benjamin Bunny''s GLee instead.Enigma ;  You can''t expect a depth buffer to resolve differences in Z where these differences are considerably smaller than the size of your scene.  So, as suggested, you have to split your scene into "zones" where the size of the each zone is somewhere near the size of the Z differences you are trying to resolve.  Then draw these zones back-to-front, clearing the Z buffer in between.You may choose the zone to be the size of a planet, or a solar system or whatever - as long as the don''t overlap in extent.A scheme like this lends itsself capturing each zone into a texture and only updating the texture every now and then - much faster ! ;  > A scheme like this lends itsself capturing each zone into a > texture and only updating the texture every now and then - much> faster !ChookMaster, what do you mean? I capture the z-values in the z-buffer into a texture and update it only every n-th frame? Makes sense to me, but is it what you mean? Or do you mean I capture the actual image from planet-far-away and convert it to an imposter?