Forum Discussion
Oculus Go - Default controller ray and reticle
Is there a prefab for that?
I want to replicate the fading of the controller, fading of the ray, the auto-resizing reticle in my app.
I want to replicate the fading of the controller, fading of the ray, the auto-resizing reticle in my app.
4 Replies
Replies have been turned off for this discussion
- Thank you, I have already implemented the ray and the reticle with some help from those examples.
The original Oculus implementation though, has such tiny details that it would be nice to have them as prefabs. Like:- The reticle scales up / down a little, due to the proximity to a target.
- The controller model fades out when you move it up above.
- @imperativity
Are there any guides that are valid for current version of Oculus Utilities for Unity? Tried following https://developer.oculus.com/blog/adding-gear-vr-controller-support-to-unitys-ui/, but some assets mentioned there aren't a part of that package anymore. I've mostly figured things but, but I am completely lost how to implement a reticle that will be visible only on canvas - You should really consider adding these to your Oculus Utilities if you care about the consistent user experience across applications!
- Test Developing with Rift CV1, I have downloaded and tested some sample
scenes in the latest Oculus Integration Utilities v1.31 for Unity - most
scenes have something useful to use, even if not everything works, or
is incompatible as-is with Unity 2018 (requires some code tweaking for
deprecated methods)- something of note is the
Oculus/Avatar/Samples/SocialStarter/Assets/MainScene, which does the
loading of a custom avatar, complete with autofading linerender rays
& pointer spheres which match those in the default Oculus Home user
interface, however the code which creates those rays and pointers is not
externally exposed to developers- it appears to be an internal
function of the Oculus.Avatar.CAPI class, of which we only can see
headers, because it is an API inside the OVRPlugin.Unfortunately that does not help developers who need lightweight high
performance/low overhead code for mobile platforms, like Gear VR which I
am attempting.
Importing ONLY the VR subtree hierarchy from this unitypackage works for
SOME scenes which have no platform or avatar code dependencies, but if
you start using certain prefabs or scripts, a web of cross-dependencies
on the AudioManager,Avatar,LipSync,Platform,Spatializer,VoiceMod
subtrees will soon emerge, necessitating a monolithic import of bloat,
even if you remove the various 'Sample' subtrees.As official companion unity packages to the Oculus
Integration/Utilities, I have tested the line render technique shown in
the Oculus Sample OVR Updated Controller Interaction (separate
unitypackage) and certain locomotion scenes in Oculus Sample Framework
(separate unitypackage)- both also designed for earlier versions of
Unity, in order to test locomotion/teleport/rotation as well as UI
interaction, but that brought additional complexity because of differing
versions of OVR scripts in the sample scene prefabs which are
incompatible with the same named scripts in the separate
Oculus/VR/Scripts hierarchy.Additionally, the Oculus Unity UI interaction for Touch/GearVR/Go/Malibu
controllers seems broken when dealing with anything more complex than a
toggle, button, input field, or slider bar.
(i.e. Things like a Unity UI.DropDown result in reverting to selection
via a non-visible Gaze Cursor.)
There is a user-submitted hack for this here: https://forums.oculusvr.com/developer/discussion/39327/gaze-pointers-drop-down-boxes(thx @jhocking !)It also bears repeating to say Unity UI Navigation must be disabled on
all in-scene UI components to avoid the 'stuck focus' bug, (selects the
previous UI element on click rather than the UI element currently being
pointed to).I will try the hack, and try to use something other than a dropdown or scroll
field, but just be aware not everything is integrating well....
