This kind of thing is sadly hard to avoid when you cross a handedness boundary. That negative scale (your formula is essentially “multiply by -1, 1, 1”) changes the direction of rotation on your object.
Imagine you have a rotation matrix that’s 45 degrees in Y. In Maya, that’s a 45 degree counter-clockwise rotation:
The Unity version rotates clockwise
In both scenes the sphere is a child of the cube, offset to local [1,0,0] – but in Unity that 1 unit in X is on the left of the cube when scene from above; in Maya [1,0,0] puts the sphere to the right of the cube.
Exporting the Maya model to Unity gives you something that looks right. Here the green is the Maya model brought in to Unity…
But if you check the rotations in that image you’ll see that the original rotation of Y = 45 in Maya is now Y = -45 in Unity. You can’t see it but the Unity version of the sphere is now at [-1, 0, 0] instead of [1,0.0].
The importer will fix the values for you (on transforms and animations) but to do so it has to actually transform the numbers – you won’t be able to type the numbers on one side and get the same result on the other. Depending on the original values the Unity-side numbers might just look like a sign flip on the Maya numbers… or they might not.
For cameras in particular it’s probably easiest to export a camera target and use a lookat script to keep the camera pointing where you want it to go. There are other options as well – but unfortunately human-typed numbers are not one of the options that’s likely to work.
