Animation Origin transform matrix is exported incorrectly

[jem-suu]

I've noticed that model files generated using this plugin have a different axis applied to them that results in animations applied to objects behaving differently compared to model files that are run through the .x to .o3d creator.

If this isn't already in the SDK Support option, could an option be put into the exporter to export with the old axis?

(I'll probably put pictures to illustrate this later on)

[Road-hog123]

I should perhaps rename the SDK Compatibility option to Crossing Editor Compatibility—it just exports an o3d version 1 header that the Crossing Editor knows how to read, the rest of the file is unchanged.

If my exporter is not producing the correct transform matrix then that's a bug that should be fixed—but I'm going to need more information about how the transform matrix is different (and unexpected?) to be able to make any changes.

Were the converted o3d files exported using the X exporter bundled with Blender <=2.79b, or with a third-party X exporter for Blender >=2.80?

[jem-suu]

The converted o3d files were from the included exporter from 2.79b.

I'm going off memory here, but from what I've experienced, origin_rot_y and origin_rot_z are seemingly swapped around.

An example I can think of from the top of my head is the front wheels when Steering, when you apply

origin_rot_y
90

to a rotation animation on a mesh exported from the 2.79b .x, the axis of rotation changes on the Y axis and thus the mesh rotates on the z-axis. Applying the same on a mesh exported using the exporter on 2.80+, the axis of rotation on a wheel changes on the Z axis and thus the mesh rotates on the Y axis, a bit like this: (Source: Greenmint Discord Server)

I also think that the axis directions are also different, as, again, using a typical wheel animation like below:

[newanim]
origin_from_mesh
anim_rot
Wheel_Rotation_1_R
57.295779513082320876798154814105

the wheel rotates backwards and I would have to put a negative value for that animation for it to animate correctly

I'll have to figure out how to illustrate it better, and I'll add another comment once I do do.

[jem-suu]

Looking at this diagram from Webdisk: my guess as to what's happening is that:

• +X is being exported as -X, and vice versa
• Y and Z are swapped

[Road-hog123]

Ok, this implies the coordinate system of the transform matrix is not the same as the geometry... 🙄 I'll do some testing and get this fixed. 👍

[Road-hog123]

Ok, this implies the coordinate system of the transform matrix is not the same as the geometry... 🙄

It turns out the coordinate system is the same, but the coordinate system conversion for matrices also requires that the middle rows be swapped, which was not being done and is now fixed.

Testing shows the diagram from Webdisk is incorrect (+X is right, not left), but I can understand why because OMSI is cursed—being a DirectX application it uses left-handed Y-up internally, but frequently makes itself appear to use right-handed Z-up in the UI and config files by labelling Z as Y and Y as Z—this results in a system with right-handed axes and left-handed rotations. 🙄