Motion Sickness In 3D Games?

James Ensor asks: "I've always been subject to pretty bad motion sickness ever since I was a kid. I especially have problems with some, but not all 3d games. Has anyone else had this problem and/or have any insight into why some games are worse than others/how to make games that don't cause it? An interesting side note, Games based on DirectX have been a much bigger problem for me than anything based on OpenGL. In fact, in games that support both, I often get sick playing the DirectX version, flip over to openGL and have no problems. Any thoughts?" I can see how some games might cause some motion sickness, but the DirectX/OpenGL connection is a new (but highly quesitonable) addition. Is anyone else afflicted with a similar malady?

Comments

Simulator Sickness

[nellardo]

"Simulator sickness", the variant of motion sickness induced by immersive virtual environments, can be some of the most intense motion sickness around. Though I can't compare it with space sickness (yet :-), I can say that I almost never get motion sick except when using an immersive display, especially a head-mounted one.

Last I read, the causes of motion sickness weren't well-understood, but the theory generally was that differences in visual and proprioceptic feedback is what induces nausea. "Proprioceptic" feedback is the knowledge (a sense, like touch or pressure, if you will) of where your body is in space and how the parts are positioned relative to each other. Proprioception is what lets you close your eyes and touch your left and right fingertips together.

How does this apply to games? The one-word answer is lag, the bane of all researcher working in virtual reality (in augmented reality it is even harder). User input occurs, and it takes a certain amount of time for that input to be processed by the computer, for the machine to determine what to do, and then to produce the appropriate output. The difference between the user's input (action) and the computer's response (reaction) is the critical lag factor in VR, games, and simulation. Cognitive experiments suggest that, so long as this lag is less than about a tenth of a second (the number varies based on task), the user feels in control. Greater than a tenth, and the user feels like their actions don't correspond to the reactions.

So, in VR, move your head. The screen needs to reflect this in under a tenth of a second. "No problem," you say, "because Quake runs at 60Hz on my machine." Yes, but frame rate is not the critical factor, but the length of time between your mouse click and the appearance of a missle on screen.

