Babylon virtual joystick improvements

[thomlucc]

Improve Virtual Joystick. Initial feedback:
1 - It can not be made sticky.
2 - It can not be made always visible
3 - It can not be modified ( size, color, etc )

Additional feedback to come in forum thread: https://forum.babylonjs.com/t/navigation-gui-for-tablets-mobiles/7771

[jalmasi]

Hi,
just found another issue - it makes 'enter VR' button of VR Helper unavailable.

[Rockwell15]

@thomlucc

Hi! I'm hoping to take the lead on developing these improvements, may I?

I see that the linked forum thread has been inactive since January so I assume the improvements mentioned here will be good for now?

To reiterate, all that needs to be covered is:

1. Allow specification of joystick position
2. Allow joystick to be always visible
3. Allow graphical customizations
4. Limit the joystick's inner puck movement. The current VirtualJoystick's inner puck moves to wherever your mouse is, but Nipple.JS's implementation (which was mentioned a couple times in that thread) limits it into the container's bounds.
5. Update docs especially since I did see that you can already change the color

[deltakosh]

Fantastic! I was thinking that we could use GUI for that. Thoughts?

[Rockwell15]

@deltakosh

My thoughts exactly! I'm thinking we can take additional arguments in the VirtualJoystick constructor to allow people to easily change the basic style. Then we can expose the GUI element too so people can make further customization if they so choose.

Extra parameters:

• color
• size
• position (will automatically be "sticky" if this is supplied)
• alwaysVisible
• container image
• puck image ( so you could achieve the behavior asked for in the OP of that thread )

What do you think?

[thomlucc]

@Rockwell15, I'll let @deltakosh answer you, but wanted to thank you for taking the lead on this issue!

[deltakosh]

@deltakosh

My thoughts exactly! I'm thinking we can take additional arguments in the VirtualJoystick constructor to allow people to easily change the basic style. Then we can expose the GUI element too so people can make further customization if they so choose.

Extra parameters:

• color
• size
• position (will automatically be "sticky" if this is supplied)
• alwaysVisible
• container image
• puck image ( so you could achieve the behavior asked for in the OP of that thread )

What do you think?

Love it!!!

[Rockwell15]

@deltakosh

I see that people currently have the option to set a premade canvas on the VirtualJoystick class. Do you see any scenario where simply ignoring that property would create issues for backward compatibility? (Since we'd be using the GUI controls for pointer events instead)

[Rockwell15]

@thomlucc
@deltakosh

I've made an implementation just using GUI inside of the current "virtualJoystick.js" file. However, I just realized when I went to change to a module import (instead of using the global BABYLON.GUI), that the "gui" module is not in "src", and no other files in "src" use the GUI.

Am I taking the wrong approach directly using GUI in "virtualJoystick.js"?

[deltakosh]

Rats! you are right! we cannot use GUI as it will create a loop between both and bjs must have no dependency

We need to create an external module for that:(
a module that will reference both bjs and GUI (like the inspector for instance)

Pinging @sebavan to see if he has a better idea to use GUI from bjs code

[Rockwell15]

@deltakosh

I can still accomplish everything by drawing on canvas, no problem. Or maybe do you think it would be better to have users who want customizations to pass the GUI reference with the customization options?

[deltakosh]

I think it is ok to draw on the canvas (I wanted to avoid duplication of code mostly)

[Rockwell15]

@deltakosh

I have a branch ready to make a pull request, but it has multiple commits. This is my first github contribution so I'm not sure of the etiquette and didn't read anything that addresses this question. Should I make this just 1 commit? Or is multiple commits for a single issue common?

[deltakosh]

Ideally 1 commit if you can squash them

[deltakosh]

Done