XNA will use right-handed system!

Graphics and GPU Programming Programming

Started by qingrui July 04, 2006 04:39 AM

18 comments, last by qingrui 17 years, 9 months ago

1,826

July 04, 2006 11:10 AM

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.

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

sirob

1,181

July 04, 2006 11:31 AM

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?

Sirob Yes.» - status: Work-O-Rama.

IndyJones

298

July 04, 2006 11:51 AM

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.

hplus0603

11,916

July 04, 2006 12:15 PM

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.

enum Bool { True, False, FileNotFound };

DXnut

262

July 04, 2006 01:15 PM

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.

--------------------------Most of what I know came from Frank D. Luna's DirectX books

jollyjeffers

1,571

July 04, 2006 01:41 PM

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

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

IndyJones

298

July 04, 2006 03:39 PM

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

DXnut

262

July 04, 2006 09:28 PM

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.

--------------------------Most of what I know came from Frank D. Luna's DirectX books

remigius

1,173

July 05, 2006 12:44 AM

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]

Rim van Wersch [ MDXInfo ] [ XNAInfo ] [ YouTube ] - Do yourself a favor and bookmark this excellent free online D3D/shader book!

qingrui

118

Author

July 05, 2006 01:23 AM

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 :)

XNA will use right-handed system!

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

XNA will use right-handed system!

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines