I just read this article and the author makes a really strong case for bivectors instead of quaternions:
https://marctenbosch.com/quaternions/
There seems to be zero history on ThreeJS discussing it and I was curious what everyone thought about this. Any reason NOT to support bivectors instead?
I salute your initiative and the thought-provoking perspective. It’s refreshing to know that I’m not alone in feeling a certain level of apprehension towards quaternions. While I may not possess the same depth of understanding as you do, I must applaud the caliber of your presentation and the quality of the used illustrations, making this complex subject more approachable and understandable.
Quaternions are de facto an industry standard, widely used in major softwares, engines, and libraries. They have proven to be effective for representing rotations and have been extensively studied and optimized over the years.
Introducing a new representation would require significant changes to existing software and workflows. It would involve rewriting core algorithms, updating libraries, and potentially disrupting compatibility with existing projects and file formats. Such a transition would need to be carefully planned, tested, and supported by the 3D community.
That being said, ThreeJS may provide an ideal starting point for exploring the implementation of rotation rotors. As an open-source library, it can offer the flexibility and collaborative environment necessary for introducing new concepts. By integrating rotation rotors as a property of the Object3D class, in addition to quaternion, developers could perceive it as either a double standard or a viable alternative to quaternions. One advantage of this approach is that it has the potential to coexist with existing projects without causing disruptions. By treating rotation rotors as an additional feature, developers could gradually incorporate them into their workflows while maintaining compatibility with quaternions.
However, such a transition would require substantial updates throughout the Three.js library and, more importantly, the support and involvement of the Three.js community. Active participation, feedback, and contributions from developers would be vital to refine the implementation, ensure its effectiveness, and foster its adoption within the 3D graphics community.
It’s always matrix at the bottom. Currently matrices, quaternions and Euler angles can be mutually converted to one another. May be for supporting rotors just conversions to/from rotors would be sufficient? I know this is oversimplification, but rotors would be a wrapper around rotation matrices the same way quaternions are a wrapper.
You are right, at the end all transformations are converted to a Matrix. I was cautious in order to not make any hasty statement. But this make the integration as simple as wrapping and plugin a new property, we this even exporting and importing toJSON, ObjectLoader and GLTFLoader would work out of the box.
Actually there is a thought about that matter, may be why its never discussed is quaternion works really well to do the job.