I spent a long time over the summer mulling over a tricky flight problem and after many laps of the local park, flapping my arms like a bird to get into the appropriate mindset, I finally cracked it.
The Gliding Problem
[ NB the PLAYER spends the whole experience lying on their back looking up at the ceiling, arms outstretched, each hand holding a motion controller]
The Snow Angel Flight solution I started experimenting with at the end of last term involved calculating the dot product between two vectors: one was the forward vector and another was the vector from the position of the VR headset to the position of the motion controller.
Starting from the T-pose if the PLAYER moves their arms up towards the head (at the furthest extreme the arms are by ears) the dot product value gradually changes from zero to 1. From T-pose to arms by the side, the dot product values gradually change from zero to minus 1. By comparing the two dot product values one for the left and one for the right motion controller, it was possible to work out whether the arms were level i.e. in T-pose — in which case the PLAYER flies straight ahead — or if one arm was closer to the head or closer to the hips than the other then their direction of travel would rotate toward the left or the right.
Specifically…
To steer: the dot product for left arm to HMD versus forward_vector(value 1) was subtracted from right arm vs HMD dot product (value 2) such that when a threshold was crossed (e.g. larger than 0.2 or smaller than -0.2) the direction of travel would change by adding torque (yaw) to point the direction the direction of travel towards the left or the right accordingly.
This all worked just fine, but then...
Problems started arising when the PLAYER was given the power to change altitude. To dive —they would move both arms toward their sides which added torque (pitch) to steer the direction of travel to point downwards so that they start to lose altitude. To pull up — they would move both arms towards their heads which reduced torque (pitch) to steer the direction of travel to point upwards so that they started to gain altitude. As soon as the pitch changed significantly the dot product values produced by the left and right motion controllers would go haywire and ultimately cause a tailspin.
THE SOLUTION
The reason for the tailspin was that the changes in pitch angle changed the local horizontal plane in virtual reality, but in reality the plane of the horizontal stayed the same. To stop the tail spin all I had to do was to make sure that as the forward direction of the VR Player pitched up and down, so too did an attached game object which I called the “BasePlate”. So long as the script that was detecting the location of the motion controllers and calculating the Dot Products was attached to the Base Plate (which always stays in the same plane as the HMD and motion controllers i.e. flush with the floor in reality) then the Dot Project values will be accurate no matter whether the VR Player was pitched up, down or parallel with the ground.
Next up, detecting flapping motions…
