Test existing simulator sickness solutions, and our own potential solutions, especially ones that will help with our own VR projects with a 1-week research project.
While there are no sure-fire solutions , we managed to get some best practice guides that will be immensely helpful for our next VR projects.
If you ever tried using any Virtual Reality (VR) experience, you might be familiar with its simulator sickness. It’s somewhat similar to the motion sickness that some people feel when they’re reading something, while in a moving vehicle. It’s can make you feel dizzy, queasy, even may put you out of commission for several hours.
We’ve tried a several of VR experiences, and developed a couple ourselves; and simulator sickness is definitely one of our top concerns. There are already design guidelines available from Oculus Rift, Google Cardboard, and others, to minimize this. But there are some solutions that either haven’t been covered there, or ones that we needed but haven’t been specifically addressed. So then we thought, hey, why not do a little research project ourselves?
We’ll be honest from the beginning here: this is just a mini 1-week research project, and we only used a sample pool of 5 testers, so it’s by no means a scientific research. But, even then, we managed to get some conclusions that are useful for us, and hopefully also for you!
The project was split into 7 days:
Day 1: Listing specific scenarios that may cause simulator sickness
Day 2: Developing the app to test the problems
Day 3: Testing them in an as isolated manner as possible, and then picking the most prominent ones.
Day 4: Listing potential solutions
Day 5 – 6: Developing the app to test the solutions
Day 7: Testing them also in an as isolated manner as possible, and then trying to get conclusions from the result.
Since so far we’ve only collected possible problem sources from online sources and anecdotally from our own experiences, they were just a collection of vague ideas our minds. Obviously, that won’t be a good start for a research. So off we went to cast a little order in the chaos.
We listed the most basic elements of the problems. There were 15 types of elements, each with a couple of different alternatives. For example for the “speed” element, there were two alternatives: normal and high. For “level of control” there were also two: full control in first person shooter (FPS) style setup, and no movement control where the user simply follows a predetermined track.
The last one is actually very important for us because one of our VR projects is of that type, and there’s a likelihood that there will be more of that in the future.
After creating the list, we chose and combined them to a series of 13 scenarios that we think covers all those potential problem sources.
The next day, off we went to Unity for a full sleepless day to develop the simulation app for those scenarios. Not much to be talked about here. Some coffee got consumed, some error messages got cursed. Just the usual programming stuff. And this was what we created:
The test setup was simple: each the testers played each of the simulations, and after each one, we asked them a series of questions in the Simulator Sickness Questionnaire.
By the end, we managed to get two of them so sick they can only lay down for several hours, while interestingly, the rest of them survived the ordeal with little to no effect. That’s our first glimpse of just how wide-ranging people’s immunity to simulator sickness can be.
Here’s one of the graphs that we got from the data. The x-Axis is the scenario number, y-axis is the simulator sickness score.
As you can see, while there are similarities between each person, there are also a lot of variations. Predictably, perhaps, the ones with the lowest scores are the two people who are used to playing video games. So they might’ve built up tolerance over the years.
We listed several problems that we found, and split them into two categories: virtual, and reality. What did we mean by that? Well a VR experience has to sides to it. The virtual side is from the fact that it is a digital experience; and therefore it’s subject to digital problems such as lag.
The other side is from the fact that even when it’s not real, it feels real to a certain level. Obviously people get motion sickness from real life experiences, especially from extreme ones like roller coasters. So because of how “real” an experience in VR can be, we think it also stands to reason that similarly uncomfortable scenarios in VR will also induce that.
This one is the most obvious. Any digital experience, even when not in VR, will be severely degraded by lag, flickers, or low frame rate. And in VR it can make even the simplest most casual experience almost intolerable to some people.
This one is also very popular and might be the main source of VR’s simulator sickness. The effect is from conflicting information from our sight and our vestibular system (the inner ear system that detects movement). Simply put, our eyes say that we’re moving, and our inner ear says otherwise. This conflict is mostly caused by accelerations both in position, and direction.
This one was unpredicted. Some of the testers reported that they feel worse after taking of the VR display.
People can get nauseated from car/boat rides, roller coasters, or even when someone grabs them by their shoulders and then shaking them. So any experience that feels like that might cause the effect.
This is from any movement or rotation that is outside of the user’s control that happens without clear warning. In real life, this would be akin to if someone suddenly swivels your office chair. In the on rail type experience this happens when the view direction suddenly changes without a clear indication. In the FPS type however, this happens when the movement direction is controlled via a joystick. The user usually lose track of which way is forward, so when their avatar moves, it moves in an unexpected direction.
This especially happens if the experience extensively uses head motion as input, e.g. rapidly shooting targets with directions from the head.
Now that we have a reasonable idea of what the problems are, comes the time to solve them. We chose 3 scenarios that represent the 2 types of experience: 1 for on rail and and 2 for manual control. And then gave each of them multiple possible solutions. More details below.
On Rail possible solutions:
Manual control possible solutions:
We got the “field of view (FoV) limiter” from a research by Ajoy Fernandes and Steven Feiner at Columbia University.
The VRStep is a VR control scheme that can be bought in Unity Asset Store.
Outside of the experience itself, we also wanted to test a cooling down screen, to reduce the worsening of the simulator sickness after taking off the VR display.
Back to Unity we went. Some more coffee got consumed, some more error messages got cursed. Then lo and behold! A brand new level. With a bit more flair added.
Not much to be talked about the testing process, other than now we are no longer putting people out of commission. So that’s a good sign at least.
Again here’s one of the graphs that we got from the data. Just like before, the x Axis is the scenario number, y axis is the simulator sickness score.
As you can probably see, the result contains a lot of variations from person to person. So, rather predictably, we haven’t come up with simple clear cut solution to the problem. But still, as mentioned earlier, we managed to get some conclusions. You can read the full conclusions in the part 2