I’ve found a\u00a0path by which the\u00a0Oculus SDK generates the field of view (FOV):<\/p>\n
CalculateFovFromHmdInfo<\/em> calls CalculateFovFromEyePosition<\/em>, then ClampToPhysicalScreenFov<\/em>. \u00a0(It also clamps eye relief to a max of 0.006 meters, which is thus far not reproduced in my code.)<\/p>\n All from OVR_Stereo.cpp\/.h.<\/p>\n CalculateFovFromEyePosition\u00a0<\/em>calculates the\u00a0<\/em>FOV\u00a0<\/em>as four tangents from image center — up, down, left and right. \u00a0Each is simply the offset from image center (lens radius\u00a0+ the eye offset from lens center) divided by the eye relief (distance from eye\u00a0to lens surface). \u00a0It also does that weird correction for eye rotation mentioned in an earlier post; the max of the corrected and uncorrected tangents are used.<\/p>\n ClampToPhysicalScreenFov <\/em>estimates the physical screen FOV from a distortion (via GetPhysicalScreenFov<\/em>). \u00a0It returns the min of an input FOV and the estimated physical FOV.<\/p>\n Last week’s images were made using Calculate<\/em>, but not Clamp<\/em>. 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). \u00a0I haven’t yet thought much about why, but here’s some quick\u00a0observations in\u00a0the direction of\u00a0when (all values in meters):<\/p>\n Values for ER less\u00a0than\u00a0-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).<\/p>\n Values of ER greater than 0.019 cause vertical stretch, fairly uniform in magnitude between top and bottom, and modest rate of increase. \u00a0It seems fairly gradual with the current stimulus.<\/p>\n Those both hold fairly well for all values of IPD. \u00a0However, bounds on IPD are sensitive to ER.<\/p>\n At negative values up to -0.0018, IPD doesn’t cause distortions (tested for values >1 and <-0.7). \u00a0It’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.<\/p>\n At ER of 0.0001, IPD distorts outside of range 0.0125\u00a0to 0.1145.<\/p>\n At ER of 0.01, IPD distorts outside of range 0.034\u00a0to 0.094. \u00a0(This ER is the Oculus SDK’s default.)<\/p>\n At ER of 0.019, IPD distorts outisde\u00a0of range 0.0535 to 0.075.<\/p>\n Large IPD cause the image of both eyes to stretch away from the nose, small values towards. \u00a0The distortion is drastic and increases fairly quickly with distance from the “safe” range of IPD values.<\/p>\n These ranges might be a little restrictive for our concerns, but should be workable; another worry\u00a0is that\u00a0the distortions may imply the clamping method itself is flawed.<\/p>\n We’ll also need to be aware of when things get clamped when designing experiments that care about specific values for IPD and ER.<\/p>\n","protected":false},"excerpt":{"rendered":" I’ve found a\u00a0path by which the\u00a0Oculus SDK generates the field of view (FOV): CalculateFovFromHmdInfo calls CalculateFovFromEyePosition, then ClampToPhysicalScreenFov. \u00a0(It also clamps eye relief to a max of 0.006 meters, which is thus far not reproduced in my code.) All from … Continue reading