{"id":147,"date":"2014-06-21T18:41:00","date_gmt":"2014-06-21T18:41:00","guid":{"rendered":"https:\/\/blogs.scummvm.org\/josejx\/?p=147"},"modified":"2022-05-21T18:43:22","modified_gmt":"2022-05-21T18:43:22","slug":"returning-to-quaternions-and-rotations","status":"publish","type":"post","link":"https:\/\/blogs.scummvm.org\/josejx\/2014\/06\/21\/returning-to-quaternions-and-rotations\/","title":{"rendered":"Returning to Quaternions and Rotations"},"content":{"rendered":"

Continued from the previous entry<\/a>.<\/i><\/p>\n

After a long hiatus, I’m working on completing the rotation and quaternion changes that arose as a part of fixing attaching and dettaching actors. To begin, I needed to rebase my old changes so that they applied to the current git master. With all of the progress that has been made since the start of GSoC, the patchset was out of date and doesn’t address all of the current uses of Quaternions<\/i> and Rotation3d<\/i>.<\/p>\n

In order to make this patchset easier to accept into ResidualVM, I’m splitting the work up into three distinct parts:<\/p>\n

    \n
  1. Rework of Rotation3d<\/i> to support the various Euler Angle orders<\/li>\n
  2. The final expanded Quaternion<\/i> implementation<\/li>\n
  3. The completed attaching and detaching code<\/li>\n<\/ol>\n

    The reasoning behind this approach is that a large portion of the current Quaternion usage is simply to convert from Euler Angles to a Matrix. By removing this extra step, the resulting code will be easier to read and more straightforward. After applying my previous changes to the Rotation3d<\/i> class, I created tests to check that the code was capable of converting from Euler Angles to a Rotation Matrix, and back again. In this implmentation, the user can specify the Euler Angle order by using the enum<\/i> EulerOrder <\/i>values, and building the Rotation Matrix with the member function buildFromXYZ<\/i> or using the constructor that takes three angles and the EulerOrder<\/i>.<\/p>\n

    Let’s take a brief detour here for a moment to explain how to add tests to ResidualVM’s test suite. ResidualVM uses CxxTest<\/a> as the framework to build unit tests. All of the tests can be found in the directory test<\/a>, with a directory inside that for each of the ResidualVM components tested. Currently, there are tests for the audio subsystem<\/a> and the common functionality<\/a>. In this changeset, I’ve created a new directory, math<\/i> and added a new file, rotation3d.h<\/i> which contains the unit tests for the Rotation3d class.<\/p>\n

    Unit tests are implemented by writing classes that contain the tests and CxxTest automatically generates the rest of the code to run the tests. So, to add a new test, we first include a header from CxxTest that defines the TestSuite<\/i> class. We then define a class that inherits from this base class and then implement our tests with each unit test as a public member of our class. Each of these unit test functions return no value and have no parameters. To actually test a value, CxxTest provides assertions<\/a> which should be used to report the test result.<\/p>\n

    Since math isn’t already a part of the testing structure, we’ll need to add a new directory to the unit test build system. To do this, you must add the test header files to the build by adding them to the module.mk<\/i> file in the test root. So, to add our new math tests to the unit tests to be built, I modified the TEST variable with the text in red:<\/p>\n