UnityVr vs Oculus Utilities

Depending on how long it will take for Unity to add all necessary stuff from Oculus Utils into the engine, it might make sense for Oculus to release stripped down Utils that can be dropped into Unity VR examples with a detailed tutorial how to hook up most critical (for the app/game to be accepted to Oculus Store) functionality. Although I doubt that will ever happen :roll:

@vrdaveb: Do you think you guys can make such stripped down version of Utils to work with Unity's VR examples ?

We are working with Unity on a plan for reconciling the Utilities and their new VR samples. There is nothing to announce yet, but you are free to modify both.

"vrdaveb" wrote:
We are working with Unity on a plan for reconciling the Utilities and their new VR samples. There is nothing to announce yet, but you are free to modify both.

Thanks for chiming in!
This is exactly the info I was looking for :)

Is there an update or a timeframe for this?

Just wondering if I should be trying to integrate both packages now, or wait a month and there's going to be a better solution?

There is nothing specific to announce at this time. My expectation is that given their newness, the samples will probably change more over the next several months than the utilities will.

Ok thanks, I was looking through it and there isn't much that needs to be changed around to get it to work. Thanks for the update.

After some testing, I'm not that happy with the Oculus Utilities (including the UI sample).

- I have troubble with the OVR Character controller. In some cases it starts to rotate very slow vertically by looking left and right. (Seems a problem with calculating the world matrix, in that case the OVR Gazepointer has an offset, too)

- Why does the GazePointer use RaycastAll and sort the result? Why not a simple ray? The OVR solution is very slow and detects the "gazable" objects through walls. Removing the gazable layer mask would be way too slow. Where is the benefit to detect more than the closest target?

- The OVR Input solution is properitary and doesn't depend on the Unity "CrossPlatformInput", what makes it really annoying to change the controller settings.

- The OVR-Input throws a compiler warning, for using deprecated code.

- I'm not convinced by the mouse pointer logic in the OVR Input.

I got the best results by using only the UnityVR implementation (and a modified FPSCharacterController) with classic "CrossPlattformInput" and my own (simple ray) gaze pointer.
The OVR Utilities are a little bit over complicated and not really following the classic Unity style. I would welcome a deeper cooperation between Oculus and Unity here.

"conz" wrote:
I have troubble with the OVR Character controller. In some cases it starts to rotate very slow vertically

You mean OVRPlayerController? Sounds like dead zone is too tight for your controller. In a future release, we're planning to increase it a little to prevent this. In the meantime, can you change the 0.15f dead zone in OVRInput.cs to 0.2f?

"conz" wrote:
Why does the GazePointer use RaycastAll and sort the result?

It sounds like you're using the sample VR UI project from our blog (https://developer.oculus.com/blog/unity ... tem-in-vr/). That isn't part of the Utilities, it's a drop-in replacement for the usual mouse-driven input modules in UGUI. It implements Unity's GraphicRaycaster interface, which returns all hits in sorted order. This is more flexible than Physics.Raycast and Unity probably needs it for a number of corner cases in their UI logic.

"conz" wrote:
The OVR Input solution is properitary and doesn't depend on the Unity "CrossPlatformInput", what makes it really annoying to change the controller settings.

OVRInput is designed to be similar to UnityEngine.Input, which drives the undocumented CrossPlatformInput class's StandaloneInput back-end. Unity prefers not to include any Oculus-specific code in their Standard Assets, but we are still working with them to expose this in a cross-platform way.

"conz" wrote:
I'm not convinced by the mouse pointer logic in the OVR Input.

Which logic is that?

"conz" wrote:
- The OVR-Input throws a compiler warning, for using deprecated code.

I'm unable to reproduce this. What Unity version and Utilities version are you using? What is the warning? Is it in OVRInput.cs or OVRInputModule.cs?

"conz" wrote:
The OVR Utilities are a little bit over complicated and not really following the classic Unity style. I would welcome a deeper cooperation between Oculus and Unity here.

