Skip to main content
Up and Coming
July 25, 2014

Question about DK2 EyeCup in SDK

As far as I know, the DK 2 will ship with two eyecups, A and B.

Looking at the source code, there seems to be a "DK2 A" eye cup defined, but no mention of "DK2 B". Basing off of DK 1 eyecup code, I'm guessing DK2 A and B will be the same family and won't be any differences in constants?

I'm speculating here, but I'm guessing that the config util just always stores "A" in the profile or the code only ever uses that one "DK2 A" enum? Like if I choose the B lens in the config util, it won't accidentally fall back to "DK1 black"?

Well hopefully my DK2 will arrive tomorrow so I can find out my worries are unnecessary :D

    6 replies

    Participant
    July 25, 2014
    Hmm, interesting observation. It definitely does appear that the SDK has no constant for DK2's B cups in EyeCupType. GenerateHmdRenderInfoFromHmdInfo has no mention of the B cups either. All three DK1 cups actually use the same lens constants too, so maybe the distinction just isn't important for software?

    Oh, one other thing I noticed:
        // Obtain data from profile.
    char eyecup[16];
    if (profile->GetValue(OVR_KEY_EYE_CUP, eyecup, 16))
    {
    SetEyeCup(&renderInfo, eyecup);
    }

    The eye cup type is retrieved from the profile, but this variable is never used after it is set. Additionally, the OVR_KEY_EYE_CUP constant is only used here. Instead, the eye cup type is being determined based on the HmdType.

    ---------

    Also, I found this bit interesting:

    // Internal R&D codenames.
    // Reminder - this header file is public - codenames only!
    EyeCup_DKHD2A,
    EyeCup_OrangeA,
    EyeCup_RedA,
    EyeCup_PinkA,
    EyeCup_BlueA,
    EyeCup_Delilah1A,
    EyeCup_Delilah2A,
    EyeCup_JamesA,
    EyeCup_SunMandalaA,


    Look at all those hardware iterations!
    Participant
    July 25, 2014
    You are right. The code doesn't currently differentiate between eye-cups for rendering but should do so in the future. B & C cups don't actually produce collimated light which makes them difficult to model properly. Still an area of research here.
    Participant
    July 25, 2014
    Ah, that's interesting. Thanks for the response, brantlew!

    Do you know what the negative side-effects of this are off the top of your head?

    I'm not yet super familiar with the exact math behind the distortions that go on, just the general concepts. Would dealing with a non-collimated light lens involve a different distortion technique? Or is it merely the issue of accurately measuring the variables?
    Participant
    July 25, 2014
    "PathogenDavid" wrote:
    Ah, that's interesting. Thanks for the response, brantlew!

    Do you know what the negative side-effects of this are off the top of your head?

    I'm not yet super familiar with the exact math behind the distortions that go on, just the general concepts. Would dealing with a non-collimated light lens involve a different distortion technique? Or is it merely the issue of accurately measuring the variables?


    Distortion varies with eye position (IPD or eye rotation) a lot more under non-collimated conditions. Using the A cups with corrective lenses is the recommended way to use the device.
    Participant
    July 25, 2014
    That makes sense! I did not know that the non-A cups weren't recommended. Luckily I have good vision so I don't need the other ones.

    Thanks again for the info!
    Up and Coming
    July 25, 2014
    "brantlew" wrote:
    You are right. The code doesn't currently differentiate between eye-cups for rendering but should do so in the future. B & C cups don't actually produce collimated light which makes them difficult to model properly. Still an area of research here.


    C-cups? You mean for DK1 right? Would be awesome if there was C-cup for the DK2!
    "It's like Homeworld in first person." Disable Aero and vSync for a completely simulator sickness free experience with 2xHz FPS. Keep the config utility open for tracking to work.