# Size of the world and clipping area

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.

-

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.

-
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.