Sorry, but I need more detail to understand what is wrong here. Can you describe what part of the workflow is too complicated and how you would like it to change?

Thank you for your response.

"vrdaveb" wrote:
You mean OVRPlayerController? Sounds like dead zone is too tight for your controller. In a future release, we're planning to increase it a little to prevent this. In the meantime, can you change the 0.15f dead zone in OVRInput.cs to 0.2f?

I don't think that the dead zone is the problem. I don't have a control for vertical movement with the controller. The strange thing is, that your gaze pointer (UI project) has an offset (when the shifting is happening), too. It detects the colliders with an offset of where they are in the world.

"vrdaveb" wrote:
It sounds like you're using the sample VR UI project from our blog (https://developer.oculus.com/blog/unity ... tem-in-vr/). That isn't part of the Utilities, it's a drop-in replacement for the usual mouse-driven input modules in UGUI. It implements Unity's GraphicRaycaster interface, which returns all hits in sorted order. This is more flexible than Physics.Raycast and Unity probably needs it for a number of corner cases in their UI logic.

Yes, that seems to be the reason for my problems. I thought that is the sample scene, how to use the OVR Utils.

Maybe the RaycastAll more flexible and is needed for some UI effects, but has some nasty side effects, like detecting the gazeable objects through walls and through "non gazeable objects". And RacastAll with sorting seems unnessesary slow. From user point of view, I can't imagine a situation where I would need this.
In all my tests a simple Ray with a check if the collider is "gazeable" is much faster and gives the result I would expect from a gaze pointer.

"vrdaveb" wrote:
OVRInput is designed to be similar to UnityEngine.Input, which drives the undocumented CrossPlatformInput class's StandaloneInput back-end. Unity prefers not to include any Oculus-specific code in their Standard Assets, but we are still working with them to expose this in a cross-platform way.

Maybe I don't get this. How can I change the controlls? Not with the Unity input settings, right? The only way I found was to modify the OVRInput.cs. And as an example there the button method.

"vrdaveb" wrote:
Which logic is that?

The logic with the Spherecast. Or is the Spherecast not for the mouse?
Maybe it will be different in the future (comment from code: "// In future versions of Uinty RaycastResult will contain screenPosition so this will not be necessary")

"vrdaveb" wrote:
I'm unable to reproduce this. What Unity version and Utilities version are you using? What is the warning? Is it in OVRInput.cs or OVRInputModule.cs?

Unity Verion 5.3.2p2 on Win7 64
Oculus 0.8
And the UI-Demo from your link.

Ok, my problem seems than, that I'm mixing the OVR Utils and the VR UI project here. The UI-project is your official demo scene, how to implement the controller and a gaze pointer. It shouldn't throw warnings. Please update the demo scene to your own API and current unity version.

Messages I get with your scene:
"OVRGamepadController has been deprecated and will be removed in a future release. Please migrate to OVRInput. Refer to the documentation here for more information: https://developer.oculus.com/documentat ... -ovrinput/"

"Assets/Scripts/ParticleGazeCursor.cs(88,20): warning CS0618: `UnityEngine.ParticleSystem.emissionRate' is obsolete: `emissionRate property is deprecated. Use emission.rate instead.'
"

"Assets/Scripts/OVRInputModule.cs(97,14): warning CS0114: `UnityEngine.EventSystems.OVRInputModule.Reset()' hides inherited member `UnityEngine.EventSystems.UIBehaviour.Reset()'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword"

"vrdaveb" wrote:
Sorry, but I need more detail to understand what is wrong here. Can you describe what part of the workflow is too complicated and how you would like it to change?

Not wrong, over complicated.
- Your input logic without using the input settings.
- The RaycastAll with the cloning of the PointerEventData

Please make it "KISS" as possible. I'm only a scripter, not a programmer. Maybe I have a problem to understand all your reasons to build the API and the Demo scene the way you do.
After some days trying to implement your example UI demo logic in my project I have dropped it and build my own character controller and GazePointer.