• Advertisement
Sign in to follow this  

XNA will use right-handed system!

This topic is 4254 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Have you seen the shocking news? XNA team said that XNA will use right-handed system! Is this good or bad? I spent years to be used to the left-handed system, and now I should roll back? The good thing is that it will be the same as 3dsmax, maya, etc - No need for hand conversion any more. For your reference: http://letskilldave.com/archive/2006/06/29/XNA-Framework-tidbits_2E002E002E00_.aspx

Share this post


Link to post
Share on other sites
Advertisement

If you read down the comments further the XNA System will be right handed by default, Left handed systems are still supported.

"letskilldave said:
I want to amplify my own statement and Mitch's: the XNA framework is right-handed, _by default_. Left-handed coordinate systems are also supported."

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Isn't this the same as OpenGL now also?

Share this post


Link to post
Share on other sites
Ultimately its not going to make a huge amount of difference - so probably not worth getting to worked up about. Unless you're getting friendly with the maths then the various D3DX (or whatever its replacement is) calls will mask any of the mathematical complexities.

Having said that, it does strike me as an odd change to make. Especially as legacy (and I think also D3D10) are still LH systems. I'd hazard a guess that initially it'll cause more confusion than it'll solve... but we'll just have to wait and see!

Quote:
Original post by Anonymous Poster
Isn't this the same as OpenGL now also?
I believe so, but I'd also imagine you can switch to a LH system in OpenGL if you wanted.

Cheers,
Jack

Share this post


Link to post
Share on other sites
As far as I have seen all D3D10 samples are still LH but as in D3D9 the D3DX lib still contains the RH matrix build function.

I don’t think that XNA will have a separated assembly for the D3DX functions. The MDX 2.0 betas already integrated everything in only one assembly.

Share this post


Link to post
Share on other sites
Is this possibly due to the issue with matrix multiplies in shaders? NTNET recently mentioned it in the question about SetValue vs SetMatrix. Wouldn't this save that transpose? Or does my math just suck? :).

Share this post


Link to post
Share on other sites
AFAIK The transpose is independent of LH/RH. It’s done to allow the shader to use DP4 operations instead of MUL/MAD or the mul4x4 macro. As every vertex shader hardware out there should be able to do a DP4 as singular operation the precession should be better. Additional the DP4 are more independent than the MUL/MAD chain and can better optimized.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Isn't this the same as OpenGL now also?

IIRC, most of the DCC's use left-handed systems as well, so that could be part of the reasoning behind it.

Share this post


Link to post
Share on other sites
Quote:
Original post by sirob
Is this possibly due to the issue with matrix multiplies in shaders? NTNET recently mentioned it in the question about SetValue vs SetMatrix. Wouldn't this save that transpose? Or does my math just suck? :).


No, the transpose is due to the memory layout and multiplication order of the matrices - row-major versus column-major.

Share this post


Link to post
Share on other sites
I seem to be confused again :)

Doesn't moving to a RH system mean moving from row major matrices to column major ones? Wouldn't that eliminate the need for a transpose?

Share this post


Link to post
Share on other sites
No. The difference between LH/RH is the orientation of the Z axis. In a LH system the positive Z axis is going into the screen while in a RH it is coming out of the screen (look here).

As superpig already said the transpose is only necessary to change the memory alignment of a matrix (from row-major to column-major or vice-versa) which is usually API dependent.

Share this post


Link to post
Share on other sites
Quote:
Unless you're getting friendly with the maths then the various D3DX (or whatever its replacement is) calls will mask any of the mathematical complexities.


I'm sorry to go against another moderator on his own forum, but the truth is that left-handed and right-handed math is the same. There is no difference between the function to do a cross product in a left-handed system, and one to do a cross product in a right-handed system.

Whatever numbers you put in, you get out (i e, you assume left-handed coordinates, clockwise mesh winding, Z in, Y up, X right, or you assume right-handed coordinates, counterclockwise mesh winding, Z out, Y up, X right). The only place where this makes a difference in computer graphics is when you get to do the perspective transform, because you need to map your coordinates to the physical frame buffer.

