# X, Y, Z coordinate standards?

I'm pretty new to 3D development of any kind, nonetheless games. As I read through tutorials and examples, I find that the X/Y/Z coordinates seem a bit backwards than my first guess.

I had imagined that if a person were walking around a field, their X/Y position would be changing and if they were to jump or walk up or down a hill, then their Z position would be changing. My assumptions appear to be wrong because walking around a field seems to change X/Z and jumping or going up/down a hill alters the Y.

1) Are my observations correct? 3D is new to me and I may not be thinking about things properly.

2) What's the logic behind horizontal movement being X/Z and vertical movement being Y?

3) Would it be so wrong of me to use X/Y as horizontal movement and Z as vertical movement in the XNA Framework?

-
Left/Right Hand Coordinate Systems. DirectX is left hand, the default in OpenGL is right hand. – Jonathan Connell Jul 5 '11 at 14:28

Your assumptions aren't wrong: each engine treats these coordinates differently. Generally speaking X is almost always the East-West axis but whether Y or Z is the Altitude axis tends to vary. As I understand it, Quake 3, the Source Engine, and the Torque engine all have Z as up. So does the modelling tool 3DS Max. It's not uncommon.

It makes sense to have a coordinate system that is ordered roughly in descending order of importance, so that flattening a representation into fewer dimensions is easier to understand. For example, if your game is set on a 2D height map, it makes sense for Z to be 'up', because then your X and Y coordinates in the 3D world map directly to the X and Y coordinates on the height map. On the other hand, if you think primarily in terms of rendering (and many game engine developers do), you're used to X and Y being the screen coordinates, so adding a 3rd axis naturally goes in or out of the screen.

Use what is easiest for you, but be aware that any choice is arbitrary and that you may need to convert between them and use multiple coordinate systems within one program.

-
I actually like the other two answers better, but since this is the accepted answer, a note to point out that the Y being vertical and Z being into the screen is the way most 3D hardware APIs are set up to work (DirectX and OpenGL). If you want your own system, just be aware of this as some translation may be required. (Something used improperly but consistently can often work as desired, hence the 'may be' :)) – James Jun 9 '11 at 23:03
Technically OpenGL has Z coming out of the screen by default, when you include the direction, so although both it and DirectX have Z parallel to the viewing direction, they're still incompatible! When working with 3D you need to be competent at going from one coordinate system to another via rotations, translations, and scaling - indeed, this is how models end up in the world - so there's not much point getting too attached to any notion of a standard. – Kylotan Jun 10 '11 at 1:44
Just pointing out then when dealing with millions of triangles, maybe the less you have to do to fight the hardware's coordiante system maybe the better ;) End of the day, making games is fun despite the stress levels.. Do what you want to :) – James Jun 10 '11 at 4:55
The notion of "Z" as going into/out of the screen or being altitude is somewhat misleading. It might just be easier to conceptualize the transformations. We submit 3D/4D vertex coordinates which are transformed eventually to 2D window space but with a depth value. The idea that an API inherently maps the 3D coordinates of X, Y, or Z to "depth" is not really correct -- you can come up with any transformation that interchanges the meaning of the coordinates. At the end of that transformation, you'll still get 2D window space coordinates and a depth value. – PatrickB Jun 11 '11 at 6:09
I'm not entirely sure where we disagree on the rest though: of course you could use any coordinate space you wanted as long as you can project to x,y,depth in the end, but this question is primarily about why certain conventions exist for coordinate systems, and the conventions are inevitably linked to real-world concepts. – Kylotan Jun 11 '11 at 11:47

Imagine looking at a piece of paper held out in front of you with a chart on it, the axes are typically labeled X across the bottom and Y up the vertical; this leaves Z to be the outwards axis along the ground.

It's merely a convention, but it's used a lot in graphics where we think of Z as the depth into the scene.

-

The idea is that the x and y axes stay the same - y is 'up' on the screen, and x is across.

z - the third dimension, projects back into the screen (ignoring the issues of handedness here). In 3 dimensions this gets a bit odd, but for positioning things in screen space it makes more sense.

3) You can if you want, but it would be painful and clunky. I would advise just to get used to the Z-projects-into/out of-the-monitor.

-

1) Yes your observations are correct.

2) The standard global XYZ coordinate system makes sense when you think in terms of a first person shooter, when you are looking through the eyes of a character in the scene with a blank(identity) transformation matrix. Like it would when you draw a coordinate system on a piece of paper, X points to right and Y points upwards. According to the right hand rule (x->thumb, y->index finger, z->middle finger), Z points towards you.

3) It wouldn't be wrong, but it would be a diversion from standards. There are three problems that I can think of at the moment: (a) Let's say one day you want to use a physics library that uses the standard coordinate frame. If you did not follow the standard, now you have to think about the transformation that takes you from your world to the physics world. Can get annoying when you want to fix a bug. (b) When you want to share code with someone, or bring someone over to help with development, they have to get used to your convention. (c) When using standard 3D models, you always have to have a transformation above them to prevent them from looking sideways.

Now to add to question 2, it is sooo useful to think of X, Y, and Z as not just three letters, but as right, up and backwards. Every character in the scene has a local coordinate system attached to them, and in their local coordinate frames X is always right, Y is up and Z is backwards. Once you have this, now you can make sense of vectors that you print out, or write your algorithms in a way that makes sense. Let's say you have two characters A and B, and you want to do something if one of them is facing the other. You can simply find B's location in A's coordinate frame (Ta^-1 * p_b), look at the vector you get and see if Z(backwards) is negative and X(right) and Y(up) are small, because that vector tells you how much backwards, right and up B is with respect to A.

-