for customization of on screen dom button

[vikk]

sir i create a simple e- shop in 3d ans technology used in babylon js but i want  to customize on screen key . when i click up arrow its goes to up and when click down its goes to back . and left arrow on click or press its goes to left and same as right . and when drag yellow circle its also goes that direction my camera. and my project link is..http://34.251.77.144/vikash/index.html pls give me solution due to my on screen key navigate smoothly. 

[Wingnut]

Hello Vikk.  Pretty scene! 

Look at this playground demo:

https://www.babylonjs-playground.com/#2JXSKY#47

Perhaps helpful.  This is red-bat joystick... moving green "submarine".  Drag on joystick... see green submarine move.

Maybe you can change submarine to be camera, and change joystick to be yellow circle?  (in your on-screen keyboard - lower right)

'backingPanel' mesh is VERY important for "dragging".  Lines 52-59 getBackingPanelPosition() also very important (to determine AMOUNT of dragging).

Backing panel must ALWAYS be "behind" red joystick handle, or joystick dragging will fail.  Same with your yellow circle.  There must be a backingPanel for drag system to use.

Study carefully.  Notice... pull/push joystick a LITTLE = little movement.  Pull/push LOTS == big movement.  Also notice "ramp-down" easing.

Perhaps there are better ways, but this is ONE way to do the yellow circle dragging. 

This will also work for arrow clicks... just "force" left joystick drag condition, if left arrow pressed/held.  (fake/pretend your yellow circle is dragged full leftward)

Your main project is difficult to work-on for us helpers.  Too big. 

I hope this playground demo helps.  Maybe you can make edits and more saves in that playground. Paste new URL's here, if wanted, and show us more details about your wishes

The above playground is VERY similar to our playground drag-and-drop demo... http://playground.babylonjs.com/?18

[vikk]

thank you for reply #Wingnut

i show this playground previously but my problem is ,i made on screen key and draggable key like joystick in 2d  and i want to it run smoothly , here i play with camera pls help me

[Wingnut]

My pleasure.

What you ask... is very difficult for me.  Still, I try.

First, we must verify.  Is your camera keyboard (4 arrows and yellow circle) made from HTML?

https://www.babylonjs-playground.com/#10P0IP#2

I have made one in HTML, too.  Absolute positioning.  Much work to do yet.

I have never done HTML dragging, so, I need to read about dragging yellow HTML node (called but3span).

I need to make yellow square... output drag-values same as red joystick did. 

I am slow.  Be patient with me, and I will do my best... soon. 

[vikk]

ya sure 

and you made same pg as i want . but in this pg i want when click forward button my camera goes forward and when click reverse button its goes reverse and same as left and right button and i also want when i dragg yellow sqare up our camera goes forward and dragg down our camera goes reverse and same as when dragg left its goes left as well right . and after relese yellow square goes at center

http://onecode.co.il/demos/sh3d-qdror23/shop.html?store=shoes&len=he like this website

[Wingnut]

I am having problems programming yellow drag square, though.  I dunno how to do drag on that.  Can you help?  Others?

I cannot find way to drag-move yellow square... and get values of drag amounts and directions.

Right now I am stuck.

[Wingnut]

https://code.jquery.com/ui/1.12.1/jquery-ui.js

I think that's where that draggable yellow circle is done.

I don't foresee me being able to reproduce that in the playground.

Sorry.  It would take me forever to learn jquery-ui.  Perhaps there are others in the forum that have experience with jQuery UI that can help.

[Topper]

Don't use it. Cost me days of pain.

[Wingnut]

Oh is that right?  Sorry.  Well, I can't seem to determine HOW the yellow circle gets its position dragged-around, speak nothing of trying to get it active in the playground.

