I’m trying to re-invent the wheel here a little bit and write a program that converts quaternions into Euler angles, partially as an attempt to better understand quaternions but for other various reasons as well.
However, I’ve run into a problem. In Blender, no matter what axis I use, if I input values beyond a certain point the Euler angles Blender produces differ from my program, the results from the equation on Wikipedia and Euclideanspace.com, as well as MMD(for what it’s worth).
Basically, the issue I have in more concrete form is this:
An angle of 135 in Blender will produce some variant of 0,0,(±)135(any order) for every axis.
An angle of 135 in any other converter will produce some variant of (-+)180,(±)180,(±45) for one axis, and some variant of 0,0,135 for the other two.
It’s not just this one angle, either. The problem seems to bleed over into other angles as well. It appears that the angle produced is always(or generally, I haven’t tested that much) a rotational equivalent, but if the numbers I produce in my program don’t match Blender’s, then when it comes to doing operations like multiplication and division on the angles this difference will become a problem.
I’ve been at this for the past day or two but I just can’t figure out what’s causing this discrepancy. I cannot produce a quaternion converter that always produces a variant of 0,0,135 when rotated 135 degrees from neutral; one axis always results in 180,180,45. I’m not saying Blender is wrong or anything like that, but I suspect there is something going on here that I’m not going to be able to find the answer for short of possibly looking at the source code for the quaternion object in Blender.
Can anyone give me an idea of what’s going on or help? I honestly don’t understand the math that well, so I’m about at the end of my rope as far as debugging this.
The resources I’ve used to develop my code are mostly:
I’d post the source code but it’s a little jumbled right now and all I’ve done is taken the equations on Euclideanspace.com and plugged them into Python with some swizzling in attempt to account for the equations being designed for a different rotation order(I would suspect this is the source of my problem but my converter seems to match some programs, just not Blender).