In my video about how to bake cubemap reflections into materials, I refer to the angles of cl_showpos’s readout as XYZ. This is incorrect but I felt like for the video it made the most sense mnemonically since the pos coordinates directly above the angles are laid out as XYZ. In reality the first number in the angles is actually rotation around the camera’s locally aligned Y axis. The second number is rotation around the Z axis, this one may be referenced to local space in some way but I am not sure. Finally the third number is rotation around the camera’s locally aligned X axis (forward), which normally cannot be changed but in gmod you can use the camera tool to rotate the view on this axis. So you see, these three are not XYZ… But PITCH YAW AND ROLL! (WOW Who would have thought!) Yaw is 0 when facing east because the rotation around the Z axis starts at 0 facing locally forward towards positive X in Source. The funny thing about this is that the valve developer wiki article on QAngle someone has complained this is confusing. Hammer Actually lists these 3 angles as YZX which is correct, as they are rotations around those axes. The guy who wrote this goes on to say that “This is completely wrong” which is easily proven incorrect just by loading the game with cl_showpos 1 and moving the camera around or rotating any model in hammer. Just goes to show not everything on there is accurate!
Quake and subsequently Source engine, use the ‘right’ hand Z up coordinate system. Don’t try to think of this using any of the awful diagrams that will pop up when searching for handedness systems. Use the actual hand rule system where you simply make a thumbs up, the curve of your fingers describes the positive rotation around the axis (your thumb). Right hand rule is counter clockwise rotation around the axis. Essentially you make Z your thumb and assign X then Y outwards counter clockwise perpendicular to each other following the direction of rotation. X always is assigned first and is always positive pointing to the right. This works for both left and right handed systems.
Z up right handed, is the only system that really makes sense in 3d world situations, it is in fact the most basic and widely used Cartesian coordinate system. Take some graph paper, plot a line graph. The 0,0 of your X,Y axes will always be on the bottom left of the paper. Congrats you have created a right hand rule Z height(UP) system! Left hand rule is just the inverse of right hand’s Y which means the axes are the same but your 0,0 is at the top left and Y is usually positive when moving to the bottom of the page. In some places people read right to left and I have found a few instances where they graph with 0,0 at the bottom right but in the majority of situations they will still use bottom left. This is probably because most graph making software is set up for the standard system. Having X be positive when moving left is not standard in any system I am aware of.
Look back at your graph paper, the Z axis goes up and away from the paper (height or depth). Imagine your paper extends out in the negative axis directions forming a 2D primary work plane, place an object on the 0,0,0 point and boom you now have a representation of a 3d model in a 3d space system. Looking from the top down you see your X and Y axes. In no sane world would you, looking from the TOP DOWN have X and Z. When it comes to screen space, I can understand Axis polarity flips, a lot of software uses top left as 0,0 for X,Y. This is because of how CRT’s would draw their image and it is still the standard way of addressing a location on a screen. In screen/image space (there are many names for this) the Z axis is away from the plain of the screen’s surface as If it were the paper laying on the table. Depth buffers in games are usually called Z buffers because of this. Even in source you should be familiar with Z CLIP. This only exists in screen space. Source's Z Clip is only Z in screen space, It is X in local camera (view) space and an arbitrary location in world space. Here is a cute little diagram I found that shows why Y is Up when rendering to a screen.
Some people will argue that Y is always used as ‘up’ for “engineering” and ““physics””, these people are loser nerds and should be ignored. If you look at a real map from the top down it will be split into an XY grid pattern. It is well understood that looking at anything from the top down should be mapped as XY as you are looking at the primary plain. There is NO REASON to use Y UP unless you are working in imaginary 2D side view/profile/screen space! LightWave, C4D, After Effects, and Houdini just to name a few all use Y up and what do they have in common? They are more closely tied to 3dVFX, than 3dCAD. LightWave the classic Amiga software used for creating films such as Toy Story. Cinema4D the go-to for 3d motion graphics and rendering 3d environments to static images, also originally for Amiga. Houdini, again designed for VFX use in films...
All of this software is set up to use screen/image space as your working space. This is because this software is more focused on the final image result of what you are seeing through the view of the 'camera' rather than actual 3d objects. You could argue this is true for any video game as well. Imagine Super Mario, X is left/right and Y is up and down right? Well if you were to model Super Mario world in 3D instead of using the screen space coordinate system you would use 3d world space which means Mario would no longer be jumping +Y but +Z. The same goes for games that ARE 3d, like I said before the camera in the 3d world has its own coordinate system that will be applied to the screen. But that does not mean that suddenly the entire 3d world should be flipped on its side because screen space depth is Z.
It almost seems like Y Up is an older standard since the 3dVFX industry has seemingly standardized on that. In Image or screen space it is logical that Y is the vertical axis due to the nature of your screen being just a 2d grid of pixels. However the real truth is that CAD software or even the art of Drafting is a LOT older than the 3dVFX industry. If you are a 3d modeler or environment artist you are basically a 3d drafter. You are creating either a world or things to go inside of a 3d world. Real world Z HEIGHT or DEPTH not imaginary 3dvfx world of image space Y up. Has anyone designed and built a hospital using Maya? Or a bridge using cinema4D?
How DEEP is the ocean and how HIGH is the sky? Your bedroom is not 33 feet high(or deep) it is 33 feet long, unless you have some insanely high ceilings. Z as forward and backwards, or depth into the screen only exists in 2d screen/image space. Most people don’t actually have an issue with this because it is obvious and understandable why things are the way they are, but there are some people who will not stop complaining about how Y up is better even though it logically makes no sense when working in a general 3d space to design 3d objects which will be interacted with in a 3d world. NO 3d Printer or CNC uses Y UP btw.
So back to the angle system why is 0,0,0 on your Source engine angles pointing to the east? In Source’s case it makes more sense when you take into account that the angles are defined 0-180(+/-). This is where I can understand someone saying Y alignment should be 0 degrees. Since +Y is north. But X being 0 degrees also it means you can figure out what ‘hemisphere’ the camera is pointed at simply by checking if its yaw value is positive or negative. Doing a check like this is a lot faster intuitively and programmatically than doing a multi number comparison, as would be required if using a full 360 northern alignment. The alignment of the yaw is actually a much less cut and dry situation than the axis that defines height. In Source 0 degrees yaw is east but in Source’s intermediate model format (SMD) 0 degrees yaw is actually north.
The reason for the likely confusion with cardinal directions in the gmod community is that the vast majority of compass addons will simply use the yaw value as a compass heading. This IS lazy programming but it is smart programming, and in reality most lua programmers are not aware of the correlation between the source engine coordinate system and the yaw axis. Source’s grid is almost akin to a real life alleged 'hemispherical' system with four quadrants. As much as you should never fully trust the developer wiki as any idiot can change stuff, if anyone wants to try and argue that Y+ is not north in Source just send them to this page and tell them to stfu.
People who constantly argue Y up are typically either religious zellots or just are not smart enough to understand why you would use each system in different situations. Anyone who gets any work done in 3d likely understands why something is using z or y up depending on the context and would never waste their time posting on online forums about which axis is up. When looking for diagrams for this article I came across a post that said something like "blender uses Y up for everything else except 3d why dont they just switch it to be Y up for 3d this is so stupid!!" These are the same kinds of idiots who think the metric system is the only system that should be used no matter what.