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.
Forum Discussion
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)
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
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.
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.
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)
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.
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
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).
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....
field, but just be aware not everything is integrating well....