Thus, even if you're friendly with the math, there is no difference in the D3DX math calls -- except for the one call to build your projection matrix. The difference is in how you think about, and interpret, your data at a semantic leven, which is higher up than the bits and bytes of the data and the math.

Share this post


Link to post
Share on other sites
Quote:
Original post by superpig
Quote:
Original post by sirob
Is this possibly due to the issue with matrix multiplies in shaders? NTNET recently mentioned it in the question about SetValue vs SetMatrix. Wouldn't this save that transpose? Or does my math just suck? :).


No, the transpose is due to the memory layout and multiplication order of the matrices - row-major versus column-major.


No again. I just learned that you can do:

x = mul(vector, matrix)

or

x = mul(matrix, vector)

Use the 2nd one instead of getting the trasnpose to do the first. I learned this in the Programming Vertex and Pixel Shaders book, in the chapter on bump mapping.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
I'm sorry to go against another moderator on his own forum
heh, no problem at all [smile]

What I posted wasn't really that accurate/detailed anyway - I was just thinking of the D3DXMatrix**() functions that end in "LH" or "RH" and that you don't really need to know what the underlying maths is..

I know I managed to get a very long way into the world of 3D before realising what most of the D3DX functions actually did [smile]

Cheers,
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by DXnut

No again. I just learned that you can do:

x = mul(vector, matrix)

or

x = mul(matrix, vector)

Use the 2nd one instead of getting the trasnpose to do the first. I learned this in the Programming Vertex and Pixel Shaders book, in the chapter on bump mapping.


Even in your example you are using the transpose:

#2 Multiplies a column vector with a matrix
#1 Multiplies a row vector with a matrix

Note that a row vector is nothing else than the transpose of a column vector

Share this post


Link to post
Share on other sites
Quote:
Original post by BRooksWackerman
Quote:
Original post by DXnut

No again. I just learned that you can do:

x = mul(vector, matrix)

or

x = mul(matrix, vector)

Use the 2nd one instead of getting the trasnpose to do the first. I learned this in the Programming Vertex and Pixel Shaders book, in the chapter on bump mapping.


Even in your example you are using the transpose:

#2 Multiplies a column vector with a matrix
#1 Multiplies a row vector with a matrix

Note that a row vector is nothing else than the transpose of a column vector



Hopefully you can see the difference between:

matrix = transpose(matrix);
vector = mul(vector, matrix);

and coding:

vector = mul(matrix, vector);


If not, just compile your shader and look at the assembly code.


Share this post


Link to post
Share on other sites
The 'problem' with XNA going righthand by default is indeed that it just breaks convention. It may not be any more difficult than LH, but it also isn't easier and doesn't offer any benefits, other than that various modeling packages also use RH. With D3D10 reportedly just using LH, it seems like a poorly motivated choice to go RH by default.

Quote:
Original post by hplus0603
Thus, even if you're friendly with the math, there is no difference in the D3DX math calls -- except for the one call to build your projection matrix.


The thing is though, XNA will not have a D3DX library. MDX blurs the line a bit between D3D and D3DX, so I think we all got used to the built-in vector math classes (and many others) being there by default. I sure hope they'll add some replacement for this in XNA, but it's been confirmed that we'll already be looking at reduced out-of-the-box functionality compared to MDX1.1. Hence I don't understand why they decided to add an extra obstacle with the LH/RH switch.

Ah well, I trust they'll just come up with a very nice migration guide [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
I'm sorry to go against another moderator on his own forum, but the truth is that left-handed and right-handed math is the same. There is no difference between the function to do a cross product in a left-handed system, and one to do a cross product in a right-handed system.


Yeh, the math is the same. But I think the problem lives in the mapping between math calculation and the logical world.

Let's say I want to rotate my spaceship around Y axis by 90 degrees. In a typical LH world, where X is right, Y is up and Z is front, the result is turning the spaceship right.

If we have to switch to a RH system, there're many ways. If we want to preserve the the math calculation for rotation, we have to change the meaning of the axes. Now Z must mean backward, the calculation to move forward the spaceship must be changed. If the meaning of an axis changed, there surely will be many changes to an engine. But at least one axis must be changed.

My 2 cents :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement