Personally, I've never found it necessary to be fully grounded in the basics before diving in. An excellent method of learning those basics is by doing and reading as I go, rather than reading alone until I understand. And the ever-present reference manual known as the internet makes it unnecessary to know all of the basics 100% by rote. I think a few of the analogies presented in this thread are a bit overblown, to be honest. Not knowing how homogeneous coordinates work is nowhere near as drastic as not knowing how a steering wheel works. At worst, it's more like not knowing what the turn-signal does. You can still do a lot of driving, and even when turning you will probably for the most part be fine, until that fateful day when you get pulled over for not signalling your turn, the cop finds your cousin Ron's stash of green in the trunk, and you get tossed in the pokey overnight until your folks scratch together the bail money. (Okay, so maybe even that particular analogy isn't all that accurate, either.)

The thing about homogeneous coordinates and other things is that yes, you should know them. But knowing about them really only applies to a very small part of your experience in writing a 3D framework; once you've written your projection matrix generation code and, possibly, a few other things you can mostly forget about them. In fact, if you use certain modern 3D frameworks that handle that stuff for you, you really don't need to know about them at all. Similarly with things such as quaternions. I wrote my first 3D game using quaternion and projection matrix code garnered from elsewhere, didn't have a clue how those things really worked, and managed to get by okay until I did know. The gritty internals of homogeneous coordinates, quaternions, projection matrices, transformations and so on can be safely abstracted away so that the end user doesn't need to mess with them.

If you're writing a 3D framework/engine, yes you should spend the time to know the details. If you are just using a 3D framework to build a game, maybe you can get away with a rough, basic familiarity. If you strive for mastery of every little detail, you just won't get anywhere.

A person can't use a graphics api if they don't know what homogenous coordinates are??? I guess I should have told myself that before I did this.

I feel I should point out that I've built this from scratch without using any pre-made game engine and I've got it working on both Windows and iOS, so far, and I don't have a clue what homogenous means, not even when talking about milk.

You divide the x, y, z values by the w component to get the position in 3D space which is embedded in the 4D projective homogeneous space.

So (x, y, z, w) = (1, 1, 1, 1) and (x, y, z, w) = (2, 2, 2, 2) both refer to the same point in 3D space, (1, 1, 1).

For direction vectors, w is 0, which would cause division by zero. These correspond to points at infinity in 3D space in the direction of the x, y, z components.

That's basically it in a nutshell.

4D coordinates are used because you can represent any affine transform in 3D space with a (4x4) matrix. You can't do that in 3D space because the origin of 3D space (0, 0, 0) always maps to the origin after being transformed by a matrix (so translations are impossible in 3D space using just a matrix).

That doesn't happen in homogeneous 4D space since the origin of 3D space is represented by (0, 0, 0, 1) [or (0, 0, 0, w) for w != 0].

(0, 0, 0, 0) doesn't correspond to to any point or direction in 3D space, and is not a valid value for 4D homogeneous projective space.

So 4D vectors (x, y, z, w) with w != 0 corresponds to all points in 3D space and all directions ("points at infinity") in 3D space as well.

Hope that helps.

ummmmm, Hulk says "Scaling 'w' makes things bigger and smaller."

Yes, if you only scale the w component and not the x, y and z components.

(EDIT: HULK SPEAK IN CAPITAL LETTERS ONLY TOO!)

For the longest time I was content to think that 'w' was just added to vector processors to fill in the extra value in the set of four to match the four values neccessary for color. From all this I've gathered that 'w' is neccessary to make the perspective matrix work. So if I were to carry this logic further I would surmise that 'w' is scaled down by the projection matrix math for vertices that are further back and scaled up for objects that are closer to give the illusion of depth. Thus we have perspective on the matter!

Out of all of the conjecture and philosophical discussion (which is also important...) nobody answered the original question from the OP. He wants to know why his w value is initialized to 1 when he only has a XYZ format for his vertex information. Its been really long since I worked with D3D9, so I couldn't say off the top of my head why that is. Can you describe how you managed to determine that the value is 1?

Regarding the debate, I can also confirm that I ran for a long time without really understanding what w really was doing. However, I agree with JTippets that the steering wheel analogy doesn't quite fit. Without knowing w, but still knowing how to use matrix functions roughly, you can get a bunch of work done. It is like being able to drive without understanding how an engine works. Sooner or later, when your engine breaks down, you better know the ins and outs of how it should work, or you won't have any chance to fix it. But until then, you can drive pretty far.