Opengles 2.0 spec:
2.13 Primitive Clipping
Primitives are clipped to the clip volume. In clip coordinates, the clip volume is
defined by
-wc <= xc <= wc
-wc <= yc <= wc
-wc <= zc <= wc
It means that all points in view volume coordinate x/w y/w z/w are all in [-1,1].
I don’t know why. Since when the coordinates are normalized to view volume? far plane should be wider. why are the points near it in [-1, 1] too? It don’t seem like a linear transformation.
I’m guessing it’s similar to my implementation of frustum culling; applying the perspective matrix and dividing by W transforms the scene into “clip” space, where everything you can see lies between -1 and 1 on all axes. That’s what the card expects to have fed into it.
This is std homogenous clipping which occurs in the GPU after the vertex shader runs. Your vertex shader outputs clip space, which is what the above relations are defined in.
Recall that vertex shader transforms OBJECT-SPACE vtx position by both MODELVIEW transform (to yield EYE-SPACE coords) and PROJECTION transform (to yield CLIP-SPACE coords). In CLIP-SPACE, what is inside the view frustum is defined by the above inequalities.
Some time after clipping is done, the perspective divide occurs, leaving you with -1 <= x,y,z <= 1.
Why (point * perspective_matrix)/W fall into [-1, 1]?
Why? Why not? There has to be some finite boundary, outside of which geometry is not rendered. [-1, 1] is a simple range, and one that doesn’t lose very much precision from floating point numbers.
Thanks. I learned the perspective projection matrix.
I thought the z coordinate is linear transformation to clip space. I was wrong. It’s a non-linear transformation. The reason is for it to use matrix computing. If it use linear transformation, it will not be able to unify all transformations using homogeneous matrix. Non-linear transformation may cause z-fighting.That’s why we have a far plane and let it as near as possible to near plane.