Malmer

I still don't understand the intent of not using DirectX's left handed coordinate system. I thought it made sence at first, since OpenGL uses a right handed coordinate system.It would open up for easier porting of OpenGL code and interop integration with OpenGL libraries. Now I would prefer to have things the same way as DirectX so that I can easily use libraries and code from DirectX, but that's me. I can still say that all is good and a right handed system is just fine.

But then I notice that matrices in XNA use row major representation, just like DirectX and not like OpenGL's column major matrices. Now it is only a matter of the order you multiply your matrices in and it really doesn't matter which one you use as long as you know which is which. Now if one were to use a library designed for OpenGL then one assumes column-major matrices and would have transpose them when wrapping them to XNA even though naturally one would assume they would be the same since XNA flipped coordinate system for this reason alone.

The above will work, but what is the point XNA isn't like DirectX and it is not like OpenGL. It is not even the most efficient (column major matrices generate less instructions when compiling HLSL shaders).

Why not stick with left handed coordinate system and row major matrices like in DirectX or go all in on OpenGL and do right handed coordinate systems and column major matrices. As it is now it is stuck in the middle for no reason (only I can think of is that row-major matrices are somewhat easier in that pre-multiplies are to the left).

Or am I missing something...



Re: XNA Framework Coordinate system and matrix inconsitencies

AndyL

Dont forget that because the Matrix elements are struct fields, the data can be stored in memory in row or column major order, simply by changing the field offsets in the matrix (and leaving the names the same) - which actually leaves with a situation where they are that way round just for us humans reading them- and the opposite of how matrix elements are actually named!



Re: XNA Framework Coordinate system and matrix inconsitencies

Shawn Hargreaves - MSFT

OpenGL and Direct3D aren't the only environments out there to be compatible with: there is also the Avalon infrastructure (now known as WPF) which is going to be increasingly important in the managed world.

Really this is one of those areas where it just isn't possible to be compatible with everyone, because everyone does things in different ways, so we just had to pick one and at least try to make everything consistent inside our own framework.

HLSL shaders don't require matrices to be the same way around as they are on the CPU side, btw. HLSL allows matrices to be specified with either layout, and the effect system will efficiently transpose the data as required when setting values from the CPU.





Re: XNA Framework Coordinate system and matrix inconsitencies

Jon Watte

Shawn Hargreaves - MSFT wrote:
Really this is one of those areas where it just isn't possible to be compatible with everyone, because everyone does things in different ways, so we just had to pick one and at least try to make everything consistent inside our own framework.


But you didn't really end up being consistent, because you multiply quaternion rotations in a different order than you multiply matrix rotations.






Re: XNA Framework Coordinate system and matrix inconsitencies

qrli

 Jon Watte wrote:
Shawn Hargreaves - MSFT wrote:
Really this is one of those areas where it just isn't possible to be compatible with everyone, because everyone does things in different ways, so we just had to pick one and at least try to make everything consistent inside our own framework.


But you didn't really end up being consistent, because you multiply quaternion rotations in a different order than you multiply matrix rotations.



I remember that quaternions are multiplied in the same order as matrices, though the "Getting Started" section in DX doc tells in the math order.

For the reason of using row-major matrix, I remember it is because of speed benefit and the same associativitye with scaler * operator.




Re: XNA Framework Coordinate system and matrix inconsitencies

Malmer

 Shawn Hargreaves - MSFT wrote:
HLSL shaders don't require matrices to be the same way around as they are on the CPU side, btw. HLSL allows matrices to be specified with either layout, and the effect system will efficiently transpose the data as required when setting values from the CPU.

And how will it be transposed by default if not specified in the .fx file Column major or row-major column major results in fewer instructions, but will mean a different multiplication order when writing the shader from what is used in XNA. So I guess  the default will be row-major there aswell to make it consistent with the api. True It would make sence. Or does it use the HLSL default with column major Anyways...here it is not a problem since one can do as one pleases with a #pragma directive in HLSL.

Personally I would have prefered it all to be the same as DirectX. Left handed and row-major. And since XNA is targeted towards making games I don't see the point in doing like WPF rather than doing like DirectX. People will not read articles on how to program 3d-graphics in WPF when they want to make something in a game. They will go to a game dev site and read how they do it in directx or opengl (or general 3d math). And I don't see the 3d parts of WPF and XNA in the same app. I do understand that people could be coding separately to the two platforms, while DirectX is more "hardcore".

One can question why WPF is different from DirectX. Had they made WPF and XNA like directX then all microsoft products would be the same and the world would be better for it. Exporting tools would work with all platforms if they worked with one etc. Now there are three major coordinate/matrix variations for developers: 1) DirectX, 2) OpenGL 3) XNA/WPF. It could have been just two...

Now I really like XNA and love WPF, but things like this makes a man pull his hair out.

