why did they decide to point Z up in quake?

Z up is the most straightforward thing. I don't get it at all, why should that be otherwise (but it is, I just don't get it).

Just an example: you can use 2D vector operations in the horizontal plane with the 3D vectors: the 2D functions can simply use the first two elements. You don't need to copy the x,y elements to another vecto just to be able to operate on it. And since Quake was coded in C, they couldn't just use a constructor in the parameters of a function.

Another example: 3Ds Max, and I guess other model editors (and design programs like CAD systems) also threat Z as the up vector.

So the more interesting question is why should that be otherwise?

well couldnt u still do the 2D functions u r talking about with the Y up?
y is up
x is to the right
z is the new dimention
so y would it take place of y lol

It's not weird, it's just a convention. Z being up is a result of Quake 3 using a righthanded coordinate system. If I remember correctly the Q3 coordinate system has +X pointing forward, +Y pointing left and + Z pointing up. Though that could very well be Q2 and Q3 is using +X right, +Y forward and +Z up. It's been too long since I've worked with either code bases

[edit]

Realised that this could be misleading people a bit. It's not because the coordinate system is righthanded that Z points up, but because of how the X and Y axes are laid out that forces Z to point up in a right handed coordinate system.

do u know which is up in valve source games?
im still messing with quake3 levels
cause i dun kno how to render edges vs vertices

do u know which is up in valve source games?
im still messing with quake3 levels
cause i dun kno how to render edges vs vertices

HL2 uses a standard righthanded coordinate system if I remember correctly. +X right, +Y forward and +Z up. Best to double check this in the SDK though.

x,y,z is in this sequence in your data, right?
if x-z is the horizontal plane, right?
you want to do many 2D stuff in that plane, right?
but x,z are not in sequence in your data, so you can't use them as they are, you have to copy them to a temporary 2D, right?

Maybe you can write all your 2D functions so that they operate with all three coordinates and never really use the second coordinate, sure. I guess many programs do that.

But why? What is the benefit of making y up? Maybe because Blender has y up (I'm not sure)?

In reality; it doesn't matter.

If you take a tradional 2D grid placed on the screen then you have X,Y locations, therefore for many people Z going 'into' the screen/scene is a natural extension of this system.

If your plane is flat to the screen then X,Y makes sense from a 2D point of view and you don't need to 'ignore' anything; I'm not even sure how you came to the conclusion that you would have to.
If you wanted to perform a 2D operation on a 3D plane you still need all 3 coords to reference the correct point on the plane.

So, in short; as long as you are consistant it doesn't matter.

(Although, as I like to say; get back to me when they call it a Y-Buffer )

Z up is the most straightforward thing. I don't get it at all, why should that be otherwise (but it is, I just don't get it).

Just an example: you can use 2D vector operations in the horizontal plane with the 3D vectors: the 2D functions can simply use the first two elements. You don't need to copy the x,y elements to another vecto just to be able to operate on it. And since Quake was coded in C, they couldn't just use a constructor in the parameters of a function.

Another example: 3Ds Max, and I guess other model editors (and design programs like CAD systems) also threat Z as the up vector.

So the more interesting question is why should that be otherwise?

+1.

are there any other games weirded out like this?

I've had to argue this point on other forums as well :| The fact is, it's not weirded out at all. In fact, z-up is common in games, modeling applications, and some non-game-oriented disciplines.

I think people get stuck on the idea of y being up because in the graphics APIs most of us are accustomed to, y is up in view space. What people seem to miss though is that view space and world space are two different things, and there's no reason they have to use the same axis orientation.

A good example would be a '2.5-d' RTS, where the gameplay is essentially 2-d but the graphics are 3-d. Expressing all the game logic in terms of x and z complicates things for no good reason. Instead, you can make z up, express the game logic in the XY plane, and orient the camera however you want. (Y is still up in the camera's own view space, but that has no effect on which axis is up in world space.)

I suspect Z is the vertical axis in Quake for similar reasons; that is, the game logic expresses itself more naturally in terms of a ground plane (XY) and an extra 'height' dimension (Z).

Maybe because Blender has y up (I'm not sure)?

Actually, I think z is up in Blender (at least by default).

In reality; it doesn't matter.

Also +1. You can use whatever convention meets your needs and makes the most sense to you.

(Although, as I like to say; get back to me when they call it a Y-Buffer ;))
[/quote]
Well, as I mentioned earlier, the fact that y is up and z is depth in view space isn't really relevant to the discussion (in that there's no particular reason view space and world space have to be oriented in the same way).

are there any other games weirded out like this?

It's not weirded out. There was no standard, people just made their own choices that differed.

It's also just a point of view thing. If you think of your logic as top-down (despite how you render it), Z on the vertical axis is still in and out of the screen.

Quake evolved from Doom. And Doom had top down logic with no height. Despite how the level was drawn, it all took place on a flat plane. You could be at the top of a platform 500 feet high and still shoot the enemy in front of the platform 500 feet below, because the game had no height, you were just shooting in a direction. So when Quake came out, the levels could still be thought of as top down, but with the difference that you could now have sectors on top of each other. So Z is both up/down, AND in and out of the screen at the same time.

What you sim and what you render are not necessarily the same.

z is up in blender. xz as ground plane has always felt more natural to me. Thinking of how a graph would look, you have an x axis going across the bottom and the y value going up. Expand to 3d and z points forward (left handed then) Of course if you think of a 2d top down game then xy horizontal makes sense, expanding to 3d and you have z as up. Both make sense and theres no reason why they shouldn't,

