# Coordinate System clarification

Hi,

I’ve read several threads about the Up axis and the coordinate system used in Collada. However, I’ve ended up perhaps even more confused than I started.

Could someone confirm two things please?

1. Does Collada use a Right-handed coordinate system exclusively throughout a dae file?

2. Are the definitions of the UP axis shown in the following image correct (a Right-handed coordinate system is being used)?

Thanks

Mark

I’ve read several threads about the Up axis and the coordinate system used in Collada. However, I’ve ended up perhaps even more confused than I started.
Hah, I know what you mean!

1. Does Collada use a Right-handed coordinate system exclusively throughout a dae file?
Yes.
2. Are the definitions of the UP axis shown in the following image correct (a Right-handed coordinate system is being used)?
Yes.

Steve

So then what I have to do to get my coordinates from, for instance, Z_UP to Y_UP is swap and negate some coordinates: Y_UP = (x, z, -y) of Z_UP coordinates. Am I getting this right?

Thanks

Mark

Yeah, that’s one way. Another way is to add a new rotation to the root of the node graph that rotates the scene from Z_UP from Y_UP.

Thank you Steve.

However, I see a problem with rotating the root of the node graph that rotates the scene from Z_UP from Y_UP. Each node in the scene hierarchy could have child nodes. Each node also has its own asset element which defines the up_axis for that node. Now if nodes have different up_axis values, a single rotation would not work, right?

However, I see a problem with rotating the root of the node graph that rotates the scene from Z_UP from Y_UP. Each node in the scene hierarchy could have child nodes. Each node also has its own asset element which defines the up_axis for that node. Now if nodes have different up_axis values, a single rotation would not work, right?

yes, that is correct. <rotate> is an active transform, Up_axis is a passive transform, and they certainly do not act the same way in a transform hierarchy.

The idea of Up_axis in the <asset> tag is to avoid having to make a matrix multiply which cost time and loss of precision, especially when accumulating transforms. Keeping track of what is the current Up_axis and doing the right assignement of values is faster and more accurate.

Regards
– Remi

Good point! In that case you would need multiple rotations, one for each asset tag with a different frame than your target.

In practice I’ve never seen multiple assets with different up axis settings used in a single document. I don’t believe any Collada importers handle that case correctly, but I could be mistaken.

Swapping the values is also about an order of magnitude more difficult to implement. Our axis converter conditioner in Refinery is 1600 lines of code. My proposal is trivial to implement in comparison and achieves the same result. It’s also how the Softimage guys implement this IIRC.

Regarding efficiency, when I implemented this at my last company I already had a root transform for each model to position it into the world. I just baked the axis rotation into that transform, so there was no additional runtime cost. Besides, an extra matrix multiply isn’t going to break performance anyway.

Honestly I never understood why you and Marcus preferred the hard way.

Steve

Ok Steve. Thanks.

Well I asked about the swapping because that would be my starting point and show that I’m on the right track. From that I would create the corresponding matrices to change coordinates using one type of up_axis to another. Then it would just be a question of multiplying coordinates by the correct matrix.

So the example I gave above, that is, Y_UP = (x, z, -y) of Z_UP coordinates, I would give me the matrix (note that this is in row major order).
1 0 0
0 0 -1
0 1 0

Mark

Sorry, I was referring to a different Marcus. Should’ve made that clear.

So the example I gave above, that is, Y_UP = (x, z, -y) of Z_UP coordinates, I would give me the matrix (note that this is in row major order).
1 0 0
0 0 -1
0 1 0
Right. Either that or the inverse. I tend to forget.

I don’t have a preference Steven

The history of the <up_axis> element’s design included many peoples concerns of precision, handedness, arbitrary axes, accuracy, and so forth.

It was very insightful of you guys to include up_axis information in Collada’s design. I think a lot of formats don’t include it.

I just want to be sure to make people aware of both up_axis implementation strategies.

Yep, one of the reasons it is the way it is was to support both strategies while limiting the more arbitrary use-cases that gamers don’t experience (although other domains do).

Can someone point me to the definition of the following terms used in up_axis?

1. upward
2. to the right
3. inward
4. In Axis

See page 58 (<asset> element section 5-18) of the COLLADA 1.5 specification:

Up Axis Values

The <up_axis> element’s values have the following meanings:

``````
Value       Right Axis       Up Axis           In Axis
X-UP        Negative y       Positive x        Positive z
Y_UP        Positive x       Positive y        Positive z
Z_UP        Positive x       Positive z        Negative y

``````

Where “In axis” is the direction looking into the scene frustum (near clip) and off into the distant (far clip).