handle update on rayOrigin from mouse -> entity

[kylebakerio]

fixes issue #4759

Description:

Changes proposed:

[dmarcos]

I usually recommend adding one cursor on <a-scene cursor="cursor="rayOrigin: mouse"> and then additional cursors in relevant entities. Would that be useful in your scenario?

[kylebakerio]

That's an interesting thought. Is there documentation that describes that idea? Do you just set multiple cursors, and then disable/enable whichever ones you want active accordingly? I imagine I could do it that way, but I wouldn't be sure what entities to put the cursor on (shouldn't the cursor generally be a child of the active camera? Would the only result be the origin of the raycaster being defined from whatever element you make the child a cursor of? Do you just set 'multiple' to allow multiple cursor components on the active camera entity? Is this going to play nicely with aframe-extras/movement-controls?). If I had multiple cursors enabled at the same time, I assume that would cause multiple click events to be fired, right?

It seems like a strange model to me to create multiple cursors and keep track of their state separately than to just update the one cursor component, if only one is ever active at a time. Not sure. Maybe if the cursor component is a bit messy and prefers to just be set once and left alone, though, that might be a cleaner option that attempting to update it for the time being?

[dmarcos]

I don't know much about your use case. Usually one wants to have a cursor for mouse / touch and one for VR.

When in VR the mouse / touch cursor won't produce events because mouse / touch are not active.
The same for the cursor(s) associated to the tracked controls in VR. In 2D mode they won't produce events.

No need to enable / disable cursors manually depending on the mode.

See the model viewer example as en example of interaction model that works across desktop / mobile / VR. One mouse cursor on <a-scene> and one cursor per tracked controller via laser controls.

Improvements ideas. On laser-controls we could enable / disable the raycaster on controllerconnected / controllerdisconnected to save on the raycaster tock calculations. The same for cursor="rayOrigin: mouse": we could enable / disable the raycaster on exit-vr / enter-vr events.

[kylebakerio]

Based on your suggestion before, I recently refactored to be using many cursor objects for various control schemes. I disable the raycaster for the mouse within cardboard and quest, for example, disable the fuse/gamepad view-based cursor when using desktop mouse mode, and always leave a third one running to check if the other player (for example) is blocking the player's view of the game board. I then of course add 4th and 5th raycasters through the HMD controllers when appropriate. This is a better solution.

Also, digging further, I found that '0 0 0' is treated as an implicit flag in that code block, meaning my origin seemed to be at world origin 0 0 0, which caused it to start working in some cases for me, but not all. I since have started setting x to 0.001, and finally it is working as desired everywhere, instead of in the range of the raycaster from world origin 0 0 0... but I find that code block slightly confusing and so haven't decided what the best way to do this is.

Either way, though, it doesn't seem that the cursor responds well to updates in its current form. Perhaps this should be somehow documented at least, if not updated.

As for disabling, I was referring tot he raycaster children of the cursors, which I don't want doing update checks on an interval if not active.

Improvements ideas. On laser-controls we could enable / disable the raycaster on controllerconnected / controllerdisconnected to save on the raycaster tock calculations. The same for cursor="rayOrigin: mouse": we could enable / disable the raycaster on exit-vr / enter-vr events.

I am essentially doing this in my code now, I have a function for detecting the various viewport/input combinations my app runs with and setting them that I run on various events like enter-vr/exit-vr, and am designing an in-game init gui sequence to select it explicitly.

[dmarcos]

A bit conflicted with this. For mouse cursor we recommend adding to the scene so no change to dynamic change to entity should be necessary. In any case the contract of a component is that it can change dynamically so this is technically a bug.

We should also probably considering adding a message to the component that for a mouse type of cursor it's recommended be added to the scene.

[dmarcos]

Thanks!