It's been a while, (sorry!) and I really need to post an update as to what I've been working on, so here it is! Unfortunately there aren't any pictures this time.
After a few false starts, I've taken out the old Quaternion implementation and implemented an order agnostic version. This implementation implements basic Quaternion math, ignoring the complication of Euler Angle order. This makes the Quaternion class simpler, and moves the problem of Euler order to either the user or the Rotation3D class.
One approach the user can take is to convert the Euler Angles to Quaternions manually using the Axis-Angle representation for each rotation axis, then multiplying these Quaternions together. While this is easy to write, it may obfuscate the intention of the engine author, so this method isn't my favorite.
A better idea would be to provide support for Euler Angles just like the original Quaternion implementation did. Due to the fact that the Rotation3D class has already implemented Euler Angle to Matrix conversions for a single Euler Angle Order, I decided that it would be a better idea to expand this for all possible Euler Angle Order representations. This code adds an order parameter for converting between Euler Angle rotations to a specific rotation order. By making this order explicit and supporting all of the available rotations, this approach should make the code more readable, while still providing the flexibility that supporting many 3D games requires.
With this capability added to the math libraries, I then wrote tests using the ResidualVM testing framework to ensure that I got the conversions correct. I also made a separate branch with both old and new Quaternion implementations to compare sequences to ensure that the new code matches the old code as closely as possible.
The git branch containing the new Quaternion and Rotation3D code can be found here, while the testing branch can be found here. There are a few bugs remaining in the usage of this code in ResidualVM (the LookAt for Grim looks like it's Z Axis-inverted, some attachment bugs still), but I hope to have those fixed in the next few days.
Once this code is pushed into merge-able shape, my next task will be adding bugs to the ResidualVM bugs list for the open issues with EMI so that there's less chance of duplicated effort.
After a few false starts, I've taken out the old Quaternion implementation and implemented an order agnostic version. This implementation implements basic Quaternion math, ignoring the complication of Euler Angle order. This makes the Quaternion class simpler, and moves the problem of Euler order to either the user or the Rotation3D class.
One approach the user can take is to convert the Euler Angles to Quaternions manually using the Axis-Angle representation for each rotation axis, then multiplying these Quaternions together. While this is easy to write, it may obfuscate the intention of the engine author, so this method isn't my favorite.
A better idea would be to provide support for Euler Angles just like the original Quaternion implementation did. Due to the fact that the Rotation3D class has already implemented Euler Angle to Matrix conversions for a single Euler Angle Order, I decided that it would be a better idea to expand this for all possible Euler Angle Order representations. This code adds an order parameter for converting between Euler Angle rotations to a specific rotation order. By making this order explicit and supporting all of the available rotations, this approach should make the code more readable, while still providing the flexibility that supporting many 3D games requires.
With this capability added to the math libraries, I then wrote tests using the ResidualVM testing framework to ensure that I got the conversions correct. I also made a separate branch with both old and new Quaternion implementations to compare sequences to ensure that the new code matches the old code as closely as possible.
The git branch containing the new Quaternion and Rotation3D code can be found here, while the testing branch can be found here. There are a few bugs remaining in the usage of this code in ResidualVM (the LookAt for Grim looks like it's Z Axis-inverted, some attachment bugs still), but I hope to have those fixed in the next few days.
Once this code is pushed into merge-able shape, my next task will be adding bugs to the ResidualVM bugs list for the open issues with EMI so that there's less chance of duplicated effort.
No comments:
Post a Comment