I’ve been looking into quaternions a bit and tried to use the Rhino Quaternion class, and I’m not claiming that I have grasped the quaternions concept in full, but it seems that Rhino Quaternions doesn’t support rotating other Rhino classes directly, like transform does.
Although Rhino quaternions supports arithmetics with other quaternions, it seems that the only way to apply rotations to other classes is via rotations retreived from the quaternins as Angle-Axis values or by quaternions yielding rotated Planes after some pure q (only) arithmethics (or by creating Transform from those results).
For example, I have noticed that in plethora of documentation for quanternions out there, there’s often assumed that multiplication (rotation) of quaternions with vectors can be done directly with quaternions, i.e. “v1 = q * v”. It simplifies life if one can use “std formulae” as documented in scientific papers etc.
Q: Also, is there any chance that extended support for quaternions arithmetics be added to the RhinoCommon Quaternion class, as well as a few more “essential” methods like;
- Vector3d Quaternion.eulerAngles; // all three angles
- static Quaternion Quaternion.Euler(double anglex, double angley, double anglez);
- void Quaternion.SetFromToRotation(Vector3d fromDirection, Vector3d toDirection);
- static Quaternion.LookRotation(Vector3d forward, Vector3d upwards = Plane.WorldXY.ZAxis);
- static Quaternion.RotateTowards(Quaternion from, Quaternion to, double maxDegreesDelta);
- static Quaternion.Lerp(Quaternion a, Quaternion b, double t);
- static Quaternion.Slerp(Quaternion a, Quaternion b, double t);
Well, any compentent game engine provides these (above examples from Unity).
And in addition to arithmetic “compatibility” with other relevant Rhino classes, perhaps some overload equivalents yielding Transforms for relevant similar quaternion operations.
That would be gold.
Problem is that quaternions are not the kind of thing that you deal with intuitively, math abstractyions as they are, therefore it’s easy to forget the reasoning about them from time to time. I guess this is why you pad classes with methods hidning complex reasoning.
May I humbly suggest adding this to Rhino 6.4? ![:wink:]( ":wink:")
// Rolf
