Physics and Control: Rotation

Early on while working on this game (and the general platform concept) I had figured out a detailed set of keyboard shortcuts for camera management. It took about 30 seconds after implementing some of it to realize that for what I was trying to do, manual camera management had to go. I had to come up with an effective way of automating the camera so the user wouldn’t have to.

There’s the high level and low level of it. The high level is what algorithm to use to position and direct the camera. The general goal is “keep useful things in view and filling as much of the view as possible”. We’ve already been through two ideas for that and I expect we’ll be iterating further for it.

At the low level, I wanted even the camera to simulate proper physics. The position of the camera is straightforward. We can use the same position control we use for all the other items. Orientation was much more complicated. I wasn’t planning on implementing rotational control for items in the world (though, that could change), but for the camera, it’s required of course.

Representation of rotations is typically done using quaternions, which is what we’re using. Angular velocity and acceleration can be represented by vectors. We searched around trying to find control algorithms for rotations and couldn’t find anything. There’s SLERP and SQUAD but those are interpolations that by themselves don’t simulate physics.

In the end, I realized that the rotational case could be modeled just like the positional case. That one could decompose the angular velocity vector just like I had done with the translational velocity vector. Such that we can even reuse the exact same code that handles the 1D case. We’re running into the inaccuracy of floating point arithmetic, but we have this mostly working.