Let's run some numbers. Just to keep the math easy, lets say we'd like to maintain a 100Hz frame rate and a 0.1 second lag. So, at worst, no more than ten frames can go by between the time the user moves the mouse and the screen changes to reflect the move (e.g., a new door becomes visible on the edge.

• Suppose the mouse is sampled at 100Hz (that's fast, but let's keep the math simple). Then worst case the user's move occurs just after a sample is taken. That's 0.01 second of lag right there (it takes that long before the mouse is sampled again).
• Now how often can the IO controller put info on the bus? Probably no more than a 100 times a second - after all, that's the sampling rate. So add 0.01 second of lag.
• Now let's handle the IO interrupt. Add 0.01 sec of lag for the kernel-level context switch to deal with that. We're up to 0.03, with 0.07 left to spare, and we haven't yet hit the main CPU.
• So the CPU finally gets the click. Let's pretend our game is really well-coded and so it only takes us 10 milliseconds to decode the click, look up the corresponding action (hope the event table didn't get swapped out :-), and get the geometry for that door to put on the screen (better hope you pre-loaded it and you don't have to get it from disk now - that would blow the lag budget right there). 0.04.
• Now we run through all the other stuff going on in the game - monsters, AI, etc. Again, let's be generous - 10 msec. We're halfway to the "lag barrier" at 0.05 sec.
• Now process all the geometry. Visibility, any transforms you can't do on the framebuffer card, etc. 10 msec, 0.06.
• Another 10msec dealing with the bus and shipping all that geometry to the graphics accelerator. 0.07! Phew! We made it!
• Nope. Haven't drawn everything yet. Let's say the card does all the geometry transforms, clipping, etc. in our math-friendly 10 msec. 0.08.
• Now rasterize all those polygons. 0.09. Uh oh.
• Ship the frame to the monitor - 0.10 - we just made it!
• Bzzt. Try again. Your monitor refreshes at 100Hz, and you just missed it. 0.11 and we're over.

We're not over "lag budget" by much, but that's not the point. This was a contrived example. Now add all the layers of software and such in there, speed up some parts (the bus), and slow down others (gee, that fancy new AI isn't so cool anymore). The point is, many parallel steps in the pipeline, and end-to-end lag can be dramatically higher than frame rate might indicate (more than ten times, in this case). Add network traffic and, ugh.

So how is this relevant to the question of OpenGL vs DirectX? Well, it sounds to me that the original poster gets well and truly immersed, setting up the possibility for simulator sickness if lag gets ugly. And it would seem that the lag is just under the poster's nausea threshold with OpenGL and just over it with DirectX - the user moves the mouse and the screen keeps up with OpenGL, but lags behind in DirectX. Time to spew your cookies.

This kind of stuff is a bear to manage - it is like real-time computing only you don't have the guarantees you usually have in a bona fide real-time environment. Usually, RT environments have a fixed number of tasks to deal with - you know how much time anything is going to take (it's still a bitch dealing with it, but at least you know the bounds). A game doesn't work that way. If the user's facing the wall (one or two big polygons) and suddenly looks back over her shoulder to see the glorious million-polygon Great Hall, well, you get the idea. Bounds shmounds. You've got no idea how long that will take to process.

Motion sickness versus monitor sickness

[ptomblin]

I'm a pilot, and when I was first learning to fly I got motion sickness a lot. I got over it as I became more confident and less overwhelmed by all the new stuff I was learning. Now I get motion sickness when I'm flying with a "hood", a view limiting device used to simulate flying in non-visual "instrument" conditions while your instructor is still in visual conditions and can watch for other aircraft. But I'm fully confident that I'll get over that as well, once I'm not overwhelmed by trying to fly in a new way while studying the approach plate, tune the radios and get the plane set up for the approach while the turbulence is throwing me around.

I also sometimes get "monitor" sickness. I used to get it playing Quake 2, especially when playing it with software rendering. Getting a Voodoo II card was a major improvement. I think that supports the previous poster's theory that it has to do with the lag between doing something and the effects of that action getting rendered.

However, if I want to get so sick that I have to lie down for a few hours, I only need to watch my daughters play Team Fortress Classic. I don't know exactly what it is, but I suspect it's because I'm not in control so I'm not "ready" when the viewpoint whips around. I can watch for about 15 minutes and then I'm so sick I have to lie down for hours. This is worse than a 3 hour instrument flying lesson.

So sorry, I have no great insights as to how to cure it, but I would guess that a fast video card and bearing with it until it goes away might be the only things that will help.

--
A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.

More on Simulator Sickness

[cr0sh]

All you have said is very true - but one thing you left out (or maybe only hinted about, if you read between the lines, so to speak), is one of the main reason motion sickness occurs:

One set of senses are telling you one thing, while another is seeing (or perceiving, perhaps in the wrong way) another.

Case in point, for the poster: He is obviously well immersed in the game, but most of his body is motionless - however, his eyes are perceiving that he is in motion. These two conflicting inputs (that of the eyes seeing motion, but his inner ear telling him he's not moving) help cause the motion sickness he experiences.

How to help? Don't get immersed - have a frame of reference for your eyes that show them you aren't moving as well. Either sit farther away from your monitor, so that you see the edge of the screen, use a smaller monitor, or run the game in a window.

A similar way to get sick is to ride an amusement park ride with your eyes closed in the late evening. Kinda the reverse of what the poster is experiencing.

You talked about lag. In a fully immersed setup (High quality, 60 degree FOV or greater HMD, etc), lag can cause severe difference in inputs, if the lag is large enough. Say the screen is updating as you turn your head left, then you quickly turn your head to the right. The screen may still display the images of what you were doing when you were turning your head to the left, as you are really turning your head to the right (the Virtuality 1000 game system was notorious for this) - time to spew. Another problem with fully immersed systems can be sensor calibration - this would help cause motion sickness, either by say - an electrolic tilt sensor "sloshing" after physical movement has stopped - and hence displaying to the user they are still moving, or by the sensor being out of alignment with the users actual position - maybe in an extreme case giving the user the image of him looking up, when he is trying to look straight ahead.

From my personal experience, I don't have a problem with immersed or semi-immersed virtual environments, even ones with bad lag. Maybe I have just adjusted, or for some other reason it doesn't bother me. What is strange though, is that I find reading while in an automobile (as the passenger, of course) makes me feel a little queasy - at least enough where I don't like to do it...strange...

Here is a link to a paper done on simulator sickness for the U.S. Army Research Institute, by Eugenia M. Kolasinski:

Simulator Sickness in Virtual Environments