Forum Discussion
Solved
Cursor Lock unavailable ?
Hello,
I recently tried to update some old "0.6" app to the new "1.3" drivers - it's a seated experience where the user can look at various UI elements to 'click' them.
For this, I lock the cursor in the middle via Cursor.lockState and just use the standard Unity UI (with in-world Canvas). Everything worked fine before, and still work in the editor - but not once built.
With a built app, if I have both the Oculus API and "Virtual Reality Support" enabled (in Unity's player options), the LockState stay at "none" - whatever my scripts try to do. Removing the Oculus plugin or unchecking "VR Supported" put thing back to normal, but then the Oculus doesn't work.
This is very problematic because it make the whole "look at a button to press it" concept very uncomfortable, as it force the user to manually center his cursor at the app's start (and moving accidentally your mouse mess up everything). This problem appear even on a new, nearly empty project with just the Oculus plugin and a few scripts trying to mess with the cursor's state.
Is this an intended behavior, or a bug ?
In any case, does someone have a way to correct it ?
I could add Colliders to every UI elements and then perform ray test from the camera, but that's basically recreating Unity's UI/EventSystem in a less optimized way.
I recently tried to update some old "0.6" app to the new "1.3" drivers - it's a seated experience where the user can look at various UI elements to 'click' them.
For this, I lock the cursor in the middle via Cursor.lockState and just use the standard Unity UI (with in-world Canvas). Everything worked fine before, and still work in the editor - but not once built.
With a built app, if I have both the Oculus API and "Virtual Reality Support" enabled (in Unity's player options), the LockState stay at "none" - whatever my scripts try to do. Removing the Oculus plugin or unchecking "VR Supported" put thing back to normal, but then the Oculus doesn't work.
This is very problematic because it make the whole "look at a button to press it" concept very uncomfortable, as it force the user to manually center his cursor at the app's start (and moving accidentally your mouse mess up everything). This problem appear even on a new, nearly empty project with just the Oculus plugin and a few scripts trying to mess with the cursor's state.
Is this an intended behavior, or a bug ?
In any case, does someone have a way to correct it ?
I could add Colliders to every UI elements and then perform ray test from the camera, but that's basically recreating Unity's UI/EventSystem in a less optimized way.
- Using the Windows mouse cursor with VR is not recommended. We've written a better gaze-based cursor system for Unity's UI, which you can read more about at https://developer.oculus.com/blog/unitys-ui-system-in-vr.
31 Replies
Replies have been turned off for this discussion
- It does sound like a possible per-object culling issue. If you're using Camera scaling, be sure to scale your near and far clip planes by the same amount.
> I have no easy way of replicating it without providing my whole project.
If you click Help > Report a bug..., it will upload your whole project (securely and under NDA) for Unity to reproduce on their end. - I'd like to file a bug report but currently I have no easy way of replicating it without providing my whole project. The objects that are fading are created at runtime using obj importer and I have a feeling that it's something to do with Unity the scale of the object and something getting confused and thinking the object is really far off and fading it out to cull. It's only a guess but the best I can come up with at the moment.
- > weird thing that happens with some of my objects disappearing fading out when move away from there
That's odd, be sure to file a bug with Help > Report a bug. - @vrdaveb Thanks for the info. I'll look into that.
@delphinius I'll also look into that. Although I'm currently stuck on 5.4.0f1 as there is a weird thing that happens with some of my objects disappearing fading out when move away from there. It's very odd and I can't find any information on it. Still, currently the version I'm on works so I'll stick to that :) - > I've discovered that if you click on the outside of the window and then back in again that the mouse becomes locked again
This should be the case for Rift and other VR headsets.
> OnApplicationFocus function returns false even though it is focused until you've done this.
There is a known issue where OnApplicationFocus gets called the same way for two different kinds of focus: keyboard focus and Oculus VR focus. It only gets called with true if the app has BOTH kinds of focus, but you can check OVRManager.hasVrFocus to see whether the app has Oculus VR focus. - There's a patch note in the latest patch release that might be applicable:
- (803319) - Windows Standalone: Fix regression where "touch up" events would be lost when occurring outside window bounds.
Maybe a version update would help? - Although that seems to be true it doesn't seem to happen when using the Vive, just the Oculus. I've also discovered another explanation relating to this which I've commented on in the ticket.
I've discovered that if you click on the outside of the window and then back in again that the mouse becomes locked again. I've also notice that the OnApplicationFocus function returns false even though it is focused until you've done this.
So Unity's own OnApplicationFocus falsely indicates whether the mouse is in focus or not.
I've added a mouse isn't in focus dialogue to my player so people know in the headset when the mouse is outside the area but this is just annoying most people.
If anyone can come up with any suggestions I'd be very greatful :)
- We talked more about this and, unfortunately, there isn't a good answer because VR focus and keyboard focus are two separate things. If your app loses keyboard focus, it will also lose the mouse cursor lock, so you need to re-lock the cursor when you get keyboard focus back.
- Thanks for re-testing. Unity has reproduced the issue and assigned it for an upcoming release. Not sure exactly when that will ship yet, but I will keep you posted.
- I can confirm that this is still an issue in the build 5.4.0F1. If you're interested in getting this fixed visit the bug page and up vote the ticket.
