The cube's edge seems longer than 2.0???

OpenGL OpenGL: Basic Coding
1

:frowning: I found a curious problem when studying frustum (or view volume) of perspective view.

  1. Given a cube at origine, 2.0 for each edge.
  2. A viewer at (0,0,5), looking at origine,with near plane 2.0 and far plane 20.0
  3. Each time we press ‘z’, the viewer moves 1.0 along negtive z-axis.

The question is:
When we move the viewer to (0,0,3) and (0,0,-3), we can’t see the cube plane overlapped with the near plane,
but when we move the viewer to (0,0,1) and (0,0,-1), we do can see the cube plane overlapped with the near plane.
It looks like the cube’s edge is longer than 2.0!
Why?
example is in “Interactive computer Graphics–A Top-down Approach with OpenGL 3rd” , cubeview.c

2

I don’t see any problem with projection and with example you talking about. In point 3 I can see one side of cube, in point 1 - another, in point -1 again I see first side and in point -3 - second. What a problem here?

3

Originally posted by CWiC:
I don’t see any problem with projection and with example you talking about. In point 3 I can see one side of cube, in point 1 - another, in point -1 again I see first side and in point -3 - second. What a problem here?
I’ve run it many times, but at point 3 and -3, I still can’t see the cube face overlapped with near plane.
maybe with some texture or change some color you will see this problem.

4

It’s not clear for me what you men while say “face overlapped with near plane”. Why “overlapped”? I just can see that face, don’t you?

5

I think a screenshot would be nice, don’t you think ?

6

If the problem is that some implementations show the front face of the cube if it is mathematically exactly on the front plane and others don’t, you’re relying on floating point precision to be identical among implementations.
This is deemed to fail generally (not OpenGL related). You should never expect a floating point calculation to “equal” some other floating point value this way.

7

Originally posted by Relic:
If the problem is that some implementations show the front face of the cube if it is mathematically exactly on the front plane and others don’t, you’re relying on floating point precision to be identical among implementations.
This is deemed to fail generally (not OpenGL related). You should never expect a floating point calculation to “equal” some other floating point value this way.
I think that’s the piont.
thanks for everyone