IPD settings and key mapping

The keyboard controls for the IPD start on line 254 of OVRMainMenu.cs in the function UpdateIPD(). By default it uses =/-.

The definition of the IPD is in OVRCameraController.cs, and it looks like it grabs the value from the hardware (OVRDevice).

thanks !

but does it mean you can set any value for IPD in CameraController.cs without any effect since it keeps the hardware value (0.064) ??

What I'm trying to do is to diminish the motion sickness by adjusting the IPD but I may be wrong. May be it's useless to set a different value for IPD and keeping the same hardware (which has no IPD adjyustment knob) ?

thanks

cyril

On a german keyboard, press "+" to increase the IPD (instead of "=").

yes but the problem, on a frecnh keyboard is to DECREASE the IPD, you only can increase it with the +/= key.

anyway if I can modify it in Unity there is the solution.

the real question for me is how this software change would affect the simulation since the hardware has no IPD knob

cyril

Changing the IPD value in OVRCameraController doesn't have any effect. Like cyberreality points out, it pulls 0.064 from the device with GetIPD() which, in turn, looks like its getting it straight from the DLL (unless I'm reading it wrong). What has me scratching me head is that removing "OVRDevice.GetIPD(ref IPD);" from InitCameraControllerVariables() doesn't appear to change anything.

Maybe replacing the IPD references in UpdateCamera() (where it seems to be put to use) with a new variable would do the trick, but I'm not sure where else the hard-coded 0.064 is getting used, and if that would result in a mismatch somewhere.

I stopped tinkering with it when I discovered how much debate there is over the merit in changing the IPD because, as cyril mentions, the physical IPD on the headset is fixed.

Just wanted to throw in here the fact that there are two IPD's to be aware of when developing: the device IPD, and the virtual IPD. I could be wrong, but as far as I know the device IPD (OVRDevice.GetIPD()) is fixed at 0.064 since the first devkit has no adjustable lens separation. The virtual IPD (OVRCameraController's Get/SetIPD()) determines the distance between the two eye cameras, and as the developer you can set this to whatever makes sense for the scale of the world you're working with, and let the user customize it from there to match their real IPD.

What I'm still not quite clear on is the whether software should care about the player's actual IPD, or if that is simply a problem for Oculus to solve with adjustable device IPD (by turning a dial to change lens separation, etc).

Could someone help me out with a quick sanity check? I'm not sure if what I'm seeing is unique to my setup.

Like I mentioned earlier, changing the IPD value in OVRCameraController doesn't actually change anything for me. Likewise, using SetIPD() from another script isn't changing anything either. It's the strangest thing, but the IPD variable seems to be cached somewhere. There must be something wonky with my Unity config, or I've got a script somewhere else that's causing the problem, but would someone else mind repeating the quick test below to see if you can reproduce the problem?

Just to throw it at the wall and see what happened, I created a new variable in OVRCameraController float myIPD = 100.0f (using a huge value so the effect will be obvious). Then, in UpdateCameras() changed

float eyePositionOffset = -IPD * 0.5f;
and
eyePositionOffset = IPD * 0.5f;

to

float eyePositionOffset = -myIPD * 0.5f;
and
eyePositionOffset = myIPD * 0.5f;

This works. The cameras are clearly 100 units apart.. then I change the value of myIPD to 0.064f and recompile.. the cameras are STILL 100 units apart. I can keep recreating this. Each new variable I substitute in UpdateCameras() works the first time, and is then locked into that value forever.

This could be a very simple C# or Unity feature I'm not familiar with. Or it could be gremlins in my computer. Can someone else repeat the above and see if they have similar (mis)fortune?

Interesting. I am seeing the same thing happen. It seems the value is cached somewhere.

At first I thought right-clicking the value in the editor and doing "Revert to pre-fab" would help, but it still seems to get the old value. Not sure if there is any good reason for this, let me see what I can find out.

No Occulus / unity developper here able to answer this weird cached values issue ?

and above all what is the main contributing factor to the motion sickness?
- IPD
- head tracking (translation motion tracking or lack of instead)
- use of prescription glasses (since the virtual image is projected at a far far plane which is a problem for short sighted people)
- resolution

more ?

thanks

cyril

Right now, my best guess is that one of the other OVR scripts is writing the value to PlayerPrefs, which is stored in the registry. It's the only "hidden variable" scenario I can think of, but I haven't found an instance of that happening yet.

I'll keep looking for a fix. I get motion sickness myself pretty easily, and I do find that adjusting the IPD makes the game more comfortable. I know there is debate about that, but it's been the case in my experience. I want IPD to be adjustable in my game, so I'm motivated to keep trying.

It also leads me to wonder if some developers don't feel it makes a difference because, although they believe they've changed the IPD value, because of this problem, they really haven't.