Here’s a some screenshots of OculusWorldDemo, showing a bit of how the post-render, pre-warp shaders interact with FOV and IPD — and the larger system that the functions I’ve been hijacking are meant to be a part of.

(Note: the demo was targeting the DK1)

The defaults:

With “zero IPD” toggled:

Max FOV at 45.4 degrees (can’t go lower than 20, which is similar):

Max FOV at 130 degrees (it goes higher, but you see no change):

These are just the things easily exposed in the demo’s menu; they don’t do exactly what we’d want to test.

“Zero IPD” is described as:

 // ForceZeroIpd does three things:
 // 1) Sets FOV to maximum symmetrical FOV based on both eyes
 // 2) Sets eye ViewAdjust values to 0.0 (effective IPD == 0)
 // 3) Uses only the Left texture for rendering.

So that’s about what we’d expect to see.

Max FOV is used similarly to the clamping function mentioned in earlier posts, and is an FovPort; it looks here that FovPorts may have more viewport to them, than FOV.

It’s still not clear exactly how best to build modified FOVs.  We need more complicated scenes; here are a few things we might use to generate them:

Unity

Unity has a nice editor, and we can expect students to be familiar with it.  I don’t think we get source code.

Unity claims they’ll have Rift support for free users soon.  That was in September.

Unity pro already has support, and costs either $75 / month (with a 12 month contract), or $1,500.  That’s per component; if we want the base and android, that’s $150 / month, or $3,000.

For educational licencing, we could contact them as suggested on the official site:

https://store.unity3d.com/education

Or purchase from the official reseller:

http://www.studica.com/unity

They offer all components in a watermarked version for $150 per year, individual components for a one-time $750, or all components for a one-time $1,999; we’d want the main component, and maybe android or ios.

These are all pre-orders for Unity 5.

Studica claims all of their discounts end on October 31st, 2014.

Unreal Engine

With this we get source; it’s unclear how it compares to Unity.  They also have a visual editor, and some weird pegs-and-wires visual programming system that I’m a little curious to see in the wild, how it shapes the way people think about programming.

Free to students via the Github Student Developer Pack.  They’ve given me access for a year; I think there’s some kind of renewal process after.

Free to schools by filling out the form at the bottom of this page.

Non-educational licences are $20 / month; with both educational and non-, they claim 5% of your profits if you launch a commercial product.

Just Load Something and Draw It

Both of those will sometimes be inflexible; even with the full source code of Unreal, even simple modifications mean a lot of learning their system.  Implicit in the act of research is doing things established engines don’t expect.

For quick tests and simple scenes, we might want a really barebones way to load, manipulate, and render models.  For that, I’m looking at Open Asset Import Library.

I haven’t yet had time to look at these in detail; a future post may have some kind of comparison.

Current plan is to go ahead without the Oculus SDK’s clamping; worst case, we can compare against default Oculus renders.

This means the next step is finding scenes to display — I’m going to take a quick look at Unity and Unreal, while integrating with our in-house code.

Also, there’s a guy (Oliver Kreylos, of UC Davis and Vrui) who made a simulator of sorts for the Rift’s optics.  Interesting for at least two reasons:

1. It might be useful to build something similar ourselves, to ease exploration and explanation.

2. He’s really gung-ho about eye tracking, but concedes (to his blog commenters) that placing the virtual camera in the center of the eyeball (rather than an unknown pupil) is an okay approximation.  It results in the point of focus being properly aligned, and the Rift’s lenses help to minimize off-focus distortion.

In the following pictures, the eyes are focused on the top corner of the diamond.  Green is the actual shape and incoming light; purple is the perceived path of light and perceived shape.

Centered at “rest” pupil (and poorly calibrated?):

Centered in the eye, but no lenses:

Centered, with lenses:

His posts and videos here:

http://doc-ok.org/?p=756

http://doc-ok.org/?p=764

First link talks about the Rift in general (20 mins); the second link talks about centering the virtual camera within the eye (5 mins).

I’ve found a path by which the Oculus SDK generates the field of view (FOV):

CalculateFovFromHmdInfo calls CalculateFovFromEyePosition, then ClampToPhysicalScreenFov.  (It also clamps eye relief to a max of 0.006 meters, which is thus far not reproduced in my code.)

All from OVR_Stereo.cpp/.h.

CalculateFovFromEyePosition calculates the FOV as four tangents from image center — up, down, left and right.  Each is simply the offset from image center (lens radius + the eye offset from lens center) divided by the eye relief (distance from eye to lens surface).  It also does that weird correction for eye rotation mentioned in an earlier post; the max of the corrected and uncorrected tangents are used.

ClampToPhysicalScreenFov estimates the physical screen FOV from a distortion (via GetPhysicalScreenFov).  It returns the min of an input FOV and the estimated physical FOV.

Last week’s images were made using Calculate, but not Clamp. Clamping makes my FOV match the default, but adds odd distortions outside of certain bounds for eye relief (ER) and offsets from image center (which I’m deriving from interpupillary distance (IPD).  I haven’t yet thought much about why, but here’s some quick observations in the direction of when (all values in meters):

Values for ER less than -0.0018 result in a flipped image (the flipping is expected for negative values, so we would expect this to happen as soon as we dip below 0; the surprise is that it waits so long).

Values of ER greater than 0.019 cause vertical stretch, fairly uniform in magnitude between top and bottom, and modest rate of increase.  It seems fairly gradual with the current stimulus.

Those both hold fairly well for all values of IPD.  However, bounds on IPD are sensitive to ER.

At negative values up to -0.0018, IPD doesn’t cause distortions (tested for values >1 and <-0.7).  It’s clearly entered some kind of weird state with negative ERs; something to keep in mind for future debugging / modeling, but we shouldn’t need negative ER directly.

At ER of 0.0001, IPD distorts outside of range 0.0125 to 0.1145.

At ER of 0.01, IPD distorts outside of range 0.034 to 0.094.  (This ER is the Oculus SDK’s default.)

At ER of 0.019, IPD distorts outisde of range 0.0535 to 0.075.

Large IPD cause the image of both eyes to stretch away from the nose, small values towards.  The distortion is drastic and increases fairly quickly with distance from the “safe” range of IPD values.

These ranges might be a little restrictive for our concerns, but should be workable; another worry is that the distortions may imply the clamping method itself is flawed.

We’ll also need to be aware of when things get clamped when designing experiments that care about specific values for IPD and ER.