Forum Discussion
BUG: ovr_GetRenderDesc always returns 'default' IPD (64mm) until slider is adjusted
I've just implemented support for live IPD adjustment. Testing with CV1.
As suggested, I am calling ovr_GetRenderDesc every frame. In all cases from the start, regardless of the the slider's position, the values returned indicate an IPD of 64mm (32mm each way).
When the slider is adjusted at some point, the reported offsets go to the true value.
As suggested, I am calling ovr_GetRenderDesc every frame. In all cases from the start, regardless of the the slider's position, the values returned indicate an IPD of 64mm (32mm each way).
When the slider is adjusted at some point, the reported offsets go to the true value.
30 Replies
- Do you think a fresh windows install could help?I already tried deleting everything related to the Oculus software I could find, but that didn't help.I can't imagine this being an hardware issue. But then again, I can't explain what's causing this.The scale is almost twice as big as it was on the DK2. (DK2 scale=life like for me)
- I think I have the same problem with the CV1.
In released VR Applications like Oculus Home or Chronos, everything looks unnaturally small to me ( I have an IPD of ~59 mm ) and in my own engine, I can not use the HmdToEyeOffset() functionality of the SDK since it always returns two cameras with a distance of 0.064 units. Is this expected behaviour?
Are we developers responsible for giving the user an option to set their IPD? Seems kinda pointless with the headset having the nice IPD adjustment functionality... - Sorry for the delay. I must have missed this thread somehow. I will share the feedback with the team and report back if I get any news. Thanks.
- @cybereality
you can have a little log to help you in your report :smile: (but it is dk2 ) because this plague everyone since the launch right now.
I have none of this files on my computer, but i believe at home, i have the ipd issue while i have the files, i will provide a log from that other computer tonight with a cv1VRINF: [CAPI] LibOVR module is located at C:\Program Files (x86)\Oculus\Support\oculus-runtime\LibOVRRT64_1.dll11/07 13:37:55.336 {DEBUG} [Client] Connected to the server running version (prod = 1).1.5.0(build = 241049) feature version = 0. Client runs version (prod = 1).1.5.0(build = 241049) feature version = 0
VRDBG: Connected to the server running version (prod = 1).1.5.0(build = 241049) feature version = 0. Client runs version (prod = 1).1.5.0(build = 241049) feature version = 011/07 13:37:55.337 {DEBUG} [Kernel:Default] Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/ProfileDB.json
VRDBG: Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/ProfileDB.json11/07 13:37:55.337 {DEBUG} [Kernel:Default] Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/Profiles.json
VRDBG: Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/Profiles.json11/07 13:37:55.337 {DEBUG} [Kernel:Default] Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/ProfileDB.json
VRDBG: Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/ProfileDB.json11/07 13:37:55.337 {DEBUG} [Kernel:Default] Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/Profiles.json
11/07 13:37:55.337 {DEBUG} [Kernel:Default] [HMDState] Using default profile default
VRDBG: Failed to open file: C:\Users\nsilvagni\AppData\Local\Oculus/Profiles.json11/07 13:37:55.337 {INFO} [Kernel:Default] IAD changed to 64.0mm
VRDBG: [HMDState] Using default profile defaultVRINF: IAD changed to 64.0mm11/07 13:37:55.337 {DEBUG} [Kernel:Default] [SharedMemory] Creating factory
VRDBG: [SharedMemory] Creating factoryAdd gamepag 1891710823896
- Update a couple days ago for anyone following this issue.https://forums.oculus.com/developer/discussion/comment/421516/#Comment_421516
Actually, you may be right. I just wrote a quick C++ console app, and the value of HmdToEyeOffset is always +-0.032 regardless of the slider. Let me have an engineer look deeper into this. - @cybereality - Thanks for the info. It is quite hilarious how hard it is to get Oculus developers to look into a bug. I love cyber's comment "Actually, you may be right." as if he had never heard of this before. And @tomf denying the bug four months ago, then ignoring us confirming that the bug really does exist. Exasperating!
- I'm really sorry for the delay. I don't think I initially understood how serious this issue was and didn't do a proper investigation. I can confirm that it is happening for me too. I have a bug report filed already, and will be sure to stay on top of the engineering team until this is resolved. Thanks.
- So relieved you're on top of this @cybereality! Makes a big difference for us 71mm guys. :)
- So, whatever became of this bug?
- The issue has been fixed and still is as far as i am aware.