(I'm not the smartest guy in the world, though... sorry).

Can you help me with the yellow circle/square in the middle?  Can you show me how to make it drag-move and produce values based-upon its position?

Maybe others have ideas.  I need that dragging to produce values, just like my non-DOM red joystick does.

After I get the yellow circle (yellow square in my PG demo) to drag-position and return usable values to me, THEN I can try to use those values to move a camera.

 

What I would do if I were you is... use BabylonJS GUI system... to create the keypad.  Even then, I'm not sure that I can drag-around the yellow circle... unless we make it be a sprite.

But... there IS paddingLeft and paddingTop on BabylonJS GUI controls, and a markAsDirty() which has been seen doing live-updating of AdvancedDynamicTextures (the basis of BabylonJS GUI).

Would you entertain the idea of switching to non-DOM buttons on the keypad?  If we do this, the GUI becomes usable for VR headgear, too. 

Conversely, if you use a DOM version of the keypad, VR headgear folk won't be able to see/use it.

Thoughts?  (from anyone/everyone, please)

[vikk]

in  my project http://34.251.77.144/vikash/index.html   i write these code for circle and arrow ...in index.html 

<div class="circel">
 <div class="outer">
    <p><i class="up" id = "up"  onmousedown="moveup()" ontouchstart="moveup()"></i></p>
    <div class="inner" id = "inner"></div>
    <p><i class="right" id = "right" onmousedown="moveright()"  ontouchstart="moveright()"></i></p>
    <p><i class="left" id = "left"  onmousedown="moveleft()" ontouchstart="moveleft()"></i></p>
    <p><i class="down" id = "down" onmousedown="movedown()" ontouchstart="movedown()"></i></p>
</div>
</div>

and  for dragging i write these code in code2.js

    function moveup() {
            //camera.fov -=0.03;
            camera.position.x -=3;
}

function movedown() {
             camera.position.x +=3;
}

function moveleft() {
             camera.rotation.y -=0.03;
}

function moveright() {
            camera.rotation.y +=0.03;
}
   var xpos; var ypos;

$(document).ready(function() {
    $( "#inner" ).draggable({ cursor: 'move',
    containment: 'parent', revert: true  });
  // sets draggable the element with id="dg"
  $('#inner').draggable({
    // get the initial X and Y position when dragging starts
    start: function(event, ui) {
      xpos = ui.position.left;
      ypos = ui.position.top;
    },
    // when dragging stops
    stop: function(event, ui) {
      // calculate the dragged distance, with the current X and Y position and the "xpos" and "ypos"
      var xmove = ui.position.left - xpos;
      var ymove = ui.position.top - ypos;

      // define the moved direction: right, bottom (when positive), left, up (when negative)
      //var xd = xmove >= 0 ? ' To right: ' : ' To left: ';
      //var yd = ymove >= 0 ? ' Bottom: ' : ' Up: ';
       if(xmove >= 0 )
        {
         camera.rotation.y -=0.03;
        }else{
        camera.rotation.y +=0.03;
        }
         if( ymove >= 0 )
        {
         camera.position.z -=3;
        }else{
        camera.position.z +=3;
        }
    }
  });
});

[Wingnut]

https://www.babylonjs-playground.com/#10P0IP#6

Wingnut having troubles with .draggable.  I'm not very good at jQuery.

In your code, you are using a variable called 'ui'.  I don't think I have that available in playground, so I just set it empty in line 162.

Also, I changed #inner to #innerpad  ... no big deal.

Also, changed the document/scene isReady method... WAS line 165, now line 166.  No biggie.

Watch JS console.  Line 167 working fine, line 169 working fine, but line 179 is dead.  (see error dump in console).  .draggable is not  function.

I'm not sure why it is broken, but I will keep working.  Help from anyone... highly welcomed. 

[Wingnut]

MEANTIME...  for fun... let's look at my renderLoop at line 127 of the red joystick demo: 

scene.beforeRender = function() {

        animationRatio = scene.getAnimationRatio(); // the same speed all devices

        subRight = sub.getDirection(BABYLON.Vector3.Right());

        subForward = sub.getDirection(BABYLON.Vector3.Forward());

        sub.position.addInPlace(subRight.scaleInPlace(-xspeed * animationRatio));

        sub.position.addInPlace(subForward.scaleInPlace(zspeed * animationRatio));

        if (!stickInUse) {

            if (xspeed > 0) xspeed -= rampdown;

            if (xspeed < 0) xspeed += rampdown;

            if (zspeed > 0) zspeed -= rampdown;

            if (zspeed < 0) zspeed += rampdown;

        }       

    }

This is similar to the renderLoop YOU will use for your camera mover.  See the green lines?  Pretend you have changed each 'sub' to 'camera'.

        camera.position.addInPlace(cameraRight.scaleInPlace(-xspeed * animationRatio));
        camera.position.addInPlace(cameraForward.scaleInPlace(zspeed * animationRatio));

renderLoops run continuously.  The green lines run CONSTANTLY.  When joystick is centered/unused, xspeed and zspeed == 0.  SO, there is no camera movement, even though these two positioning lines are always running.  Perhaps you can fix your issue more quickly than my slow work.  xspeed would be the amount of left/right movement of inner circle.  zspeed would be amount of forward/backward movement of inner circle.

Right now, the submarine only goes worldspace forward/backward/left/right.  It doesn't allow turning/rotation.

But take a quick look at THIS PG that satGuru helped me with:  http://playground.babylonjs.com/#6FHKHC#9

First, let's see what the 'wingnut crap' does.  You can turn this free camera in ANY direction, and then use mousewheel to go forward/backward along the z-axis.  Line 31 is the code that gets the current camera Z-direction.  Mousewheel moves camera in camera's Z direction (in camera space, not world space), no matter which direction camera is aimed.  Good, right?  You want your yellow circle to do the same, right?  Go forward/backward along camera aiming direction, yes?

Let's make some changes... try to find camera X direction for left/right moving.  http://playground.babylonjs.com/#6FHKHC#10

In lines 31/32, I have made BOTH camera directions... Z and X.  In lines 35 and 37, I am using dirX instead-of dirZ.  Try the mousewheel.

Again, no matter which direction the camera is aimed... camera still moves perfectly left/right (in camera space, not world space).  This is what you want your yellow circle to do... when dragged left/right, too, right?  @satguru's lines 35 and 37 uses the very same .addInPlace as our two green lines above, eh?

So... your renderLoop for your camera mover... will likely also contain two lines like 31 and 32... which are camera directionX and directionZ getters.  This is so we can move your camera along camera-space X and camera-space Z, instead of worldspace x and worldspace z.

Anyway, I thought I would show you these things, and perhaps... you would have enough "stuff" to fix your issue yourself... without waiting for my slow testings and jQuery problems.  xspeed and zspeed can be positive or negative... no problems.  Your yellow circular touchpad values can do the same.  When dragged down, it can produce negative z values.  When dragged up... positive z values.  When dragged left... negative x values.  When dragged right... positive x values.

The secret is... constantly TRYING to move the camera... in the renderLoop (whenever an Xvalue or Zvalue is produced by the yellow circle drag).  I will keep working on the playground version... hopefully with help from jQuery pros.  You, my friend, now have everything you need to fix your own issue... if you wish.  You might be able to do it faster than I.    Good luck, if you try it.  Sorry for long post.

Update:  Just for MORE fun, let's try a camera-mover renderLoop (lines 118-139) on our red joystick.  https://www.babylonjs-playground.com/#2JXSKY#49

Works ok, eh?  We simply "feed" the beforeRender func... a positive or negative xspeed, and a positive or negative zspeed.  My "rampdown system" isn't working perfectly, so you might see a little camera "drift" after joystick is released.  But... this beforeRender function is essentially the same one you will use.  It is constantly watching-for changing xspeed and zspeed values, and adding them to the camera position.

If you can make your yellow circle... produce some xspeed and zspeed values, you are ALMOST done/fixed, yes?  Good luck.  May your horse be with you. 

[Wingnut]

https://www.babylonjs-playground.com/#91I2RE#4

Wow, look how similar a Babylon GUI Colorpicker is... to being your wanted ipod circle.

ALL of it... is similar to a thing called a virtualJoystick.  It is/was a drag-able touchscreen controller... graphical rings on the screen... drag them with your thumbs on a portable device.

I wonder... if we bought @Deltakosh a new speedboat or something... maybe he would down-"hack" his colorpicker... into being an ipod circular center-draggable "thing".

He's a great coder and darned nice guy, but this is a rather large request.

4 compass-point buttons around a drag-able center dot.  Optional 4 more buttons (northwest, northeast, southwest, southeast).  Back-lit, for easy nighttime usage. 

Wha-da-ya-say, Delta?  (or any other coding madman)  Have you the time/energy to make a GUI ipod 'thing'? 

Custom GUI controls.  sigh.  Look at those cool circles in that colorpicker.  I put the colorpicker code... into the PG (remmed-out cuz I couldn't get it to activate successfully, yet)

Sigh. A REAL MAN... could make a GUI ipod controller-pad... from pieces/parts of the colorpicker code.  (a REAL man).  Unfortunately, Wingnut is a scared man. 

But but but but... doncha think that an ipod control... would be a useful new GUI control and possibly be the basis for Babylon VirtualJoysticks v.7.0?  Huh?  Have we got ANY GUI virtual joysticks?  Maybe they went obsolete.

A reminder, Vikk.  The virtual joysticks from the old days... are not like my red joystick.  They are/were more like what YOU want... a drag-thing to control camera movement/navigation.  They used an annoying extra canvas layer.  Maybe they still exist.  Let's hope not. 

For ME to modify colorpicker until it became the new ipod-like control... would take about 3 months, I predict.  Ow.    But... colorpicker sure is a nice, pretty, drag-able GUI controller, eh?  VR headset-ready. 

But but but 2.0...  an ipod controller COULD be "pieced together" from the currently-available GUI controls, and work just fine.  I know it.  So... THAT route could be taken, too... without the need to invent a brand new GUI control.  hmm.

[Guest]

By the way the mastermind behind the color picker is @adam

[Wingnut]

Oh, thx dk. 

Ahh yeah, adam... hero to all ages... good coder, good thinker.  Adam has made a GUI control, huh?  *sigh*  That rotten son of a  guy is SUCH a hero of mine! 

I wonder if he has the only "outsider"-written GUI control so far.  Bet so.

Anyone remember when I was mapping ADT's onto spheres to create those round gauges/meters?  Well... you know... "painting" arcs/circles (math stuff) is probably a much wiser way to make a circular meter... than... you know... https://www.babylonjs-playground.com/#11JINV#36

Why am I still talking?  Oh yeah... round-shaped GUI controls (with dragable center dot).  hmm.

[vikk]

I am stuck yet . please help me

 

[Wingnut]

*nod*.  *sigh*.  Not able to convert your yellow-circle dragging... into xspeed and zspeed values, for your new beforeRender-based camera mover, eh?  That's cool.  We'll keep digging.

 

I was hoping that @adam would agree to modify his colorpicker into an ipod control-pad... for us.  Vikk, I really think using BABYLON GUI... instead-of HTML/jQuery... is better.

(Side note to Adam:  Did you see that the colorpicker docs are within the 'containers' section?  Is it a container?  I'd be glad to adjust that, if you wish.)

Anyone, could you please help me activate the colorpicker source code... found here:  https://www.babylonjs-playground.com/#91I2RE#4

I seem to have lost my golden touch... for hijacking framework code into playground scope. 

Once I can get that "turned-on" in the playground, then I have a "hacking" environment.  I'll borrow Adam's circle-drawing techniques, and his dragging techniques, and a million other techniques... and make an ipod control.  The Gods can turn it into TypeScript later, if they so choose and deem it worthy.

If that looks impossible, I''ll borrow some dragging knowledge from Adam's code, and piece-together a primitive ipod control... using 5-10 separate GUI controls.  Perhaps I can even make 4 arrow buttons... curved to match the ipod's circular control contour.  (Essentially, each of the 4 buttons is 1/4 of Adam's colorful circle.)  That would look pretty. 

Ideally, we probably don't want the center drag-circle... be allowed to cross onto/under a surrounding button.  SO, if each button was a "quarter-circle arc" -shaped... that would be best.  I wonder if GUI can sense a click... on a quarter-round-arc-shaped button.  hmm.  But Adam... can sense a click... ANYWHERE on his color circle.  So... I have hope. 

I'm so slow at helping, eh Vikk?  Sorry.  I was hoping that you could get xspeed and zspeed numbers from your current draggable yellow circle, and just feed those numbers into our new beforeRender camera mover.  Oh well... we need the ipod control for our GUI system, anyway.  I might as well code it, or whine like a spoiled brat until someone creates one for us.   

If someone creates the ipod GUI control, it will be the first "combo" control... having 5 actions associated with it.  Forward button, back button, left button, right button, and dragable center-pad.  Gruesome control!  Perhaps we could use a helper class... the GUI Custom Combined Control Manager.  oooh. 

Technically, i guess the virtual keyboard control... is the first 'combo control', sort-of.  *shrug*

Stay tuned... thx for your patience Vikkmeister.

[Wingnut]

Hi again, Vikk and everyone.  Well, I fought with the jQuery drag PG a bit more... failed to get it dragging.  Lines 169-211 area... having problems making the yellow #innerpad... be draggable.  Not sure how to move 'forward', there.  (or backward, or sideways, or any other direction - ar ar ar)    Help welcome.

The other avenue is started, too.  I will try to make a GUI ipod control... by modifying a colorpicker control.  https://www.babylonjs-playground.com/#91I2RE#6

As you can see, I finally was able to activate the in-playground colorpicker source code, but it runs only once.  Only one drag or click is allowed, and then it quits working.

Still troubleshooting.

Update:  https://www.babylonjs-playground.com/#91I2RE#7  Line 367 - this._host._capturingControl = null;   ... needed disabling.    Yay!  Next, we move a camera with a colorpicker... as a proof of concept. 

Another:  #91I2RE#9  Not much new.  Good code in there... Adam seems to know what he's doing.  For me, it's like trying to read 'the fine print' of insurance policies. 

[Wingnut]

Here's another.  https://www.babylonjs-playground.com/#91I2RE#15

Starting to come-around.    Slow slow slow.  Click inside circle... if smaller center circle is missing after load/run.  I have a little bug with initial center-circle drawing.

But we got center-dot drag and we got camera moving.  YAY!   Phew.

Currently, moving the arc-cam .target location.  Sensitivity setting at line 465. 

I think Vikk wants to TURN the camera when drag left/right, not slew/strafe.  I might need to change to a freeCam for that.

Also, still got some drag limits to set (they go a bit too far)... and 4 buttons to make.  Ideally, they are "quarter-circle" buttons (the 4 of them combine into a complete circle around the center-drag area).

Gruesome trails ahead, yet.  Exciting! 

[Wingnut]

Hi Vikk and others.  Busy RL day, but I got SOME work done on 'the insane project'.

https://www.babylonjs-playground.com/#91I2RE#21

https://www.babylonjs-playground.com/#91I2RE#22  (this one with x-drag axis... bound-to arcCam.alpha.  Left/right drag... turns camera, not slew/strafe)

I put some divider lines on the outer circle, to make them look like quarter-round buttons.  I also turned on 5 image-only buttons, and just hammered them into position.

These 4 buttons (actually 5 but we can ignore the blank button in the middle) are in a new stackpanel... panel 2, and it's a vertical.  

And, I'm laying out the center 3 buttons as if they were in a NON-vertical stack of their own.  Bad idea on my part.  Anyway, TMI, huh?  

Interesting... look at the right arrow area around line 435.  Height = 0px?  PaddingTop = -105px?  Gruesome.  Poorly done by Mr. Wingnut.  The center three button areas (left, right, and nullspace) SHOULD be in a horizontal stack panel together.

Also, the image buttons are BEHIND the picker's blue ring.  That is why they don't change color when moused-over.  I think they are blocked.

They SHOULD be in front of the blue ring, but I can't figure out how to do that, yet.

Hell, look at line 478.  picker.paddingTop = "-150px";  GRUESOME.  Just FORCING things around, like a madman.... hammers, crowbars, come-alongs, and jaws-of-life device.  heh

Trying to define click-zones on quarter-round buttons?  What a ridiculous task.    There might be better ways... not sure (based-upon the angle between center and where upon ring the click happened). 

Currently, I'm too scared to test-change the size of the picker.  Those click-zones will totally go to hell... if I do.    Oh well, it's "click zones v0.1", anyway.  It's supposed to be crappy... at version 0.1.

AND, this PG is a 4-button version (quarter-round buttons).  Wait until we try the 8-button version and ITS click-zones!   (optional northwest, northeast, southwest, southeast... with all eighth-round buttons).  My dog has run away out of fear, and... IT TOOK ITS PASSPORT!  That's one scared puppy!   heh.

Also, I need to somehow limit the drag-distance of the center circle... keep it from crossing onto the blue ring.  Work work work.

I REALLY think @adam should take over and run with this, now.  Pretty please?  I'm getting a tumor.  This is too big of a coding mission for young Wingleberry.

[Wingnut]

Hi guys.  Does anyone mind if I keep on talking?  (It's my way of gently begging for team help.) 

Latest PG.  [link]  Lines 150-168.  Using the var ang, I can draw those little white lines onto the blue ring.

Now look at lines 299-325.  Adam has built a couple of click-location checkers.  _isPointOnSquare (is click in center area?  the 'square' is currently un-drawn - reversable wingy mod)... and _isPointOnWheel.   We can KNOW where the click happened (most importantly, perhaps we can determine WHERE upon the outer ring... did the click happen).  These two "flags" are used in the updateValueFromPointer func at line 263. 

SO, it is MY theory... that IF _isPointOnWheel... we can calculate a clickAng, and use that value to determine which outer-ring button was pressed/clicked/touched.

THUS, we can eliminate the click-zones crap.  Even for an 8-button outer ring, we can use our new clickAng to determine which button (where upon the outer ring)... the onPointerDown event happened.

This system would be sweeeeeeeet.  It actually opens-up the project... to have ANY number of buttons on the outer ring.  Show inventory buttons, target closest enemy, increase IPOD backlight, ANY button... can be put on the outer ring of our new ipod controller.  COOOOOL!  I think this is wiser than using click zones made from imageOnlyButton controls.  Keep in mind that these outer ring buttons... are "stupid buttons".   Testing for pointerEnter/pointerExit on each sub-button is (likely-) NOT allowed. 

Putting icons or text atop each ring-button... difficult.  Likely, ring button labels will ALL need to be on a single image, drawn in a circle, and might require an extra little-canvas. 

Making each button a different color... likely possible.

Sigh.  Why do I care?  Cuz Vikk had a need, and we have no virtual joystick graphics made from Babylon GUI, yet.  Where the heck is @davrous?  Is he still alive?  He's Captain VR.  I wonder what he is using inside the headgear... for VJ gfx.  I suppose the software for these newfangled VR headsets with gloves/air-thimbles... supplies some graphics when the air-pointer/thimble is raised in front of the head gear.  I wouldn't know... I'm not rich enough to experience those kinds of luxuries.

I guess, originally, virtual joystick graphics were designed-for "two-thumb fun"... for games/VR-nav... on touch-screen tablet devices (no headgear or air-pointers). 

Seems like we need some virtual joystick graphics made from Babylon GUI, for the future, and for Vikk right now.  I think the IPOD controller can be versatile enough to use for both needs... and many future needs, too.  onChangeObserving for a combo/compound control like this... could be challenging.  Right now, picker.value has a setter and getter... and it is currently a simple {x: xval, y: yval} object.  It used to be a color. 

I suppose outer ring needs ONE onChangeObserver (check for button clicks)... and inner-drag circle needs ANOTHER.  Two onChangeObservers on a single control?  Erf.

Another thought... is to make the outer ring... a control of its own.  And make center-dot dragger... ALSO a control of its own.  Construct them with a cooperative size, and you can overlay them atop each other... without unwanted interference.  hmm. 

The ring-o-buttons control could be useful in non-drag situations.  Conversely, the "drag-able dot" could be useful at times when no ring-o-buttons is desired.  They are ok alone, but even better... together.    This method would also be conducive to allowing ANY "controller" to be inside a ring-o-buttons controller.  Sometimes users might want a PLAY button in the middle, and not a dragable puck/dot.  Perhaps a pretty circular picture could go inside the ring.  Maybe some targeting reticles, for when a BIG ring-of-buttons is used as a HUD for a starfighter craft.   

I like the "separate components" idea, but getting their over-layed canvai to play nicely with each other...z-index-wise and isBlocker-wise... could be challenging.

HELP!  heh.  Suggestions?  Ideas?  Anyone want to take the helm?  I'd gladly relinquish it. 

[Wingnut]

Hi again!  Okay, on the high-interest subject of hacking an ipod controller for BJS GUI (snore)...  https://www.babylonjs-playground.com/#91I2RE#29

Mostly, work happening in updateValueFromPointer() below line 280... the center-drag circle functionality.  (_draw is also involved, of course.  onPointerMove, too.)

Drag-circle now stays within outer ring, and this.value now maintains "clean" offset-from-center numbers.  (see console while dragging center-circle)

I also activated a snap-to-center on pointerUp.  ALso, this is a FREEcam version.  Previous was ARC. 

Next, I'll start working-with the outer ring (the 4 quarter-round buttons).  See the 'ang' formula in line 275?  'atan2' !  Wow, that sure sounds mathy.  Scared?  I am.    Remember the TV show "Ark 2".  Wow! 

For those not paying attention, the quarter-round buttons are not really buttons.  Because of their shape, its a pain-in-the-butt(on) to determine their 'click zones'.

Soooo, I... (and the huge group of volunteer helpers that have climbed-aboard this campfire adventure)... will attempt to determine an angle... from center of circle... to where-clicked-on-outer-ring.  FROM that angle value, we will determine which button was clicked.

And again, no onEnter, no onExit, no onButtonDown/Up, none of those will be active.  Each of the quarter-round buttons are stupid-buttons, to a degree.  MAYBE... we can do a changeButtonColorOnMouseOver... later.  MAYBE.    For now, let's get their clicks workin'.

Sorry this is going so slow, Vikk.  This project is right at the top edge of my intelligence level.  Help welcomed, as always. 

I could use help about... how to label the buttons.  Keep in mind that I would like to allow the outer ring... to have ANY NUMBER OF BUTTONS.    Most ipod controllers just have simple arrowheads for labels.  But later, when we use this controller in full-screen mode (space-fighter HUD circle), each of the buttons (perhaps up to 30 of them)... will need text labels, too.

The ONLY way I can think to do this... is to make the user create all the labels, already in a circular pattern... on a single image/texture (in a 2d paintbox app).  Then I can POSSIBLY overlay that single texture... atop the ipod controller.  It will label all the buttons...  with one overlay-image.  Help welcome... on overlaying a single transparent-background "labeling image" atop entire ipod controller.

If another canvas is needed, it must be rendered "in-front" of course, and cannot be click-blocking for the outer-ring canvas, OR for the invisible square canvas in the center.  It is my hypothesis so far... that both of those canvas are needed... to determine _isPointOnSquare or _isPointOnWheel.  I haven't studied those functions yet, though.

This single "labeling image" MIGHT ALSO be able to "texture" and border the controller... making it look similar to a standard remote control.  *shrug*  Party on.

[Wingnut]

Ok, even more progress.  https://www.babylonjs-playground.com/#91I2RE#35

The 4 quarter-round buttons are now working... somewhat.  I'm not sure WHY, yet... but... keep your button clicks/holds... near the outer edges of the blue ring for best results. 

I think this problem involves the hidden inside-the-ring square... seems a bit large, yet.  I think isPointOnSquare is being set TRUE if button clicks happen too close to center area.

There may be other/better ways (than the hidden square) to determine if click was inside-of, or upon... the blue ring.  Still learning/testing.

I was pleasantly surprised to see the buttons... allow being held-down.  Phew.  Again, keep the button clicks near the outside edges of the buttons, for now. 

Good progress, though.  Thanks to StackOverflow and 2 hours of testing, it appears I have the angle-determines-which-button-clicked thing...  almost working.  YAY!

The global xspeed and zspeed variables... got a new friend, called slew.  It is used for the left and right buttons... making the camera slew/strafe left/right. 

Dragging the center circle left/right... turns/pans the camera (pivot around Y axis). 

I need to ask Vikk about wanted "wire-up" details, IF he/she decides to use this hacked controller.

Although I have 'bound' this controller to a freeCamera, its values can be bound to anything... such as a mesh or light (see lines 493-495).  Party on!

Note:  Changing the control's height and width to "250px" in lines 455/456... didn't do so well.  Work is needed, there.  Standard ColorPicker also, seemingly, fails that test [link] - lines 405/406.  There is a hard-wired _size at line 32 that is of-concern.  Maybe quiet Adam will tell us the story of that.  But, so far, he's been as elusive as a Jack-a-lope.   Adam wrote the ColorPicker... so we're using code stolen from him.  But, he's busy with a day job, I think.  A Muskie School?  No wonder they are so darned difficult to catch (a muskie is also a fish).  Adam is teaching muskies to avoid my artificial lures, I bet.    But my F11 Silver-Chartreuse Rapala will not be denied.  It's irresistible.  heh

[Wingnut]

Alrighty then... one more update.  https://www.babylonjs-playground.com/#91I2RE#36

I'm testing a buttons/keypad "labeling image" (an overlay to put little arrows or words on the buttons).

I found a "CC" image on the web.... with transparent background... to test with.  It works, for concept tests.

Lines 445 - 451 installs this stand-alone 'extra' image control.  It is put into the same stack panel as the picker (bad idea), then uses large negative paddingTop to "crowbar" the image atop the blue ring (worse idea).  There's a better way... for sure.  Improvements in that image-positioning technique... and maybe a better graphic... tomorrow. 

image.isHitTestVisible = false in line 449... what a FANTASTIC feature!  This allows us to click-thru that aux canvas layer (the labeling image) and use our buttons and drag-puck JUST FINE!   YAY! 

With a little 2D paint app work, that CC image could be modified into some arrows for the buttons.  Sweet.

Update:  [#38]  Got some graphics done for the arrow labels.  Looks ok.  Four white arrows, and a little black dot in the center, not perfectly centered.  The white divider lines between the buttons COULD have been done in this overlay-image, too.  Currently, they are done during the dynamic ring-draw... lines 151-171.

Also, I fixed problem when clicking on inner-edges of buttons.  No problems, now.  Also, a less-brute-force-positioned labeling-image (lines 448-458).  (yawn)

[Wingnut]

To rattle-on more, I am now at that "dreaded point".   @Deltakosh once said... "Just submit code in JS, and I'll convert it to TypeScript FOR YOU."  (loose quote)

So... yes, we would like this controller to get to core... someday.  It would be nice if Vikk didn't have to haul around this big fat chunk of code inside his/her project.  It would be nice... if it was part of BJS GUI core/base.  But, it's still not ready for that activity.

GUI controls have rules.  They have an interface to honor.  One of the more-important parts... is onSomethingHappened observer.   

In the #38 playground, see line 27 and line 51.  OnValueChanged.  No onLeftButtonDown, no onButton12Down, etc.  Take notice that I said "button12".  Remember, that I would LOVE to allow the ipod controller to be HUGE in size.... where the outer ring uses almost the entire screen (spaceFighter HUD).  THEN, the "ring" could have ANY number of buttons.  Remember I derive WHICH BUTTON WAS PRESSED... via the angle.  So, you know, 360 degrees in the circle, 360 "stupid" ring buttons... no problem.

I call them stupid, because no onEnter, onExit, etc.  We could fake-generate an onPointerDown for each button, if wanted.

MAIN PROBLEM... the ipod controller is actually TWO controls.  Theoretically, the center drag-puck... is one controller with an onChangeObserver.  The outer ring-o-buttons... is ANOTHER controller... with ITS own onChangeObserver.  These two controls generate DRASTICALLY different dataTypes for their values.  The drag-puck (center dot)... produces a Vec2.  The outer ring... who knows what THAT will output.  Probably... umm... a button number/id.

In short (yeah, right)... I must pause to think about HOW IN THE HELL to separate this thing... into two separate controls (which play nice with each other, when over-layed like they are now).

OW!  Did Deltakosh say that he would convert TWO javascript mods... into TS?    I hope so. 

Somebody needs to take-over this project... soon.  It's TOO BIG for me, but we gotta have it.  These are two important controls.  Universal draggyThing, and universal circle-o-buttons. 

C'mon, who wants to take over?  Anyone!  Farm animals and woodland critters... welcome to apply!  Somebody spearhead this thing into core-worthiness, huh?  I'm scared.

What's that?  You wish you could "experience" an 8-button ipod controller?  Ok.  https://www.babylonjs-playground.com/#91I2RE#40