Why does the projection matrix transform object points into a unit cube in computer graphics?

This semester I both took a computer vision and a computer graphics seminar. But only now before the exams I realize that there seems to be a fundamental difference between projection in both topics.

In computer vision we learned the math to map an object point from 3D to a plane using a 4x3 matrix, which seems logical to me:

|u|   |p_11 p_12 p_13 p_14|   |X|
|v| = |p_21 p_22 p_23 p_24| x |Y|
|w|   |p_31 p_32 p_33 p_34|   |Z|
|1|


However in computer graphics one usually uses a 4x4-matrix. The very nice explanation on Coding Labs has a picture depicting the outcome of said transformation: it depicts a unit-cube containing the transformed objects (distorted according to the projection).

But a unit-cube certainly isn't what is rendered on to the flat 2D screen. Is there something going on internally that just isn't mentioned? Why is this done?

• I can agree that the question is not a duplicate, I can't add an answer since its been closed, but the answer in short is that you combine your world/model, view and projection matrices into one which is used in the shader. And both z and w are used in various instances. Nothing is stopping you from writing a shader that uses 4x3 matrices as uniform and drops the w component however Feb 18 '15 at 13:29
• @JoshPetrie could you un-duplicate my question. You probably did not receive a notification that I changed my question appropriately.
– alex
Feb 18 '15 at 16:07
• Thanks @DanielCarlsson, but my above formula already translates from proj. 3D to proj. 2D, therefore dropping the w component wouldn't make much sense. The way I understand it, after projection the "scene" is still in proj. 3D (so (X1 Y1 Z1 T1)^T before (i.e. View * World * Model) to (X2 Y2 Z2 T2)^T after (i.e. Projection * View * World * Model)). Obviously, there must be some final transformation not covered anywhere (so I get the 2D coords for the rendered pixels (before transforming proj 2D to euclidean 2D)) or I am completely wrong.
– alex
Feb 18 '15 at 16:17
• @alex No, I don't get explicit notifications if a question I closed is edited. Your clarification suggests that the bit about computer vision is tangential to the question, and that your main concern is about the rationale behind transforming into the 4D parallelepiped before projecting down to 2D? (I made edits accordingly to remove the distracting information.)
– user1430
Feb 18 '15 at 16:41
• I have a feeling the answer to Alex's question has to do with how games use the transformed z coordinate for a non-linear depth buffer, which presumably isn't required for the many kinds of computer vision work. Feb 18 '15 at 17:00

The application of the projection matrix is not the end of the transformation pipeline in computer graphics.

Applying the projection matrix to a set of geometry in computer graphics puts the object in clip space, which is a 4D parallelepiped (typically visualized as a unit cube). This space is useful because it makes the equations describing the view frustum extremely simple. For example, in D3D they (typically) end up becoming

-w <= x <= w
-w <= y <= w
0 <= z <= w


essentially due to the fact that the planes of the frustum are the planes of a "unit cube" and thus have trivial equations. This means clipping against that frustum is also extremely easy.

Clipping is an important part of the graphics pipeline, because it allows you to ensure the set of triangles to be rasterized is entirely within view, and thus avoid expensive checks and breaks in the tight loop of the rasterization routine. At the same time, clipping is a thing you need to test every triangle in the scene for, so arranging your pipeline to make it fast is important.

Computer vision is generally unconcerned with these details of rasterization, and thus doesn't need to take this detour.

• You know, I already suspected that exactly this is the case, but I couldn't find a resource. It seemed somewhat obvious that one would use the extra dimension to model the viewing frustum and also make clipping easier. Wish my professor would have explained this in more detail. Thanks!
– alex
Feb 18 '15 at 17:19
• What book did you use? Blinn's books are pretty good.
– user1430
Feb 18 '15 at 17:29
• I used Foley, Van Dam, Feiner, Hughes: Computer Graphics. Principles and practice. But then again I mostly studied the course notes, just skipped over passages in the book and did the homework assignments where we "just" implemented things in GLSL. Maybe I missed this part in the book, but what made me wonder where that noone seemed to write about this on the net at all. (Or my google-force left me)
– alex
Feb 19 '15 at 9:15