• Advertisement
Sign in to follow this  

PhysX coordinate System

This topic is 3894 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

In an unrelated post, the wise and powerful moderator states: "(PhysX) use(s) a right-handed coordinate system..." However the documentation for the PhysX API states: "Left or right handedness is not a concern of the SDK..." I think I have to agree with the moderator in this case and here is why: When configuring the Joint object in PhysX, you supply the x and y axis, and the engine calculates the z axis by taking the cross product. If the engine uses the cross product to calculate the third axis, doesn't that mean that it is assuming a particular coordinate system is being used? If the engine does Z = X cross Y then it is assuming one convention, but if it does Z = Y cross X then it's assuming another convention. Is my logic sound here?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by andresch
In an unrelated post, the wise and powerful moderator states: "(PhysX) use(s) a right-handed coordinate system..."
However the documentation for the PhysX API states: "Left or right handedness is not a concern of the SDK..."

I think I have to agree with the moderator in this case and here is why:

When configuring the Joint object in PhysX, you supply the x and y axis, and the engine calculates the z axis by taking the cross product. If the engine uses the cross product to calculate the third axis, doesn't that mean that it is assuming a particular coordinate system is being used? If the engine does Z = X cross Y then it is assuming one convention, but if it does Z = Y cross X then it's assuming another convention.

Is my logic sound here?
I don't know the answer to your specific question regarding the PhysX API, but there are a few issues that can cause confusion where handedness is concerned.

First of all, as I understand it, handedness has a purely mathematical meaning, and also a (different) 'spatial' meaning.

The mathematical meaning is simple: if the determinant of the matrix representing a given orthogonal basis is positive, the coordinate system defined by that basis is considered to be 'right handed', else it's considered to be 'left handed'.

The 'spatial' definition requires a visual or physical (that is, not purely mathematical) representation in order for it to have meaning. Spatially, handedness refers to how the basis vectors are oriented with respect to one another visually or physically. (This is where the familiar left-hand/right-hand tricks for determining the directions of axes, cross-products, and rotations come into play).

For convenience, let's adopt the abbreviations MRH and MLH for 'mathematical' handedness, and S*H for 'spatial' handedness. We can then make a few observations:

1. Most (probably all) graphics and physics APIs assume a MRH system.

2. SRH and SLH systems are both MRH with respect to themselves, and MLH when expressed in a coordinate system of the opposite (spatial) handedness.

3. Negating an axis or swapping two axes flips the mathematical handedness of a basis (i.e. reflection). This corresponds with the various row operations that will negate the determinant of a matrix.

4. In a MRH system, it will always be the case that X = YxZ, Y = ZxX, and Z = XxY.

5. In using the cross product to compute the third basis vector from two existing basis vectors, you are making an assumption about mathematical handedness, but not spatial handedness.

6. When transformations are expressed in purely abstract mathematical terms (i.e. 'just numbers'), there is no spatial handedness. This may be what the PhysX docs mean in saying the SDK is handedness-agnostic: spatial handedness only comes into play once you pull transforms from the physics simulator and assign them to visible objects using a specific graphics API.

7. As an illustrative example, consider a simulated spacecraft for which +z is forward and +y up in local space. You apply a force (as from a thruster) from the back, on the +x side of the ship, and PhysX processes it appropriately. At this point it's all 'just numbers', and these numbers are going to be the same no matter what the spatial handedness of the display system. However, once you've rendered the ship, it will appear to turn left in D3D, and right in OpenGL, due to the fact that these two APIs differ in terms of spatial handedness (at least by default). When deciding, say, what key to map to the '+x thruster', it is the handedness of the graphics system, and not the physics system, that must be considered.

Although, again, I'm not familiar with the PhysX SDK, I'm going to venture a guess that it is indeed agnostic with respect to spatial handedness. I imagine that when you submit the X and Y axes for the joint basis, Z is always calculated as XxY. This does indeed imply mathematical right-handedness, but with respect to spatial handedness (the sense of the term with which we're most often concerned), it neither assumes nor implies anything.

There's also the issue of 'which way is up/forward/sideways' with respect to how the 'front' and 'top' of your models are oriented, but this is a separate problem, unrelated to handedness.

Although I'm usually fairly confident in my 'math answers', I haven't quite been able to tease apart the finer details of the relationship between these two meanings of the term 'handedness' (if there are indeed two meanings), so the above may not be exactly correct. If Graham, Dave, Christer, or any of the other true math experts on this forum stumble across this thread, maybe they can help clear things up a little (in fact, I went into as much detail as I did largely in the hopes that I'd be able to clear up my own uncertainties about this terminology!).

Share this post


Link to post
Share on other sites
I actually posted a followup to my message that andresch quoted, correcting something I wrote that wasn't quite correct, and possibly revealing my opinion about the subject of this thread.

So, I believe there isn't really a mathematical handedness, at all. Cross products and the like, are pure operations, and the concept of "handedness" is purely a convention that we invented for the sake of convention...to make it easier to comprehend some things, to learn them and to communicate them.

In explaining myself, I'd like to further comment on my replies to the other thread. In my followup, I stood by my comment that most SDK's dealing with geometry, including physics SDK's, use a right-handed system. But, as alluded to by the PhysX documentation (which andresch quoted), it is possible to write a system that is independent of handedness. Internally, yes, the SDK's might choose to let Z = X cross Y or alternatively Z = Y cross X. And you might choose to label that as "taking sides" and that the SDK uses a right-handed or left-handed system. But, in fact, as long as an SDK does projections correctly using a computed coordinate system for joints, say, it does not matter which way the Z axis was calculated. The end simulation result would be the same if only that one line of code was changed. The code at large doesn't have to make any assumption or decision about this thing called "handedness" other than that one line of cross product code, which was chosen arbitrarily and could be reversed.

So, in graphics, where you simulate a vision system, the virtual camera, choices do have to be made that involved a "handedness," and we might as well call this what jyk suggested, "spatial handedness." The only real reason (er...I think) we have to involved handedness here is because we have to decide which direction the camera looks, within its on projection transformation. We may decide, as OpenGL does, that the camera looks down its positive z axis, so that things further from the camera have larger z coordinate in projection space. We still want the rendered image to be proper, left-to-right rather than a mirror image, so the camera projection matrix's x and y axes have to be aligned with the world. But that can mean that the projection matrix has to have a flipped "handedness" when compared with the model world's "handedness." This is all about camera conventions, and so choice of handedness is again simply a matter of convention.

Share this post


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

  • Advertisement