1. ## 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

2. 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

4. 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.

5. 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?

6. 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

7. Originally Posted by comanche008
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?
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.
Originally Posted by remi
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.
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

8. 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

9. Originally Posted by comanche008
Well I asked about the swapping because that would be my starting point and show that I'm on the right track.
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.

10. 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.

Page 1 of 2 12 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•