Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a 32x32x32 cube (I say 32 because that's the size of the texture).

I can make the vertices of this cube go from (0,0,0) to (32,32,32). This mean the camera will be moving += 1 when ever a key on the keyboard is pressed. This also mean that the far clipping area will be pretty big when calling the CreatePerspectiveFieldOfView function.

Since everyhing is in double, I can also have the vertices go from (0,0,0) to (1,1,1). The camera will be moving += (1/32) and the far clipping area will be much smaller.

Is there a standard into this?
I've read that if the far clipping area is too big it can causes problems.
Since both solution have the same effect, I don't know what is the best one and which one can potentially case a problem in the long run.

share|improve this question
up vote 4 down vote accepted

The reason a big clipping area is bad is because the Z-buffer uses floating points between 0 and 1 to determine depth.

This means that the only real issue here appears when your clipping plane is FAR beyond the walls of the cube. Say half of your clipping plane is outside your cube, that would make the depth buffer resolution on the objects inside the cube half as accurate as it could be.

Hope this helps.

share|improve this answer
It's worth pointing out that because your Z-Buffer uses 0-1 floating point for depth, it really doesn't matter too much what your specific values are for distance and clipping plane since it all gets normalized in the end. What matters is that you only have a certain amount of total precision and when you try to stuff a ton of different distance points into your depth buffer you might start getting z-fighting issues. – Tetrad Nov 15 '10 at 12:40
@Tetrad thanks for this clarification – the_lotus Nov 15 '10 at 13:56

The other answer doesn't give you the whole story, even with the addition of Tetrad's comment. It's of vital importance to take into account the non-linear distribution of precision for values stored in the Z-buffer. zNear has a much greater impact on artifacts such as Z-fighting than zFar does.

For a better explanation of why, see this article:

share|improve this answer
I never knew the z-buffer precision was non-linear. Thanks for the link! – Luke Mar 22 '12 at 12:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.