Given a point in space, a direction of travel, and a time since start, what's a convincing, non-sickening formula to simulate head bob? What's been successful in previous games? Has there been any research on what bobs induce sickness the least?
An example naive head bob formula, applied to the up axis:
Gah! Don't change pitch. At all. Unless you want the player to feel like they're playing a drunk, and fighting the camera. Your focal point is set by the player's control, don't change it.
I'm not even sure it warrants a 'formula' - I think you'd be better served with some predictably random motion. Look into low frequency Perlin noise to generation your offset curves. Any simple formula you can think of will be predictable enough that it defeats the whole point of the bob - to give the impression that the avatar isn't moving in an artificial way. You can combine trig functions to get a pseudo-random smoothed curve, but you're far better off using Perlin noise which is perfect for this sort of work.
I'm not aware of any research on 'good' head bobbing, but I'd say if you're going to do it, you need to do some serious cold testing and iteration. You (the implementer) are not in a good position to judge the effectiveness of your implementation, because very quickly after you start, you'll become hyper-sensitised to the amount and manner of the bob. What others might find good, you'll obsess over and reject.
Most of all, keep the motion subtle. The temptation when implementing is to crank up the 'bob' factor until it's noticeable, because you want to see it taking effect. That's no good. Ideally the player doesn't even notice the bobbing - if you ask them after the testing whether they noticed their viewpoint bobbing when they ran, I think they should say no. The purpose of a bobbing motion in the viewpoint is to make the motion feel natural, so that you don't feel like you're sliding around as a camera on top of a wheeled dolly. The player's hind-brain will pick up on the artificial nature of a naive implementation, but it only takes small subtle variations from that to fool the perception.
There are many causes of nausea. Here are the environmental factors to consider:
(You normally don't have control over these environmental factors, unless you're making a gaming installation. In which case, you absolutely should be considering them.)
Remember that nausea is caused by a disagreement between what's being seen by the eyes and what's being experienced by your body's internal motion sensors in the inner ears; the more context that your brain gets that motion being seen by the eyes is not an actual motion (say, by being in a well-lit room with plenty of stationary objects visible behind the screen), the less nausea will be experienced.
In terms of the camera behaviour itself, any sort of automatic rhythmic motion can easily cause nausea. Rotations are worst (particularly tilting), but even rhythmic translations from side to side or up and down will cause nausea for many (but not all!) players.
For this reason, if you use camera bob, it's important to always include an option to disable it. Otherwise, many players will be unable to play your game for more than a few minutes at a time.
As a rule of thumb, the slower the cycle and the smaller the motion of the camera along that cycle, the less nausea will be caused for the players who are susceptible to it.
Additionally, sudden changes in velocity are particularly bad for nausea; any rhythmic motion you choose to use should be smooth through its whole arc, rather than 'bouncing' along any axis, the way that your example graph does.
It's also worth noting that most players do not have nausea responses immediately; those responses build up over a few minutes duration. Some games therefore only perform these sorts of camera movements periodically; for example, when the player is performing a duration-limited "sprint" move, rather than all the time when the player is running normally. It's still probably important to allow those who are susceptible to nausea to disable the effect entirely, but more users will be able to tolerate the effect if it's infrequent than if it's constant.
I'll just drop two additional ideas to the table.
First of all, have you ever seen Mirror's Edge first person camera in action? See this link if you haven't. I'm not sure about pitch, but there's quite a bit of roll changes taking place, and I think it looks very dynamic and fresh. So that's just a possibility for you to consider incorporating in your formula too, if you like the feel it gives.
Another idea which I don't know if any game uses, is to take a simplified animated 3D model of a character walking, and even if you won't be rendering, you can still gather head position information from it, or even attach your camera to the head's bone. And if the character has eye movement independent from his head, you could even incorporate both. I don't know how that would look in action, but I figure it should behave very realistically. But there's also a chance it could look extremely sickening too :-)
The human vision system includes some (pretty sophisticated) feedback control to allow the eyes to track the relative motion of objects. The ultimate effect of this is that, when you focus on a particular point, the image of that point will continue to be projected to roughly the same location on the retina despite motion of the point and your head. (As a simple demonstration: focus on a word on this page. Move your head around. Note how violently you have to move your head before the word begins to blur and displace from the centre of your field of view.)
To emulate this effect, when you displace the camera, you should also adjust the view direction so that whatever the player's eye is focusing on stays in the same location on the screen. Since you don't have any information about where the player is looking, the best you can do is to make the not-unreasonable guess that they're probably looking at the centre of the screen. This will produce an effect more similar to what you 'expect', which is subtly changing parallax as the viewpoint moves.
It's probably impossible to completely eliminate nausea. Motion sickness is typically a response to inconsistent sensory input. In a vehicle, the inconsistency is that the inertial information from the inner ear indicates motion, while visual cues indicate that you are stationary. With head bob, the converse will be true.
I definitely recommend against changing the pitch of the camera, since the camera's facing is under the player's control. Just using a sine function to subtly deflect along the vertical/Y axis usually works well.