Side note:
What would rock was if one could mix the 2d parts of wpf with xna so that it could be mixed with xna graphics (with a changeable z-buffer depth to allow things to go infront off WPF).





Re: XNA Framework Coordinate system and matrix inconsitencies

Malmer

qrli wrote:
Jon Watte wrote:
Shawn Hargreaves - MSFT wrote:
Really this is one of those areas where it just isn't possible to be compatible with everyone, because everyone does things in different ways, so we just had to pick one and at least try to make everything consistent inside our own framework.


But you didn't really end up being consistent, because you multiply quaternion rotations in a different order than you multiply matrix rotations.



I remember that quaternions are multiplied in the same order as matrices, though the "Getting Started" section in DX doc tells in the math order.

Actually that is a bug in XNA. If you multiply quaternions in the same order as matrices you get the wrong result. Has been pointed out on this forum before.





Re: XNA Framework Coordinate system and matrix inconsitencies

Flavious

 Malmer wrote:
And how will it be transposed by default if not specified in the .fx file Column major or row-major

Column major, I think; construct by rows but pack by columns.

Personally I would have prefered it all to be the same as DirectX. Left handed and row-major.

Yes, I understand that argument. But I have also thought it a little strange that graphics has broken with mathematical conventions for apparently no other reason than to have a positive "right" vector. I suppose it could be a coincidence

By the way, I use the same layout for both OpenGL and D3D. The only caveat that I'm aware of is that of the view volume difference, z in [-1,1] for OpenGL, [0,1] in D3D; but this is easily--if not conveniently--remedied with a suitable change of projection matrix.





Re: XNA Framework Coordinate system and matrix inconsitencies

qrli

It's hard to tell how much the diversity is. I've used a few OpenGL engines with row-major matrix, including OpenInventor. And I was very surprised that my textbook teach row-major matrix because I learned OpenGL before that. I have also seen engines with X pointing left so as to let Z point front.

I like right-handed more because it is the same convention as in math. I prefer row-major for performance reason, but column-major is faster in shaders. Well, the world is always in trouble.




Re: XNA Framework Coordinate system and matrix inconsitencies

Malmer

So I guess what we really need are no handedness in coordinate systems and diagonal major matrices and everyone will be happy... :-)

I guess we'll just take the world as it is and be happy that we even got such a nice little API such as XNA, because it truely is really nice to work with and even though we all see things we miss or want different many of us really like what the team has done and are quite impressed on the ease of use.

Now we just long for the next release where all the math routines we miss are there, BoundingXYZ implement a common interface, the Plane class actually has som useful methods, quaternion multiplications happen in the same order as matrices and with documentation that says a little bit more than "DoStuff() - Does stuff". :-)

Until then we'll just love what we got so far and scream in terror over what we don't have in it.





Re: XNA Framework Coordinate system and matrix inconsitencies

Jon Watte

Actually that is a bug in XNA.

Actually, they claim this works as designed, because someone who "knows quaternions" would be confused when they swapped the multiplication order. I think that argument holds as much water as saying someone who "understands matrices" would be confused by the row-vector convention they've chosen to adopt -- the "Mathematical" definition is using column vectors on the right. I happen to think row vectors are more natural, so that's the right choice for matrices IMO -- the same choice should be done for quats, too. Of course, this would be a lot clearer to users of the API if they actually had a native vector-by-quaternion multiplication operator implemented (see separate post :-)

The end result is that we will have to live with multiplying quaternions backwards from matrices in XNA forever -- it didn't change for 1.0, and the team has made it clear that they're not listening to new feedback on this point.






Re: XNA Framework Coordinate system and matrix inconsitencies

qrli

Jon Watte wrote:
Actually that is a bug in XNA.

Actually, they claim this works as designed, because someone who "knows quaternions" would be confused when they swapped the multiplication order. I think that argument holds as much water as saying someone who "understands matrices" would be confused by the row-vector convention they've chosen to adopt -- the "Mathematical" definition is using column vectors on the right. I happen to think row vectors are more natural, so that's the right choice for matrices IMO -- the same choice should be done for quats, too. Of course, this would be a lot clearer to users of the API if they actually had a native vector-by-quaternion multiplication operator implemented (see separate post :-)

The end result is that we will have to live with multiplying quaternions backwards from matrices in XNA forever -- it didn't change for 1.0, and the team has made it clear that they're not listening to new feedback on this point.



My god, is that true If so this can be another historical event like the left-handed system in D3D.




Re: XNA Framework Coordinate system and matrix inconsitencies

Jon Watte

I do not post things I do not believe to be true.

Btw: Choosing left-handed systems for DirectX was not entirely unheard of -- computer graphics has traditionally been done left-handedly for a long time before DirectX (way back in the offline raytracing days).