3D is hard. XYZ sounds simple enough, but as soon as you ask "which way is left/up/right", you run into ambiguities. I'd like to sum up what we know, in a short format. The reason I'm posting this:
This is the switch in blender2ogre that gets things right:
What I'm wondering is - if the game gets it consistently wrong all the time, is it really "wrong" or just "our own quirky way of doing things"? Problem is I'm not sure it's consistent:
- In the game, +Y is up, +X is right, +Z is forward. See this image in OGRE docs. This "Y is up" arrangement is standard in 3D renderers and game engines.
- In Blender, +Z is up, +X is right, -Y is forward. See top of this Blender-Docs page. This "Z is up" arrangement is standard in mathematics.
- For historical reasons, the game mostly expects assets to have the axes wrong and tries to compensate by rotating, causing further confusion.
This is the switch in blender2ogre that gets things right:
What I'm wondering is - if the game gets it consistently wrong all the time, is it really "wrong" or just "our own quirky way of doing things"? Problem is I'm not sure it's consistent:
- Terrain objects (placed via ODEF/TOBJ) are auto-rotated -90 degrees around local X, so that Y becomes Z. This is the corrective code - clear single line. For of the `pitch()` function, see animations on this OGRE WIKI page.
- Same applies props (placed via truckfile). This is the corrective code - it takes the "x node/y node" from truck file and actually uses them as X and Z axes in the calculation.
- I'm not sure about flexbodywheels - there is a hardcoded 90 degree rotation, but around the local Y axis, so, causing the effect Mike described on Discord but not fixing up the axes.
- The checkpoints in race scripts all face X axis, whereas procedural roads face Z axis. I ran into this when working on the mission system. I ranted about it on Discord recently.