scgames, on 11 Jun 2009 - 12:24, said:

Just a quick comment on the 'handedness' issue. Generally speaking, the (geometric) handedness of the coordinate system used should not affect your math library code (by which I mean code that constructs or manipulates vectors, matrices, quaternions, and so on). In other words (for example) a function that builds a rotation matrix or quaternion or computes the cross product of two vectors should be exactly the same regardless of the handedness of the coordinate system being used.

Projection transforms and 'view' transforms (e.g. a 'look at' transform) are exceptions in that they're generally constructed differently for left- and right-handed systems. The differences actually have to do with which direction is considered 'forward' in view space, but are also an indirect result of the coordinate system handedness and the convention that the positive x axis should point to the right in view space.

As for computing cross products, with a typical orthonormal basis the relationships between the vectors should be:

x = yXz
y = zXx
z = xXy

If you're seeing the arguments flipped around depending on handedness, you might be looking at a 'look at' function (where the flipping is related to which direction is to be considered forward in view space).

Even though most functions should be unaffected by handedness, you may find that the results of applying said functions change when switching handedness. For example, triangle windings may flip, models may be mirrored, and rotations may appear to go the 'wrong' way. In these cases though it's the input data that should be changed, not the functions that work with the data.

Also, keep in mind that the DirectX/D3D and OpenGL APIs differ in a few other ways as well, most notably matrix layout (row major vs. column major), vector notation (row vs. column vectors) and the near plane distance for the canonical view volume (zero vs. negative one). The issues of matrix layout, vector notation, and coordinate system handedness are often confused with each other, but in fact they are three separate and unrelated issues (although they can interact with each other in ways that can be quite confusing).

This led me to thinking about coordinate system handedness and I see the point that numbers are numbers and the formula for cross or dot product are the same irrespective of the human who perceives it and hence we'd get the same results be it we consider data in any handedness. Then why do we see handedness conversions being talked about? i.e. converting some asset from one handed system to another doesn't seem to make sense; say a triangle data of v0 = (0, 0, 0), v1 = (0, 0, 1), v2 = (1, 0, 1) could be interpreted as a triangle irrespective of the system used and in both cases the base of the triangle would be away from the origin, hence why would this (or any asset/mesh) data be called LHS or RHS.

Also in another post I noticed this

Quote

you can test the "handedness" of a coordinate
system given the basis {v1, v2, v3}.

if (v1 x v2) . v3 > 0, then it''s right-handed.
if (v1 x v2) . v3 < 0, then it''s left-handed

but what beats me is, even here, I'm unable to differentiate the handedness, since in both systems, i x j = k and there by k.k will always be > 0 (k^2, to be exact), then how does the above hold true?

Handedness is something that is only in the mind of the human who interprets the data; say in a model file, after all the numbers present are just numbers and they don't've any inherent handedness bound to them (or am I wrong here?), then why do we talk about conversion from one system to another? Is it because of the graphics API that we use (which I think shouldn't be the reason since both GL and DX supports both handedness is what I read); so I'm really confused on what circumstance does the handedness really matter. If, I, the developer always interpret/see all data in RHS, then when would I be bitten by it and why?

It'd be great if someone can explain this to me.

Thanks!

Well if your projection matrix and view matrix are set up for a left-handed coordinate system, then if you interpret the data in a resource file as right-handed, and attempt to render them, everything will be on its side and backwards (from the point of view of humans looking through a monitor)

Agreed. My point is how do you differentiate a LHS model and RHS model, what exactly is different between the two? The reason I'm not able to differentiate is that both models will've just numbers; say in a triangle of vertices v0 (0, 0, 0), v1 (0, 0, 1), v2 (1, 0, 1) where's the handedness encoded/lurking?

Similarly, given three vectors say i (1, 0, 0), j (0, 1, 0), k (0, 0, 1), how do you know if it's left or right handed. In my first post, I'd quoted

you can test the "handedness" of a coordinate
system given the basis {v1, v2, v3}.

if (v1 x v2) . v3 > 0, then it''s right-handed.
if (v1 x v2) . v3 < 0, then it''s left-handed

But then with the above vectors, considering them as either left or right both pass the test. Then how do I differentiate?

You can't find the handedness by just looking at the coordinates.

Handedness only comes into play when you want to interpret those coordinates, and show it to a human.

If the 3d modeller worked in a LHS and you try to display it in a RHS it will look inverted from how the modeller intended, but there is no way to know what he intended without asking him. (That is, have a separate encoding in the file that says "this is modelled in LHS")

Then why do we see handedness conversions being talked about?

You never convert from left-handed to right-handed (or vice versa) as such because that is meaningless.

However, you may (and regularly do) move data from one coordinate system to another, involving a transform of some type. And it may be the case that one system is left-handed and one is right-handed, and indeed that the coordinate systems are otherwise identical except for this. One reason handedness is interesting is because you can't transform from one to another with rotations and translations alone, unlike most other operations you'll perform on 3D data. You need to scale one axis negatively to reflect it.

Your rendering system will have its own idea of which direction Z goes in, relative to the XY plane, so you need to ensure your data is transformed to the appropriate coordinate system before the renderer gets hold of it. Handedness is an arbitrary choice, but typically the renderer has already made its choice and you need to be aware of it so that you can adjust your data to suit.

However, I'm reading "Essential Mathematics for Game Programmers", in which there is a statement which goes, "when we've three basis vectors i, j and k, performing scalar triple product like (i x j) . k > 0 then it is right handed while if it's negative it's left handed".

Well that's wrong for a start. In either left or rand handed systems, cross(i, j) will always equal k (assuming no scaling obviously). Now, if you happen to be using either system, and introduce a scaling of -1 in one of the axes, then your coordinate-frame will now be the opposite handedness to your coordinate-system. I suspect that's what the author of the book was attempting to explain.

What confuses me is, I took 3 vectors say 1i, 3j, 4k and drew them both in a left and right handed system, perform the aforementioned scalar triple product, I always get 12, which is positive, when would this be negative to show that the basis is left handed?

Never. In both cases the vector mathematics is the same. The only difference is that in a right handed system it will be on the right hand side of the origin, and in a left handed system it will be on the other side. In other words, it is only the projection matrix that is different between the two (and the winding order usually). Really this is only a problem when you introduce scaling into a system. If you're reckless and simply multiply some transforms by a scaling matrix (rather than M' = ScaleTM * M * invert(ScaleTM)), then a negative scale in 1 or all 3 axes, will turn the matrix inside out. In that case, dot(cross(i, j), k) will be negative.

The only real way to find out which system you are using, is to look at your assets in Maya/XSI/Max (all right-handed), and then draw your assets in the world. Are they the same, or are they a mirror image?

Never. In both cases the vector mathematics is the same. The only difference is that in a right handed system it will be on the right hand side of the origin, and in a left handed system it will be on the other side.

Now, if you happen to be using either system, and introduce a scaling of -1 in one of the axes, then your coordinate-frame will now be the opposite handedness to your coordinate-system. I suspect that's what the author of the book was attempting to explain.