# What does the graphics card do with the fourth element of a vector as the final position?

From this question it appears you would want a four-element position vector, as it is simpler to modify its position with matrix multiplication.

On its own this would imply the fourth element should simply be ignored when considering it as a representation of a 3D point (assuming no transformation), but I know this is not true, as when I supply a vector4 to the GPU, if the fourth element is not one, it is not rendered - why?

What is the significance of the fourth element, once it is in the rasterizer?

EDIT: On review this question was somewhat poorly worded; it would be more accurate for the second paragraph to say: "if the value of the fourth element is not within a certain range, it is not rendered 'correctly'/'as expected'".

• does not a vector4 with coordinates (x,y,z,0.5) give the same results of the vector4 with coordinates (2x,2y,2z,1)? – FxIII Oct 1 '11 at 21:09
• @FxIII, I was not able to reproduce that exactly but you are right that was an incorrect blanket statement made in my original post, after some more experimentation I have updated it. – sebf Oct 2 '11 at 14:39

The fourth component is a trick to keep track of perspective projection. When you do a perspective projection, you want to divide by z: x' = x/z, y' = y/z, but this isn't an operation that can be implemented by a 3x3 matrix operating on a vector of x, y, z. The trick that has become standard for doing this is to append a fourth coordinate, w, and declare that x, y, z will always be divided by w after all transformations are applied and before rasterization.

Perspective projection is then accomplished by having a matrix that moves z into w, so that you end up dividing by z. But it also gives you the flexibility to leave w = 1.0 if you don't want to do a divide; for instance if you just want a parallel projection, or a rotation or whatever.

The ability to encode positions as w = 1, directions as w = 0 and use the fourth row/column of a matrix for translation is a nice side benefit, but it's not the primary reason for appending w. One could use affine transformations (a 3x3 matrix plus a 3-component translation vector) to accomplish translation without any w in sight. (One would have to keep track of what's a position and what's a direction, and apply different transformation functions to each; that's a bit inconvenient, but not really a big deal.)

(BTW, mathematically, vectors augmented with w are known as homogeneous coordinates, and they live in a place called projective space. However, you don't need to understand the higher math to do 3D graphics.)

• Once again is slightly incorrect to talk about vectors and points in those terms since there is an isomorphism between points and vectors (the point and the vector that move the origin to that point are the same entity). Would be more correct to talk about points/vectors (w!=0) and (projective)directions (w=0). Anyway the misuse of the term "vector" is a quite consolidated standard in the 3d libraries language. – FxIII Oct 1 '11 at 21:17
• @FxIII: Corrected. It was confusing to use "vector" in the standard math sense and as a synonym for "direction" in the same post. – Nicol Bolas Oct 1 '11 at 21:57
• @FxIII and Nicol Bolas: I disagree. You really do encode vectors as w = 0 - including both vectors that just represent a direction, and actual vectors where the length is important. For instance, you can transform the angular velocity vector (direction = rotation axis, length = speed) of an object between local space and world space using the object's matrix. You don't want the angular velocity to get the object's translation added to it; you only want it to be rotated. So you set w = 0. I don't see the problem? – Nathan Reed Oct 1 '11 at 23:11
• @NathanReed I hope that my post helps to clarify the point, anyway a large part of my point is upon definitions and the misuse of the term vector plus the primacy of linear algebra over the standard 3D library terminology. Of course both are debatable as every definition and primacy claim is – FxIII Oct 2 '11 at 10:13
• @Nathan, I can see clearly now the purpose of the fourth element, and how the information it contains is used by the rasterizer. Thanks a lot! – sebf Oct 2 '11 at 14:34

Tring to answer to the appropriate comment of Natan, I did some consideration that can be useful to understand what really happens when you use vectors in Affine Space to represent 3D vectors in the standard Euclidean Space.

First I will call vector whatever has coordinates, so a point and a vector are the same entity; you can see a vector as difference of two point: V = B - A; V moves A in B because A + V = A + B - A = B. Put A = 0 (the origin) and you will get that V = B - 0 = B: the point B and the vector that moves 0 to B are the same thing.

I will call "vector" - in the sense used in the majority of 3D libraries - when a vector of the affine space has w = 0.

The matrix are used because they let you to represent a linear function in a compact/elegant/efficient form, but linear functions has the major disadvantage that can't transform the origin: F(0) = 0 if F wants to be linear (amog other thing such F(λX) = λF(X) and F(A + B) = F(A) + F(B) )

This means that you can not construct a matrix that do a translation since you will never move the 0 vector. Here comes into play the Affine Space. The affine space adds a dimension to the euclidean space so traslantions can be done with scaling and rotations.

The Affine Space is a projective space in the sense that you can construct a equivalence relation between Affine and Euclidean vectors so you can confuse them (as we did with poins and vectors). All the affine vectors that projects to the origin with the same direction can be seen as the same euclidean vector.

This means that all the vectors that have the same proportions in the coordinates can be considered equivalent:

Mathematically: i.e. every affine vector can be reduced to a canon version where w=1 (we choose among every equivalent vector the one we like best).

Visually (2D euclidean - 3D affine): hence the mean of "projective" space; You should notice that here the euclidean space is 2D (the cyan region)

There is a particular set of affine vectors that can't be put in their canonical version (with ease) the one that lies on the (hyper)plane w=0.

We can show it visually: what you (should) see is that while w -> 0 then the projected vector into the Euclidean space goes to the infinite but to the infinite in a particular Direction.

Now is clear that adding up two vectors in the projective space can lead to problems when you consider the sum vector as a projected vector in the euclidean space, this appends because you will sum the W components in the affine space and then project them to the euclidean (hyper)plane.

This is why you can sum only "points" to "vectors" because a "vector" will not change the w coordinate of the "point" this is true only for "points" where w =1: As you see the green point is the one obtained adding the two affine vectors that represent the cyan "point" and the V "vector", but if you apply V to every affine vector in a form different by the canon one, you will obtain a wrong results (the red ""point"").

You see that Affine Space can't be used transparently to describe operation on Euclidean Spaces and the misuse of the term "vector" has sense under the (strict) constraint of compute sums only on canon projective vectors.

Said that, is quite reasonable to think that the GPU assumes that a Vector4 has to have w=0 or w=1, unless you really know what you are doing.

• It was very hard to pick one answer to this question, as all have contributed to the understanding of how the the relationship of the fourth component is used and why it is needed. Your explanation of euclidean and affine space is very helpful, I certainly would not have understood it as I do now without that level of detail. Thank you very much! – sebf Oct 2 '11 at 14:34
• +1 for a good explanation (and diagrams!) of projective space. However, affine space and projective space aren't the same thing (see the Wikipedia definition of affine space). Maybe a good way to say this is: projective 3-space and affine 3-space can both be embedded in R^4, but the embeddings aren't entirely consonant. Encoding vectors from the affine space as w = 0 is possible and useful, but isn't meaningful from the projective point of view. Likewise, projective directions (points at infinity) aren't meaningful from the affine point of view. – Nathan Reed Oct 2 '11 at 17:04

Assume a vector like (x,y,z,w). This vector has 4 components x( x coordinate in space) , y( y coordinate in space), z( z coordinate in space) and the interesting and mysterious w component. Actually most 3d games operate in 4d space.It is also called 4d homogeneous space. There are some obvious benefits of it ->

1> It helps us in combining matrices of translation and rotation into one.But you might be thinking what's the use of it we could just multiply translation and rotation matrix and that's it but no there's more to it.If we don't have the w component in all our vectors then when we multiply the 3d vector(xyz) to the combined matrix of translation and rotation in whatever way we will be unconsciously scaling the values with x,y or z( that's how matrix multiplication operates) and this will probably corrupt the position matrix (translation part of combined matrix) due to scaling.To correct this problem 4th component vector is introduced and this component of the vector(w) will hold value 1.0 in 99% of the cases.This 4th component allow us to have unscaled position values(translation).The matrix is represented as->

 [x y z w] [rx1 rx2 rx3 1]
[ry1 ry2 ry3 1]
[rz1 rz2 rz3 1]
[px  py  pz  1]


and then we have the simple yet powerful matrix. :)

2> We copy the z value into w component in the perspective projection stage and divide the x,y with it.This way objects become shorter as they move away from screen.

• Thank you! I am seeing more and more the necessity of using the fourth component in any truely useful representation of an entity in 3D space. – sebf Oct 2 '11 at 14:34