Forum Discussion
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
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
- 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! - 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.
- 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? "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.- 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! "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!
