Hover UI Kit Release: v2.0.0B (beta)

[zachkinstner]

Please see the v2.0.0B (beta) release page. This ticket is for discussion about the latest changes, including any bugs, issues, and questions that might come up.

The project wiki provides an overview of the project, instructions for getting started, and details about project features.

This is a "beta" release, and includes several improvements and fixes since the "alpha" release. There may be breaking changes prior to the official v2.0 release. This version has been used and tested in some demo projects, which will be posted below.

[zachkinstner]

A huge part of my testing process for this beta release was building a "force-directed graph" demo, which uses Hover UI for its menu interfaces, and includes some interesting data-viz concepts. Working on this demo uncovered several bugs and other issues, which are now resolved in this release.

I wrote two articles at Medium (so far) that go into depth about the UX thinking, interface design, and other challenges involved with this demo project. The article also has links to the associated "DevUp" videos, and a downloadable demo (for Vive and Oclulus).

[zachkinstner]

While it's a little less exciting, you can also download a Hovercast demo. This demo uses the latest version of Hover UI, and is built from the "CastCubes" demo/scene that is provided (among others) in the "HoverDemos" folder.

This Hovercast demo works for Vive and Oculus, but requires Leap Motion input. The force-directed graph demo (above) automatically switches to Vive controller or Oculus Touch input if no Leap Motion input is detected.

[zachkinstner]

As part of Hover UI's beta release, I wrote about my experience building demos with it, and the value of focusing on the "developer UX": https://medium.com/@zachkinstner/a-dog-food-approach-to-developer-ux-f7e8cb44cd0c

The "developer UX" involves the documentation, tutorials, and examples, but it's also about the feel and flow of actually working with the tool. Using my own "dog-fooding" experience, and by taking feedback from developers, I'm striving to make Hover UI into a tool that is powerful, flexible, and pleasant to use.

[zachkinstner]

Here's the tweet+animation for Hover UI Kit's new release, please retweet or share!
https://twitter.com/zachkinstner/status/811987872970579970

[AntoineLasnier]

Hi Zach,
Amazing work!, Very promising.
I was wondering if there is a way to use both Vive and LeapMotion input modules in the same scene?
Thank you,

[zachkinstner]

@AntoineLasnier: By convention, each input module affects all the cursors. Each frame, an input module resets all the cursors, then updates some/all of them with new info (position, rotation, etc.). This prevents two input modules from working together simultaneously, since the second input module's updates would overwrite the first.

I'm not sure what scenario you plan to mix Vive and Leap Motion. One hand free and one hand holding the controller?

To make this work, I think you'll need to write your own input module. It would be based on the HoverInputVive and HoverInputLeapMotion scripts. You could possibly make all the private methods public in those scripts, which would allow you to re-use (instead of copy) that code in your new module.

Your module would need to decide how to divide up the cursors. For example, maybe all left-side cursors belong to Vive, while the right belongs to Leap Motion. Or, maybe "Index" and "Palm" belong to Leap Motion on both sides, while "Thumb" and "Middle" are for Vive.

[AntoineLasnier]

@zachkinstner Thank you for your answer. In my scenario, the user would use either both Vive controllers or both hands free. I just need a way to switch quickly between the 2 modes in runtime (e.g. if Vive controller are not visible, use Leap input module and vice versa). From what I know of your work, there should only be one input module used in a given scene and switching to another one cannot be made without stopping the execution. Is that correct?

[zachkinstner]

@AntoineLasnier, it will take some custom code/setup on your side, but yes: it is possible to switch between "Leap Motion" and "Vive" input modules at runtime. My force-directed graph demo currently does this -- you can start the app (using Oculus/Vive) with Leap Motion unplugged to use the Oculus/Vive controllers, then plug in the Leap Motion to use hands, then unplug Leap Motion again.

I'm not sure yet if I will try to generalize the demo's code that handles this, but it may eventually become a utility within Hover UI Kit. The idea is:

1. Have a "hardware detector" that checks the active headset and/or device. For example:

Headset = (VRSettings.loadedDeviceName == "OpenVR" ? HeadsetType.Vive : HeadsetType.Oculus);
IsLeapMotionConnected = (MyLeapController.IsServiceConnected && MyLeapController.IsConnected)

2. Based on the active devices, switch between input modules. I found that using a simple GameObject activate/deactivate approach worked for the Vive prefab, but not for the Oculus prefab. So for the demo, I ended up using the "multi-scene" approach, where the demo additively loads the desired "input module" scene (and unloads the previous one).

3. Ensure that all the "Scripting Define Symbols" are included (one for each input module you want to use). In Unity's Player menu, these are separated by ;, in any order you want, like this:

HOVER_INPUT_LEAPMOTION;HOVER_INPUT_VIVE;HOVER_INPUT_OCULUSTOUCH

The complexity here is primarily related to the Leap Motion, Oculus, and Vive prefabs, and switching between them at runtime. For Hover UI Kit, specifically, you just need to ensure that only one "input module" component (like HoverInputVive or HoverInputLeapMotion) is active at the same time. If more than one is active, whichever one executes last (per frame) will be the one that controls the cursors.

[AntoineLasnier]

@zachkinstner Thank you for your help. I will try that as soon as I get back to work and let you know.

[sanky369]

Is Hover UI kit applicable for Google Cardboard?

[zachkinstner]

@sanky369, I have not personally tried Hover UI Kit with Google Cardboard, but I think the two should work just fine together. Assuming you have no 3D input device, only the "look at" selection approach would be applicable (center your gaze on an item, holding it there until the selection is complete).

The "Follow" input module is built specifically for this scenario. For mobile VR, you would simply set the "Look" cursor (which has "raycast" mode enabled) to follow the VR headset's Transform.

[zachkinstner]

The Hover UI Kit v2.0.1B release includes various fixes. See the release page for full details.