Closed Zod- closed 7 years ago
Which line did you place the debug for the HitObject
?
if (previousFocusObject != HitObject && FocusedObjectChanged != null)
{
var msg = HitObject != null ? HitObject.name : "";
Debug.Log("HitObject: "+ msg);
FocusedObjectChanged(previousFocusObject, HitObject);
}
@kmikkel Regression from https://github.com/Microsoft/HoloToolkit-Unity/pull/606
Hi, yes I have managed to reproduce this issue. There are a few potential problems:
I have tried to order on both distance and depth. But it seems like the RaycastAll is inconsequent in what it returns. So the result is that it randomly after ordering hits by distance and depth are that the UI button seems to flicker. I suspect this may be a issue/bug in Unity.
@kmikkel Are you comparing the depth of elements from different canvases? Comparing the distance between 2 canvases and the depth for elements within a single canvas is fine. However the depth between 2 canvases shouldn't make sense. So you would have to determine first which canvas the elements belong to before you can compare distance and/or depth.
Thanks for the feedback. Good point. I only have one canvas in my test scene. But it still behaves strange. I am using Unity 5.5.0p1 in my test. I am sorry, but I don't have time to look more into this anymore at the moment.
I did some more testing and found more issues. It's not just the regression that causes the focus change firing, it only makes it slightly worse. Here doing the same reproduction steps with a commit just before the merge:
The issue is that with this UI setup, raycasts simply don't work. I think the general idea behind the current design is wrong or has to be used differently. The main issue is that the UI all exists in the same plane. The canvas and all it's child ui elements have the same z-coordinate so they all have the same distance to the camera. However because of floating point variations in the raycast calculations it will alwas choose a random one that is the "clostest".
The 3D raycast will choose a random ui-element of the canvas layer which will then be compared to a different random ui-element from the ui raycast. The regression only adds a few more randomly selected ui-elements for the second one which makes it worse.
A solution would be to add a small z-position to every single ui element so that the raycasts can actually detect the depth that they have. Like this the current system could be kept but every ui would have to be set up like this.
My second idea would be to have different layers for the canvas and its ui-elements. Only the canvas itself would be hit by the 3D raycast but not any of the ui-elements. After detecting a canvas got hit we then can do a ui raycast for the other layer where we determine which is the top element by their depth in the canvas.
Has this been addressed?
@bencinStudios I have a working version over at https://github.com/Zod-/HoloToolkit-Unity/tree/feature/ui_raycasts, but it requires a very specific setup.
RaycastUILayerMask
. RaycastLayerMask
. So the default layermask would be for example Default, TransparentFX and Water. The other layermask would be just UI.RaycastLayerMask
but not in RaycastUILayerMask
. e.g. Default.RaycastUILayerMask
.You can look at the SpatialUnderstandingExample or InputManagerTest to see an example
@bencinStudios I have solved the problem with changing focus on UI elements by adding a small z-value offset for the elements. So that the no element have the same z value as its parent. Doing this will stop the focus to switch.
Thanks @Zod- , and thanks @kmikkel ... going with ease on this one, the z-value offset seems to have worked for the most part, still very subtle flicker when button or input field is gazed at, but notably better both visually and functionally. Was the quick hack I needed to meet the deadline, thanks all!
The issue is two fold:
Once these two issues are addressed in the scene, it should work fine. There's no bug in the GazeManager
.
Trying out the SpatialUnderstandingExample I noticed that the buttons kept flickering when you keep your cursor on them. Turns out the GazeManager keeps cycling through the different layers of the UI elements and fires
GazeManager_FocusedChanged
of the InputManager constantly.How to reproduce:
For exampling just printing the name of the
HitObject
element when placing the cursor on one of the buttons and leaving it there for a few seconds: