Convention for labelling coordinate axes in 3d graphics

Question

When I recently started doing some 3d graphics, I carefully (tried to be careful, anyway) decided to use the conventional mathematical standard for labelling axes, which was much more convenient for "doing the math" in this pretty math-heavy problem domain. And to try to avoid any confusion, I even included an ascii comment block drawing in the code, something like this

        z.             As per usual spherical polar coords,
        |  .                 x   = r*sin(phi)*cos(theta)
        |    .               y   = r*sin(phi)*sin(theta)
        |      .             z   = r*cos(phi)
        |        o(x,y,z)    r^2 = x^2 + y^2 + z^2
        |      . |           h   = r*sin(phi)
        |phi .   |
        |  .r    |
        |.       |
        +--------|---y
       /   .h    |  /
      /theta .   | /
     /         . |/
    x------------+

to remind myself what goes where when calculating components for

/* ---
 * Point, line, quaternion datatypes/structs
 * ----------------------------------------------------------------------- */
#define POINT struct point_struct       /* "typedef" for point_struct*/
#define LINE  struct line_struct        /* "typedef" for line_struct*/
#define QUAT  struct quaternion_struct  /* "typedef" for quaternion_struct */
POINT   { double x, y, z; } ;           /* 3d pts (2d uses x,y components) */
LINE    { POINT pt1, pt2; } ;           /* for vectors, pt1=tail, pt2=head */
QUAT    { double q0, q1, q2, q3; } ;    /* quat = q0 + q1*i + q2*j + q3*k */

However, on a few occasions I absent-mindedly reverted to the convention I'd become more accustomed to programming, mostly in 2d without any z at all,

        y
        |
        |
        |
        |
        |
        |
        +-----------x
       /
      /
     /
    z

Needless to say, lots of time wasted debugging until I realized what the problem actually was. And then (which is now), I tried googling stuff like https://www.cs.uic.edu/~jbell/CourseNotes/ComputerGraphics/Coordinates.html to determine some "industry standard" convention, and particularly some >>rationale<< behind it that won't slip my mind while coding. So that page seems to suggest the z-axis-out-of-screen (bottom drawing) convention. But I'm not googling any actual standard about it. Is there such a thing, hopefully along with some reasoning why one's better than the other?

Answer 1

Its been a few years since I implemented my software renderer but I still remember that there is no standard. X is usually fixed and y/z are random. That is why for some model importers the coordinates need to be adjusted to the format you are using!

I came across this problem once I started implementing different renderers for various 3d model formats. In my head, x was pointing right, y up and z out of the screen. Then I noticed that the models were off. Thats how I learnt about it!

Its been years, perhaps the 3d scene has come to an agreement / standard on this issue, I dont know. I can imagine one reason for this mess though: Convention vs optimization. Convenation as in, people might be used to x-right, y-up, z-out whereas optimization forces people to use it the other way around, x, z, y because the assembler opcodes that parallelise vec4 calculations (names escaping me right now) might have their implementation focus on the x, z, y order because it might lead to less remapping for specific formulae required in the 3d domain! Might be completely off though, I am just guessing here. Sadly, cant imagine why else!

Hope this was helpful! Good luck finding the answer!

Answer 2

I am no expert on the subject but I found you a reference that might help.

The reason for using either a left handed co-ordinate system or a right handed co-ordinate system may be historical, cultural, technical or arbitrary. X to the right and Y up is pretty standard though in 3D graphics land.

Historical

Some older, popular 3D engine uses one system so you may want to follow it.

Cultural

If you come from drawing on paper laying flat on a desk, you will likely consider x to the right, y away from you and z up.

Technical

In the old days when we had CRT screens it could make a difference which parts of the screen were rendered first. The picture on the screen would be build from top to bottom and from left to right. If you had a frame buffer, lower memory locations would map to higher and lefter screen pixels. The direction in which you rendered could cause or prevent flicker.

To me the right hand rule is hardly helpful and just adds to the confusion. Just remember when people speak of left handed the Z axis goes into the screen and with right handed it comes out of the screen.

Answer 3

Working in VFX, I'd echo the conclusion that there isn't really a standard. It's all over the place with the various software out there. I'd say you're doing all right if you can at least establish your own and stick to it.

As far as left-handed or right-handed coordinate systems, with all the popular 3D software out there ranging from like Unreal Engine to Unity to Marmoset to Maya to 3DS Max to XSI to Blender, it's rather split in my experience with no strong signs of convergence. I think right-handed might be ever so-slightly common in what I've encountered (in terms of world space), but not to the point where I'd even declare it de-facto standard.

When it comes to Y/Z in world space, it is more common in my experience to see Y pointing up/down (vertical) and Z pointing in/out (depth). I suspect the mindset there is to label the world in terms of the initial viewing plane in front view. Yet there are some big dogs like 3DS Max who use Z for vertical, perhaps with the mindset of thinking of world space axis labeling in terms of the ground plane.

Needless to say, lots of time wasted debugging until I realized what the problem actually was.

For this type of thing, and as one who isn't the type to debug code and start drawing out mathematical notes and diagrams on drawing boards figuring out where I went wrong (I envy people who have the patience and mindset to do this, however), I found it very helpful to have like a "visual debug" library where I can temporarily draw lines and planes and axes and so forth (like old school debugging with printf output to figure out where we went wrong, only with visual outputs to the viewport). It requires some patience of its own as well, but I find it immensely useful in these cases. I've often found with algorithms heavy on the linear algebra that crawling is faster than running and falling into a ditch, to test every single function's visual output for correctness as we're trying to implement something complex. It's like "visual TDD", since I'm often lacking in the smarts to verify correctness in elaborate mathematical ways in these cases short of just seeing if it gives the correct visual output.

A small sample of my own little notes and "visual babystepping" (I have hundreds of these), and if I'm working from a paper I actually try to match their own diagrams of the intermediate steps of the algorithm to verify that I'm implementing it correctly so far. I have little functions like db_line (draw a debugging line into viewport) along with similar functions to draw labels and points and axes and planes and matrix coordinate systems and such.

Also getting a bit fancy but I tend to prototype these things in script and made it so I can trace through the script line by line and plot what it's doing, one step-at-a-time, into a "debug watch viewport" where I can pan and rotate and zoom around while the script is at a breakpoint to visually examine results as well as plot new things while the script is halted. That might seem a bit overengineered but it was only through building and leaning on tools like this that I was ever able to keep up with the mathematical wizards in my industry. Otherwise I'm the type where if I'm asked to implement an IK solver on a motion hierarchy, I might get the initial implementation 99% correct on the first day only to spend the remainder of the entire week trying to figure out the 1% place where I went wrong in hindsight; with this I can catch those mistakes as I'm making them usually and save so much time.

It's like if I'm trying to test out a complex transformation involving multiple coordinate systems and paths and objects, then I can write a proper automate unit test verifying that the object ends up in the correct place after that series of transformations. But if something goes wrong in the implementation of whatever interface I'm testing and the test fails, I just lack the smarts to debug it without visualizing what's going on. So for me at least, it's so helpful to develop these algorithms in tiny little babysteps where we visually output the result of each little function we write for correctness.

Otherwise if something went wrong, I'd find myself staring at a boatload of numbers in the debugger that look like gibberish to me unless I actually start manually plotting things like points and lines and such on the drawing board, at which point it becomes a lot simpler to just let the computer do that for me and see where I went wrong. So this second part of the answer is not as directly related to your immediate question relating to standards, but I figure it might help for what you're trying to avoid which is spending ages trying to figure out where you went wrong (which is something I find all too common in this domain if we don't kind of test each little teeny step individually).