Quote:Original post by Promit

Quote:Original post by Rockoon1
The OP did not state anything about hardware, nor anything about graphics for that matter.

Neither did I -- it was suggested as a possible explanation by another poster. I'm merely pointing out that hardware has nothing to do with coordinate systems.

Quote:Clearly Microsoft needs to also consider the CPU end of things and we don't know what their conclusions were.

It doesn't matter what end you look at. The coordinate system and the hardware have nothing to do with each other.

You did infact mention both graphics and hardware in your reply to me.


Anyways.. while the hardware game programmers target may not have any preferential issues with coordinate systems.. as soon we actualy pick a coordinate system we are now commited to complex hardware issues which will effect the optimal order of operations in code which uses it. And if this happens to be a library of routines then that order of operations is set in stone after being compiled.

As a very simple example.. a library routine might be responsible for throwing game objects into a 3D array of cells...

cell[x][y][z]

..but if its more or less mostly a 2D game (gameplay mostly happens on the surface of a world) then its suddently folly to use a coordinate convention where Y is up. If Y is up and the array of cells is defined cell[x][y][z] then you are going to be thrashing the L1 cache *bigtime*

But you can use cell[y][x][z], right? Wrong! remember, its a library! Its already compiled.. set in stone.. and nobody wants to set a weird coordinate swizzle like that in stone.

I think you're missing the point - Promit is correct: none of that has anything to do with how graphics hardware works.

In particular, you can use right handed, or left handed coordinates or whatever you like in shader land (which is what everything is now), since the hardware really doesn't need to know anymore (you provide the relevant programs).

Regarding your multidimensional array example: memory layout is completely independent of your coordinate system selection. You can store things however you like regardless of your selection. Even if you are storing volumetric data (which again, could be in any memory layout), it can easily be transformed from object->world space as desired. They're really two totally separate choices.

Quote:Original post by AndyTX
I think you're missing the point - Promit is correct: none of that has anything to do with how graphics hardware works.

I think you both are missing the point.

While the hardware does not take preference to 'coordinate system', it does take preference in regards to algorithm implimentation.

The choice of coordinate system is infact a choice from the subset of the permutation of all coordinate related algorithms. These algorithms range from the simplest (perhaps projection) to the most complex (perhaps piecewise subdivision of polygon soup) ..

The permutation of an algorithm which takes 3 inputs:

f(x,y,z)
f(x,z,y)
f(y,x,z)
f(y,z,x)
f(z,x,y)
f(z,y,x)

In cases where only one or a few of these is optimal due to hardware issues (I've shown a case where this is true), it behooves a project designer to maintain coherence by making a top level choice which lends itself naturally to favor the optimal permutation(s).

In effect, the hardware has influenced the choice of coordinate system... the same hardware that 'doesnt care' about coordinate systems.

Quote:Original post by AndyTX
Regarding your multidimensional array example: memory layout is completely independent of your coordinate system selection.
....snip...
They're really two totally separate choices.

This isnt quite right. Making it independed is a design choice. It can be depended or independed. You can choose to make them a seperate issue, or not.

If you are designing a library, making them a seperate choice has increased the complexity of the library internally or externally. Either the library needs to be told by the caller which swizzle will be optimal, or the caller needs to be told by the library which swizzle is optimal.

If you can make a coordinate system choice which avoids swizzles entirely while maintaining optimality in your library, why would you not?

I'm still not convinced that it matters. The choice of "up, down, left, right, etc." only becomes relevant when rasterizing to the screen (before that, it makes no difference - *all* choices are simply memory layout related). By the time you're rasterizing, there is no advantage in one coordinate basis or another - you'll have to specify it (usually in matrix form) at some point, and one 4x4 matrix is the same as the next to the GPU.

Given your "cell" example, you're simply talking about a 3D array, in which case the same rules apply for choosing your memory access pattern. Your library need not know which direction is "up" - that only matters once you're constructing a view matrix, etc. At that point - as mentioned - anything is as cheap as anything else.

[Edited by - AndyTX on September 19, 2006 3:25:24 PM]

Quote:Original post by Rockoon1

Quote:Original post by AndyTX
I think you're missing the point - Promit is correct: none of that has anything to do with how graphics hardware works.

I think you both are missing the point.

While the hardware does not take preference to 'coordinate system', it does take preference in regards to algorithm implimentation.

The choice of coordinate system is infact a choice from the subset of the permutation of all coordinate related algorithms. These algorithms range from the simplest (perhaps projection) to the most complex (perhaps piecewise subdivision of polygon soup) ..

The permutation of an algorithm which takes 3 inputs:

f(x,y,z)
f(x,z,y)
f(y,x,z)
f(y,z,x)
f(z,x,y)
f(z,y,x)

In cases where only one or a few of these is optimal due to hardware issues (I've shown a case where this is true), it behooves a project designer to maintain coherence by making a top level choice which lends itself naturally to favor the optimal permutation(s).

In effect, the hardware has influenced the choice of coordinate system... the same hardware that 'doesnt care' about coordinate systems.

Quote:Original post by AndyTX
Regarding your multidimensional array example: memory layout is completely independent of your coordinate system selection.
....snip...
They're really two totally separate choices.

This isnt quite right. Making it independed is a design choice. It can be depended or independed. You can choose to make them a seperate issue, or not.

If you are designing a library, making them a seperate choice has increased the complexity of the library internally or externally. Either the library needs to be told by the caller which swizzle will be optimal, or the caller needs to be told by the library which swizzle is optimal.

If you can make a coordinate system choice which avoids swizzles entirely while maintaining optimality in your library, why would you not?

Like some of the previous posters I'm having a hard time understanding how a choice of coordinate system (whether in terms of handedness or 'which way is up') could possibly have any affect on hardware behavior or performance. I realize you've given some examples, but to me at least they seem somewhat unclear. Just for the sake of this discussion, perhaps you could provide a single specific example of what you're talking about, perhaps with a bit of sample code illustrating the point.

As is though I'd have to agree with the other posters that there seems to be some misunderstanding here regarding the relationship between coordinate systems and graphics hardware (although perhaps a clearer example will show that not to be true).

Axis b that points down is more confy for 2D graphic. Snow is falling down, rain too, so you could just add number, and test if the number is higher than terrain/obstacle. The other advantage in 2D graphic is no negative number. "a" points to the right, "b" points down... cliping is trivial.

In 3D probably the worst default choice is the one used in OGL. Center of coordinate system shold be at bottom of the screen, or under. (Of course in space simulations you might find it quite useful, in almost all other genres NOT. And it's especially bad when you are starting with OGL. BTW the most common error for a beginer in OGL is drawing the object behind him. ~_^)