# skybox depth test

I draw skybox geometry after baking the scenery Z-buffer to take advantage of early-z and the z-buffer test itself.

I push the skybox near the farplane with glDepthRange, e.g.:

glDepthRange(0.9999,1);
// draw skybox
glDepthRange(0,1);

But this still results in clipping near the far plane (fog color does not match skybox smoothly).

How do I set the depth test to pass fragments if z==1.0, fail otherwise?

Or how do I make sure the skybox z fragment will always be 1.0? I’m thinking, if set the fragment depth to 1.0 in a shader I lose the early-z test.

Try setting z = w in your vertex program instead. That way z / w = 1.

Ah, that makes perfect sense, why didn’t I think of that?

*Edit: I still have some clipping issues, but I suspect this is due floating point inaccuracies as I move the skybox in the world to the eye position, instead of moving the eye position to the origin.

Are there alternatives that guarantee the fragment will pass when z==1.0 (per fragment rather than vertex level)?

You could try multiplying w by a number slightly less than 1, or you could use NV_depth_clamp, if available.

You could try multiplying w by a number slightly less than 1
That is essentially the same as the glDepthRange trick.

Not sure I want to use NV_depth_clamp as it is NV only.

I think it would even be possible to set glDepthRange(1, 1), so the resulting fragment depth will always be 1 but you propably still would get the problems due to clipping as clipping is applied before the depth range. So depth range is practically useless.

If you set z = w you basically put the point directly on the far clipping plane. Theroretically this should be ok but as you say you still get errors. You could make z a tiny bit smaller though.

An alternative would be to use a perspective transform which sets the far clipping plane to infinity and this would avoid the whole problem altogether.

Yes, glDepthRange(1,1) doesn’t work for me, the entire skybox is clipped. According to an old ATI paper this should work, but I heard it no longer behaves reliably on the latest drivers.

An alternative would be to use a perspective transform which sets the far clipping plane to infinity and this would avoid the whole problem altogether.
Does that work? Don’t things get clamped or clipped one way or another?

Originally posted by remdul:

[quote]An alternative would be to use a perspective transform which sets the far clipping plane to infinity and this would avoid the whole problem altogether.
Does that work? Don’t things get clamped or clipped one way or another?[/QUOTE]Yes, this should work as it is also needed for correct stencil shadows. Take a look at The Mechanics of Robust Stencil Shadows or Projection Matrix Tricks .

I will give it a look. The slides in particular look very interesting.

Thanks!