Z is up as convention in pretty much all textbooks that focus on it (rather than extending the concept of 2d outwards). Physics, higher level calc, etc.

with z being up all maps are sipmle x/y 2d. with maps i mean real maps, like google maps/bing maps. your village/city you life in has x/y maps, and z being up.

I am suprised no one has mentioned it yet; Draw a 2D coordinate system on a piece of paper. Now add the third dimension Z. Where does it point? Thats right, it points up, out of the paper

I am suprised no one has mentioned it yet; Draw a 2D coordinate system on a piece of paper. Now add the third dimension Z. Where does it point? Thats right, it points up, out of the paper

Yeah. That doesn't hold for a white-board though...

I'm with phantom on the Y-buffer thing.

I am suprised no one has mentioned it yet; Draw a 2D coordinate system on a piece of paper. Now add the third dimension Z. Where does it point? Thats right, it points up, out of the paper

I disagree. Draw a 2d coordinate system. Most people would say that X points right, and Y points up. Hence why when you add a Z axis, I would say it points towards you, not UP.


Besides, most commonly in graphics API, Y is considered up. But that doesn't mean anything because you can orient the camera anyway you want, making 'up' a moot definition.

Someone mentioned simplified math on the horizontal plane. How is it simplified? You're either going to be doing operations on the 3d vector's members, or you'll use those to create a 2d vector. either way, you have to do the same amount of math.

Also, I have no freakin clue why Quake would pick Z as up, but it doesn't make that big of a difference.

well.. z is always the 3rd one. on a screen based system, x and y where right and up, so z ment into/out of. on a map, x and y are horizontal on the table, so z ment height.

and as most artists are not tech-geeks, they don't care about the screen based system, but about the map based systems. a village is not a vertically aranged thing, but a horizontal aranged thing, with things that have height.

In math and physics, without other context, Z points up.

For specific problems, coordinate system is oriented to a way that is most convenient.

A 1D problem has x axis.
A 2D problem is done in xy plane.

How are physical things modelled in 3D? Think of a floor plan. It's drawn in a plane and walls are extruded upwards. So xy is already drawn, the z is added.

I always found Z going into screen completely confusing. The reasoning is - (xy) are same axis as screen coordinates and z goes into screen. Which is all fine and dandy as long as one is trying to make a Doom clone. In real world, camera tilts, shifts, stands on a ceiling - there are no screen coordinates. It's not camera that defines the world.

Altitude of an aircraft, for example, is Z. Simply because an aircraft can go in XYZ while a tank can go in XY only. And labels remain consecutive letters.

Similar debates were about how to label 2D screens. Typically, x goes to the right and y goes up, with (0,0) being either in center or in bottom left. Some image formats stored data like that. Here the engineers defined the convention. Since screens render top to bottom, left to right, the simplest way to scan memory was just that, 0 being in top left, and to simplify calculation, the Y axis was reversed.

Well, not understanding the vector thing means you don't code in C... if you have an array of 3 values, and you have a 2D function with arguments as pointers (what else), you can just plug your array into the 2D function. If you use Y as up, you can't do that since you would have to use the 0 and 2 elements. You have to make a temporary array.

heightmap: Most of the time you have to look for the indices of the height map: in the horizontal plane. That means 2D calculations. I can convert x-y easily to indices on a heightmap for example using vectors (the array stuff). Calculating indices is a lot of 2D calculations. Why should I use separate functions for 2D operations in 3D and in 2D (which is probably x-y)? Or making everything 3D just to make every calculations 3D?

Okay, It's not a real issue, but anyway, I only see disadvantages of Y being up (compatibility with most modelling programs, papers, books), but no advantages. It's just a matter of choice, but for me, Z up makes everything much easier and less error prone (okay, the last is pure preference)

Well, not understanding the vector thing means you don't code in C... if you have an array of 3 values, and you have a 2D function with arguments as pointers (what else), you can just plug your array into the 2D function. If you use Y as up, you can't do that since you would have to use the 0 and 2 elements. You have to make a temporary array.

Eh? You aren't making sense.

If your entries in the array have 3 values then you still need to step 3 values to get to the next set of data, so if you take elements [0,1] or [0,2] makes no differences. It's not even an optimisation thing because CPUs read data in chunks so all elements are just as likely to be in the cache thus just as likely to be fast to access.
(And, frankly, if your arguement WAS going to include performance I would just tell you that you are Doing It Wrong[sup]tm[/sup] anyway; SoA is more performance friendly for things like CPU processed data via SSE so each component would exist in its own memory block anyway meaning you could plug whichever memory blocks you wanted into the function and have it do The Right Thing[sup]tm[/sup].)

So, no, you wouldn't need a temp array if you are plugging 3 component values into a function which works on only two of them.

heightmap: Most of the time you have to look for the indices of the height map: in the horizontal plane. That means 2D calculations. I can convert x-y easily to indices on a heightmap for example using vectors (the array stuff). Calculating indices is a lot of 2D calculations. Why should I use separate functions for 2D operations in 3D and in 2D (which is probably x-y)? Or making everything 3D just to make every calculations 3D?

Okay, It's not a real issue, but anyway, I only see disadvantages of Y being up (compatibility with most modelling programs, papers, books), but no advantages. It's just a matter of choice, but for me, Z up makes everything much easier and less error prone (okay, the last is pure preference)
[/quote]

Fun fact; our game at work uses terrain on a X/Z plane with Y being elevation.

It works fine; there is no confusion between art resources and in game resources at all. Artist model how they want, we display how we want, the pipeline takes care of any conversion issues.