6dof input model proposal


(Gfodor) #1

This is a proposal for a unified input scheme across all 6dof controllers. It needs to take into account object manipulation, pen/camera, and locomotion. The main design decision in this proposal that is likely to be the most controversial is the reliance upon the grip buttons on the vive controller, which are a bit cumbersome to use. However beyond this I think this proposal is worth wiring up to test.

Proposals:

The cursor “pull” min distance is increased to the point where pulling an object towards your hand will stop out ahead of your hand, so there is no confusion if you are holding the object in your hand or on the cursor.

Grip is always used to pick up objects, regardless of if you are grabbing them on the cursor or in your hand. On Touch, hold grip to grab an object and let go of grip to let go. On Vive, click grip to lock grab an object (and click grip again to let go) or hold grip to grab an object and let go of grip to let go. The ability to grab lock via clicking the grip should help mitigate comfort concerns with vive, but click-to-grip-lock is probably unnecessary on other platforms.

Letting go of grip when throwing an object will put it in dynamic body mode, letting go while steady handed will keep it static (as is now.) However, depressing the trigger and then letting go of both buttons will force it to be static.

Pointing at a model, image, or video (or the camera) with the cursor and clicking and holding the trigger will rotate the object based upon the controller orientation deltas while the trigger is held.

While gripping the pen (in hand or on-cursor) the trigger draws.

When the cursor is not over any element, pulling the trigger activates teleporter.

When the cursor is over UI, pulling the trigger clicks the UI.

There is no more automatic grab lock on pen and camera – on vive, you can grab lock any object by grip-clicking. This automatic locking is confusing for a variety of reasons, since it makes those objects “special” and also the grip button needs to be intuited to “drop” the object (which is probably the inverse of what a user expects, since its a grip button after all.)

Clicking on a video with the trigger pause/resumes the video. Clicking on the camera with the trigger takes a picture. Clicking on a PDF advances the page.

The pen and camera never can become dynamic bodies.

Holding grip + trigger when cursor would normally teleport should just articulate avatar hands into “thumbs up”.


(Jconrad) #2

This makes sense to me. Hopefully, when the Knuckles controller slowly replaces existing Vive controllers, the lock grip won’t be necessary. It does, however, feel like a great candidate for a ‘settings’ menu, particularly as an accessibility feature for those with limited dexterity or grip stamina.

Regarding the ‘trigger to rotate objects’, I’m imagining it may be tricky to differentiate between ‘I want to rotate this video’ versus ‘I meant to hit Play on this video’. One thing to consider is taking advantage of Brian’s latest addition of visual effects as a way to give feedback to users. So, for example, maybe you have to hold down the trigger for x amount of time and while doing so, we do some kind of overlay effect that builds to signify you are switching into ‘rotate’ mode. This, plus haptic feedback could make it more obvious.


(Jconrad) #3

Also, while rotating an element, consider having a modifier that allows snap rotating (
Maybe 45-degree increments) or ‘resetting’ to a default orientation relative to the user and/or world space.