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 = xXyIf 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!