It's generally not the best idea to use something just because people say it's faster. It's better to get correct behaviour and then optimise.
Quaternions will allow you to handle angles from -360 to 360, but there's one more piece you need if you're interpolating. You need to keep track of the delta in angle between the two sources, and note when it crosses 180 degrees, because quaternion slerp will always return the shortest rotation, so will need to be flipped if that delta has been crossed. The most reliable way to do this is to use the original euler angles and just average them before constructing your new rotation. In the case you're describing, for the Z rotations you have a delta of 200 degrees, so quaternions could return the 160 degree rotation in the other direction instead to reach that orientation, and in that case, without the original eulers to inform the decision you'll have no information to choose to use the inverse quaternion instead. This isn't an issue for the actual rotation, as visually it will look the same, but once you start averaging, you've now got an 80 degree rotation in one direction versus a 100 degree rotation on the other side. Those look very different, and that's why you have that pop when you cross a 180 degree delta. As to performance, yes, matrices and quaternions are going to be quicker than other methods that have to do more work, but you throw away data to get that speed boost, and the maya nodes with direct connections are still going to use the matrices under the hood to find your final transform. In this case (averaging rotation), you've got three additions, and three multiplications, which is far faster than using a matrix. You could achieve the whole thing with a single plusMinusAverage node (or if you prefer to avoid unit conversions, 3 addDoubleLinears and 3 multDoubleLinears). That's going to be way faster than the matrix operations (which have, for each of 16 elements, four multiplications and three additions). A note that none of this will take into account offsets or parent spaces. Those you'd have to handle as well for all but the simplest cases, and for those the matrix nodes would not go amiss once you understand the maths driving them. Hope that helps, Joe On Wed, 21 Mar 2018 at 3:02 PM, justin hidair <[email protected]> wrote: > You need to use MQuaternion , go take a look at MFnTransform or > MFnTransformation ( I don’t know which it is) and see the parts where it > mentions MQuaternion , can’t remember it at the top of my head but you can > have any angle with your quaternion in radians of course so past 180 deg > like you want ( pi ) past 360 degrees ( 2 pi ) … > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *Michael Boon <[email protected]> > *Sent: *Wednesday, March 21, 2018 12:52 AM > *To: *Python Programming for Autodesk Maya > <[email protected]> > *Subject: *[Maya-Python] Re: Getting rotations beyond -180 to 180 degree > rangefrom matrix > > > > In most cases, if you're trying to average rotations, quaternions will > give you much more intuitive results. Quaternions don't get gimbal lock, so > they don't do weird things when the euler angles get near 90 degrees. One > weird thing they do (which might suit you given the subject) is that they > support angles up to +-360 degrees. > > If you use the OpenMaya.MQuaternion class, it has a slerp function that > will do your interpolation for you. > > Generally speaking (though it will depend on your specific code) > quaternions are faster than matrices or euler angles for interpolating > angles too. > > However off the top of my head, I can't remember how to get or set object > rotation as quaternion in Maya. Someone else might know? > > On Tuesday, 20 March 2018 09:52:20 UTC+11, derek wong wrote: > > I was getting the arccos of dot products between cubeA and cubeC to > determine angular differences. > > > > I just wasn't sure if I was using the entirely wrong method, or if I was > ignorant about something that would make it work, but now I know it was the > former. > > > > Thanks for the help! > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/c5861edd-f7b8-476f-838a-6bfd73251aa7%40googlegroups.com > <https://groups.google.com/d/msgid/python_inside_maya/c5861edd-f7b8-476f-838a-6bfd73251aa7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/5ab1bd25.0eaddf0a.850f5.e18f%40mx.google.com > <https://groups.google.com/d/msgid/python_inside_maya/5ab1bd25.0eaddf0a.850f5.e18f%40mx.google.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAM33%3Da5RoASVMJzjmsG4bUb34emtx5exODVC%3D8%2BRC3ceZt4_bA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
