3D SICK

Posts Tagged ‘video games’

Using an immersive display, especially one which is head-mounted can cause “simulator sickness”, which is a variant of motion sickness provoked by immersive virtual environments, although it perhaps, cannot be yet weighted against space sickness.

In theory, nausea, or motion sickness may be caused by the disparity in visual and proprioceptive feedback. Proprioceptive translates as the ability to sense the position, location, movement and orientation of the body and its parts. It is this ability that enables one to contact both left and right fingers when the eyes are shut.

How is this related to games, one wonders? The response comes in the singular word “lag”, the blight for all virtual reality canvassers. A computer captures a definite quantity of time to process user input, and consequently establish the next course of action before finally constructing a suitable output. The critical lag factor in Virtual Reality, games and simulation is positioned in the divergence between a user’s input (or action) and the computer’s retort (or reaction). Research in cognition implies that if the lag factor remains at approximately one tenth of a second, depending on the assignment, the user is still in charge. More than that and the user’s exploits do not correspond to the reaction.

The right thing to do would be to maintain constant head movement. You might say that this will not pose any difficulty because on your device, the Quake lopes at 60Hz. However, do keep in mind that the amount of time between your mouse click and the manifestation of a missile on screen is the vital issue, and not your frame rate.

Case in point: –
Sustaining a 100Hz frame rate and a 0.1 second lag. At the most, not exceeding ten frames goes by is flanked by the instance the user shifts the mouse and the screen transforms to mirror the move – the appearance of a new door on the edge.
If the mouse is illustrated at 100Hz, worse to the worst, the user’s progression happens momentarily after the sample is obtained. The lag factors at 0.01 second as it is quite some time before the mouse’s sample resumes.

With the sampling rate being 100 times per second, how many times can the IO controller positions info on the bus? A 0.01 second of lag is affixed.
Not counting hitting the main CPU, let us lever the IO interrupt. To handle this matter, append 0.01 second of lag for the kernel-level contact switch, and the ratio is elevated to 0.03 with a balance of 0.07.

At last, the CPU receives the click. Imagine that the game is coded quite well, and to decipher the click takes approximately 10 milliseconds. Anticipating that the event table did not get swapped out, observe the consequent action. Next, acquire the geometry for the said door to situate on the display. Remember to pre-load it or you run the risk of ruining the lag budget. The countdown is now 0.04.
To get through the middle of the “lag barrier” at 0.05 second, go from beginning to end all elements in the game, including monsters, artificial intelligence, so on and so forth at a munificent 10 milliseconds.

At 10 milliseconds, 0.06, process all the geometry including visibility and all other transforms you cannot achieve on the frame buffer.
0.07 is what you get after handling the bus plus shipping all geometry exported to the graphics accelerator for another 10 milliseconds. The deed is done!
Think again. Everything is not drawn. For example, the card completes all geometry conversions, clipping etcetera in the math-compatible 10 millisecond. 0.08 and counting down.
Proceed to rasterizing each polygons. Trouble arises. 0.09.
Dispatch the frame over to the screen. It’s now 0.01 and we got there just in time.
Afraid not. Make another attempt. The display is revived at 100Hz, and the ship has sailed. For good.
As this is a manufactured instance, the “lag budget” is not over by a large margin. Hasten a few components such as the bus, dawdle on the rest and insert all software layers. The point we are trying to drive home is that end-to-end lag may be exponentially bigger than rate might point to through the numerous corresponding steps in the pipeline. In this case, it is more than ten times. If you add network traffic, the situation metastasizes.

If the lag becomes intolerable, the imminent likelihood for simulator sickness when the primary poster becomes really absorbed is in fact quite real. This is the relevance of the question of OpenGL versus DirectX. With OpenGL, the lag falls just below the poster’s doorstep, whereas with DirectX, it will be just above it. The monitor remains in congruent with OpenGL, but will most certainly lag behind in DirectX. Perhaps the moment has come to disgorge your cookies.

This is the sort of substance which can be hard to control. Although it is akin to real-time computing, there are no assurances as opposed to what you can acquiesce with a genuine real-time environment. Under normal circumstances, RT environments possess a permanent task integer, the occasion to control thee integers is within your grasp. But alas, a game operates in an entirely different manner. For instance, if the player is in front of a wall which consists of between one to two sizeable polygons, and decides to look back to witness the superb million-polygon Great Hall, the rest as they say, is history. You will be at a complete loss of the time frame it will take to complete the course of next actions.

Incoming search terms for the article:

• video game nausea (4)
• 100hz sickness (1)
• video game vertigo plugged ear (1)
• nausea playing video games (1)
• how to stop having motion sickness playing video games (1)
• how to stop getting nauseous from playing games (1)
• how to avoid being dizzy when playing computer games (1)
• Do video games cause dizzyness? (1)
• cure motion sickness playing game (1)
• biobands simulator sickness (1)
• 3d sickness games (1)
• 3d movies on 100hz (1)
• video games nausea (1)