# What's the rationale for different coordinates systems?

Could someone explain to me why Blender and other 3D modeling apps switch axes?

If I export model with Blender, then exporters do following things for the same model:

The 3DS format applies this transform matrix:

     [ 1.0, 0.0, 0.0, 0.0 ],
[ 0.0, 0.0, -1.0, 0.0 ],
[ 0.0, 1.0, 0.0, 0.0 ],
[ 0.0, 0.0, 0.0, 1.0 ]


The Collada format applies this transform matrix:

     [ 1.0, 0.0, 0.0, 0.0 ],
[ 0.0, 0.0, -1.0, 0.0 ],
[ 0.0, 1.0, 0.0, 0.0 ],
[ 0.0, 0.0, 0.0, 1.0 ]


The OBJ format (default) transforms axes just like a transform matrix was applied, but OBJ format (Forward Y, Up Z) gives the original values that I see in Blender. The PLY format also does nothing and I get same values I see in Blender.

PS

Question was edited. I do not ask why there are different coordinate systems. I understand that.

I do not understand why Blender and other switch axis silently when model is exported.

• It is easy to fix model after export
• There are people who needs that.

Actually I never seen these people and if it easy to fix then it is more easy to switch axis for those who really need that switch.

I would love to hear someone who say that axis switch is important and he/she needs in real work (not in theory)

• Can you remove the rant and make your actual question clear? Possible duplicate: gamedev.stackexchange.com/questions/7915/… Nov 15 '13 at 0:32
• I am sorry for rant. But it is different question. I know how to export. I do not understand why exporter transform model. It is not obvious.
– Max
Nov 15 '13 at 0:38

There isn't really a universally standard coordinate system. I have worked on games and with tools, across all of them, have used almost every possible combination of systems. I think the only ones I have no worked with in practice are "+X is up" and "-X is up."

• In some cases it's easier to handle or visualize the data in a different coordinate system, and so exporters are written to transform into that system so that the end consuming product is more efficient.

• In other cases, file formats dictate a particular transformation due to various assumptions (though I don't think any of the ones you listed explicitly make such dictations).

• In yet more cases, the author of exporter just prefers data that way.

It's pretty much impossible to say why a particular exporter for a particular format for a particular tool operates in the way it does other than to ask the author, since it comes down to that author's preference.

I would say it's a bit odd that the importers for a particular modeling tool like Blender don't all default to exporting in Blender's coordinate system, but it is true that most of Blender's exporters were community-sourced (last time I used it), and so there was not necessarily a lot of design oversight on the functionality of each importer and their relative behavior.

Adjusting the transformation is generally as simple as applying your own corrective transformation on import (or writing your own exporter), so once you know it's there, it's not hard to work with.

• also transforming into another coordinate system is just concatenating a matrix to the transformation stack so no real cost Nov 15 '13 at 1:51
• Exactly. Exporter should not transform. Someone who needs transform can do that manually. Instead I never know when something will apply such transform. I think such transform is bad practice.
– Max
Nov 15 '13 at 13:36
• That's an opinion you are entitled to have, but the majority of the rest of the world doesn't necessarily share it.
– user1430
Nov 15 '13 at 15:36
• Right. My question was edited and infact I was interested if there are people who really needs it.
– Max
Nov 16 '13 at 15:41
• Yes, there are people who need it. The examples I gave of using every coordinate system except +/-X up are all from commercial engines or games.
– user1430
Nov 16 '13 at 19:55

Z going up is a standard co-ordinate system for modelling packages since the early days when 3D Studio Max was the de-facto tool used by everyone, and was an originator of this standard. It's still present and documented in modern versions, e.g.: http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-99C4C2C1-0971-48E2-8266-B911A3315554.htm,topicNumber=d30e55885

For example, in the World coordinate system, as seen from the Front view, the X axis runs horizontally from left to right, the Y axis runs from back to front, and the Z axis runs vertically, from bottom to top.

The transforms you give in your question just convert the co-ordinate system from that used in 3D APIs (Y up, Z depth) to that used by 3D Studio Max.

There's actually no well-defined Cartesian co-ordinate system for 3D; you just get to pick which direction each of the 3 axes represents according to the requirements of your own use case. So neither standard should be seen as correct or incorrect.

So we have a situation here where in one case - 3D modelling programs - one standard was chosen, but in another - 3D APIs - a different standard was chosen, and that's just the way things evolved historically. 3D modelling programs would have evolved from plotting out a floorplan on a sheet of paper, where Z is naturally up; the designers of 3D APIs just chose differently.

It's worth adding that there is at least one modelling program that uses a Y-up system, and that this program is documented as causing confusion for users of other programs: SolidWorks.

Users wonder why the Y-axis is pointing up and X-Z represents the top plane or table top when looking down from the top, while in some other CAD or CAM systems they may have used, the Z-axis is pointing up and X-Y represents the top plane or table top. Well, unfortunately, there are at least two defacto "standards" in the modeling industry for the orientation of the global coordinate system. I call them the Y-up and Z-up coordinate system standards. Both of these coordinate systems are right hand rule coordinate systems, they just happen to be rotated differently. So, neither of these systems is "wrong" and as they say, that is the great thing about standards...so many to choose from.

So in summary:

• There is actually no single universal standard for this.
• Different programs and use cases choose their own standard for historical reasons more than practical ones.
• Deviating from the standard that was expected to be chosen can cause confusion for the primary target audience of a program.
• In order to successfully use the output from a program in your own work, you need to know which standard it used and how to convert it to the one you're using.

That's an unfortunate state of affairs, but it's inevitable when technology from different sources evolves over an extended period of time and with no "watchdog" body to enforce conformity.