search

eastskykang / UnityMeshImporter

Runtime mesh importer for Unity using AssimpNet
https://donghok.me/UnityMeshImporter/
Other
69 stars 20 forks source link

Wrong (?) assumptions about Assimp coordinate system #10

Open NoTuxNoBux opened 3 years ago

NoTuxNoBux commented 3 years ago

I have a question about the vertex and normal conversion happening in MeshImporter.cs: the conversion that happens negates the X coordinate and maintains the Y and Z coordinates. Why is this the case? Perhaps I'm misunderstanding, but in Unity +X is right, +Y is up, and +Z is farther away. In Assimp, +X is also right, +Y is up, and +Z is closer by, into the camera, doesn't this mean only the Z coordinate should be inverted?

The lines in question are MeshImporter.cs#L144 and MeshImporter.cs#L153.

NoTuxNoBux commented 3 years ago

Testing some more with different models, some models have weirdly off Z values (meshes look fine, but some parts of the mesh are positioned farther away or closer by than they should be), whilst the same models imported in Blender look fine. I think this may be due to MeshImporter#L229:

uOb.transform.localPosition = new UnityEngine.Vector3(aTranslation.X, aTranslation.Y, aTranslation.Z);

As Assimp's coordinate system has an inverted Z axis compared to Unity, shouldn't this translation also be inverted? Changing this to -aTranslation.Z fixes the model for me.

I also tested the vertex and normal conversions from the OP with my large model, and this indeed confirms that these assumptions appear to be incorrect; if I change it back to the original code from this repository, the meshes are in all the wrong places. Only inverting the Z coordinates fixes it. For smaller models, this didn't seem to matter, only that they were sometimes appeared to be rotated incorrectly.

EDIT: I'm also now starting to doubt the rotation at MeshImporter.cs#L230:

uOb.transform.localRotation = UnityEngine.Quaternion.Euler(euler.x, -euler.y, euler.z);

My rotation on the X axis is also off compared to Blender (it is inverted). I may be wrong and am not sure my math is correct here, but shouldn't (only) the X coordinate be inverted, because positive rotation goes clockwise in the direction of the other two orthogonal axes, which means that, when the Z axis is inverted in Assimp, only rotations over the X axis become opposite?

EDIT2: I just realized all these conversions and inversions can be skipped entirely by just passing PostProcessSteps.MakeLeftHanded to Assimp. This fixes all the above issues (which seems to confirm this is currently bugged), as well as additional issues I didn't even know I had :smile:.