Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Babylon virtual joystick improvements #7398

Closed
thomlucc opened this issue Jan 7, 2020 · 14 comments
Closed

Babylon virtual joystick improvements #7398

thomlucc opened this issue Jan 7, 2020 · 14 comments
Milestone

Comments

@thomlucc
Copy link
Member

thomlucc commented Jan 7, 2020

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

@thomlucc thomlucc added this to the Future milestone Jan 7, 2020
@jalmasi
Copy link

jalmasi commented Jan 18, 2020

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

@Rockwell15
Copy link
Contributor

@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
Copy link
Contributor

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

@Rockwell15
Copy link
Contributor

@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
Copy link
Member Author

thomlucc commented Jun 2, 2020

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

@deltakosh
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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

@Rockwell15
Copy link
Contributor

@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
Copy link
Contributor

deltakosh commented Jun 8, 2020

Ideally 1 commit if you can squash them

@deltakosh
Copy link
Contributor

Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants