for customization of on screen dom button

[Wingnut]

hehe.  Zero volunteers for taking over the helm.  Alright!  "The BJS Forum - Where Teamwork is ... "  (nevermind) 

I must be the worst campfire story teller in the world. 

Anyway, we move-on in brain pain...

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

I have begun the separation of the two controls.  Now, it's "ButtonRing" and "DragPuck".  Source code for both... included in PG.

All isPickOnOuterRing/isPickOnInnerSquare testing/flags... are gone.  Although there are still "hotwired" bindings to camera global vars such as xspeed, zspeed, and slew, those will soon be gone, too.  We'll be wiring up to each control's onValueChanged observers, instead.  We need to follow the rules of GUI control-making... if we ever expect to get these controls accepted into GUI core.

Now... ButtonRing has its own onValueChanged handling - its .value holds strings - button names, so far.  Changes likely.  We must be prepared for 0 - 100 buttons. 

Also, DragPuck now has its own onValueChanged handling - its .value holds a vector2-like pair of floats  {x: float, y: float}.

Everything seems to work, somewhat.  YAY!   Lot's of work ahead.  Help welcome, as always.

I should probably leave Vikk's thread and go camp/yap in the Wingnut Chronicles thread, eh?  *shrug*

update:  I wanted to see a quick mock-up of a LARGE/HUD buttonRing, and here tizzzz.

[Wingnut]

Hi again, girls.  Continuing with our adventure... an important test after separating the two controls... is to see if they will still work when placed atop one another.

Again, all the .isClickOnCenterSquare and .isClickOnOuterRing has been removed from both controls... so cooperating is more difficult.

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

There we go.  The sw, se, nw, ne buttons... need to be clicked on their outer edges.  I believe the center dragger's canvas... is a bit too wide and tall yet.  Its corners are doing hitTestBlocking.

Notice line 540... dragger._zIndex = 1;  Positioning control canvai... atop one another... can get ugly.  Lots of testing ahead.  The secret is with the SIZE of the dragger's canvas.  It should fit within the circle of the buttonring.  The purple drawn square in the middle... is likely a bit smaller than the actual control canvas (I think).

Notice globals changed names.  Now dolly, truck, turn, and tilt.  'Turn' should probably be renamed to 'pan'.  Dolly and truck are z and x camera positions, and turn and tilt are Y and X camera rotations.  In short, the dragpuck does camera tilts/turns (rotations), and the buttonring does trucks and dollies (positions).

I have also started to remove the hotwired things, and starting to ONLY depend upon onValueChanged observing.  Still working on that.

BUT... in general, it appears that even though these two controls are completely separated now, they COULD (maybe) be placed atop each other... to form an IPOD controller (like Vikk wants).

Also notice... no containers or stacks in this one.  I'm adding the controls directly to the ADT (container)   I'm using some scary negative values in controls .top and .left properties, but it gets the job done.

It is probably NEVER wise to overlap two controls atop each other... but... this is a unique case.  Each of these controls needed THEIR OWN PRIVATE onValueChanged... due to their difference in .value dataTypes.  They needed to be separated.  Besides, sometimes users want a dragpuck without a buttonring, and sometimes they want a buttonring without a dragpuck. 

Lastly, buttonring.value is now an angle, in degrees.  Notice buttonring.onValueChangedObservable at lines 574-641.  It is now the user's responsibility to determine which button on the ring... was clicked.

This means that a buttonring control never knows how many buttons it has.  AND, all the buttons, and their labels, and the blue ring itself, and the white divider lines between buttons... COULD be done ALL with a single image.  The buttonring controller COULD produce no graphics at all.  ALL the graphics... could be provided by the user.... via the overlay image (what used to be the labeling image).  The controller itself ONLY would produce angles between center of control, and clicked position.  Weird idea, eh? 

The buttonring control would create no graphics at all.  And thus, it could be renamed... a 'clickAngle controller'.    The buttonring controller might also produce a 'distance-from-center' that the click happened... so... {angle: value, distance: value}, perhaps.  With an added 'distance' in the buttonring.value, it is possible to have multiple button rings surrounding one another.  WOW.

If you re-visit the HUD-sized buttonring... https://www.babylonjs-playground.com/#91I2RE#43 ... you can see that clicks INSIDE of the ring... also work.  This unwanted artifact happens because no click distance-from-center is calculated or included in buttonring.value.  

Ahh... Wingy just rattling-on... to try to avoid being scared. 

We're not quite ready for THIS, yet... but I can smell it on the wind. 

[Guest]

Lol if we can get into that it's gonna be terrific!

[Wingnut]

   A person needs to be a great 2d paintbox artist.  I'm not, so I stole something...

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

Click around "out there".  Watch console.  Now the button ring is producing an angle and a distance.  No graphics are drawn by the buttonring control.

So, with meticulous onValueChanged processing (line 322+) ... a person COULD determine which "button?" in the HUD... was clicked.

I didn't have the patience to build 50 button filters...   if (angle < ?? && angle > ?? && distance < ?? && distance > ??) { console.log("button27 clicked"); doStuff(27); }

Somehow, it all seems insanely possible.  I bet the pros are using an angle/distance system, too... for their circular button-ring widgets.  They almost HAVE TO BE, because... defining a "click zone"... around a curved button... would seem arduous/miserable beyond belief. 

But, there's many things that I don't know... yet.  Goofy project... this buttonring thing. 

The gfx started out as THIS.  I sucked-off the black background with my Corel ShopVac.

-----------------------

Ya know... @Gijs helped us perform a getPixelUnderPointer(), recently.  Generally, a color4 is returned... { r: redVal, g: greenVal, b: blueVal, a: alpha }

What if we invented a PixelPlus datatype?  { r: redVal, g: greenVal, b: blueVal, a: alpha, metadata: anything }

Anything might be a button number, such as 27.

THEN, we don't need an angle or distance.  We click on the screen, it returns the getPixelPlusUnderPointer().

SO...  we simply doStuff(control.getPixelPlusUnderPointer().metadata);  This is the same as a doStuff(27), right?  You bet.   A masking canvas/buffer/array.  hmm.

Scary idea.  Overloading the entire canvas... adding an extra byte to every pixel that has alpha > 0... just to "define" click zones.  Goofy!  (maybe). 

Pixels, pulling metadata travel trailers full of junk... down the highway!  Whooda thunkit?   Next thing we know, pixel rights movements... and dark vs. light pixel wars.  ImageBuffer sects from various 'backgrounds' and 'borders', fighting over paddings and margins.  The Photonic Wars.  hmm.   nah. 

Just make every button a slightly different color.  Easier.  doStuff(pixel).  The button's color... is also its ID.  But that kills shaded button graphics and specular shines.  That sucks.

Nah...  .metadata is the way.  The extra buffer.  The mask array... on GUI control.  And how... does a person... create/edit THAT thing (considering the size of OUR control's canvas)?   OMG.  Brain tumor land, baby.  It (the mask) needs to be created in the 2D paintbox app, and saved as a separate file... me thinks.  Speculating.

Precision click zones.  Yech. 

[Wingnut]

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

Phew.  Gruesome.    Needless to say, it was VERY good news to me... when I discovered that some/all GUI controls... can be smoothly z-rotated.

Don't stare at it too long... you could get an iris tumor. 

These 13 rings... are NOT dependent-upon the custom buttonring control AT ALL.  This is simply 13 GUI image controls (transparent background pngs)... placed atop each other, and rotated independently.  Easy for BJS GUI system.  Not so easy for Wingy and his Corel PhotoPaint program.

[Wingnut]

Ok, hi again.  Now that I have wandered off-topic with the futuristic "iris" GUI... it is time to get back to work.

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

There is the in-dev buttonring control, placed atop the in-dev dragpuck control... to make Vikk's "ipod controller" or something similar.

In a previous chapter, I pointed-out that our northeast, northwest, southeast, and southwest buttons... needed to be clicked on their outer edges.  I thought the problem was that the inner square... was smaller than its whole control-canvas area (on the dragpuck control).  Assorted work in lines 94-101 area... has now adjusted the squareSize to be the entire control-canvas width/height.

And, we can see that my theory was correct.  The inner "dragpuck" control (its main canvas)... is-Blocking hit tests.  (it is blocking part of our buttonring buttons).

With a little dragpuck size and padding adjustments... we're back in the center, with no nw/ne/sw/se button overlap problem.

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

But... clicking/dragging in the red center square (dragpuck controller canvas)... we can see some issues.  The puck is allowed to be dragged/clicked to a position that is partially OFF-OF the red canvas area.  We might not be able to fix this, OTHER THAN limiting the drag-distance.

In a perfect world, we would like the puck to be dragged to the inner edge of the button ring, and stop there.  To do that... our puck canvas must get bigger... and that will cause problems with pick-blocking on our NW/NE/SW/SE buttons again.  SO, this is a pending issue.

Also, I added _this._puckDiameter = 8; to the dragpuck control... at line 33. 

You can turn-off the mostly-unnecessary red center square...  by disabling line 160.

All in all, I'm not sure how to improve this.  A round canvas would be nice, but that is not something soon to be invented. 

Changing the puck circle to be an image control or sprite... that is added-to the ADT itself... MIGHT be doable, but we could encounter canvas z-index pick-blocking there, as well. 

Ideas welcome.  Get the inner drag puck... to stop at the inner edge of the button ring... (without its canvas partially blocking any buttons) and we win.  Thx for ideas/tests.  Party on!

[Wingnut]

Ok, onward with the adventure.  (oh no - yet another ignore-able message from Wingy)

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

In this version, all work is happening on the buttonring control.  Besides new .wheelThickness and .color properties, the distance parameter that returns in a buttonring's .value object... has been put to FULL use.

Now, you MUST click precisely on the blue ring buttons.  If you click inside the ring, or beyond its radius, no click is triggered.

WITH this accurate radius checker (at line 454), we get more power.  We get the power to have a second buttonring (red)... surrounding/overlaying the first buttonring (blue).

Currently, only the north and south buttons of the red ring... are active (camera ped-up and ped-down).  But, it works!  YAY!  And so do all 8 blue-ring buttons!  YAY 2.0!

I just had to try a 2-ringer.  We now have a total of THREE controls placed atop each other.  Actually, FIVE controls, if you include the two labeling images.  Yet only two ._zIndex settings were needed... on the dragpuck (line 548) and on buttonring2 (line 666).  Easy.

A 3rd, 4th and 5th ring is certainly possible.  Remembering the 13 rings of our futuristic "iris" reticle GUI... yes... 13 rings should be possible.

Earlier, we discovered that a buttonring control CAN draw its own colored circles and button dividers (like those seen in this PG).  Currently, only the little arrows... are an overlayed image.

BUT... as with the futuristic "iris" graphics, the programmer can provide ALL of the graphics, telling the buttonring controller to NOT draw anything.  Yet, the buttonring's angle-of-click and distance-of-click values... are handed-down to buttonring.onValueChanged... where the programmer uses those values to determine which ring-button was clicked.

Phew, that's a lot of words.

Interesting thing:  Look at lines 482-484 of buttonring's onPointerUp.  I NEED buttonring.onValueChanged to trigger... after the onPointerUp.  This is mainly to stop the camera movements upon pointerUp.  Line 482 made that possible.  Using lines 483/484... did NOT work.  buttonring.onValueChanged does NOT trigger... if using lines 483/484 instead of 482. 

Try it.  Disable 482, activate 483/484.  The camera never stops moving (onValueChanged code lines 586-590 and 676-679 never runs).  OnValueChanged seems it won't observe discrete property value-changes on a value object.  hunh.

I guess that's expected, but ain't it interesting?  I change both properties on the value object (483/484), and the onValueChanged observer didn't even notice.    Not a very attentive observer, eh?  heh.  I suppose we would need to create a checksum on an object, and then check for a checksum change (I just spit a little)... to test if ANY property on some object... changed.  (huh?).  Or maybe my value object... needs its own .onValueChanged observing/notifications.  Smart values.  Cool.

[Wingnut]

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

Whelp, no new ideas showed-up.  This is about as close as I can get... to perfection... using the 2-overlayed-controls method.

The drag puck has drag-limiters on it... to keep if from going off-of its canvas.

The corners of the drag control's canvas... block picking on the inside edges of the NW, NE, SW, and SE buttons on the buttonring control.

Any more size-reduction of the drag control, and we lose drag range.

I would love the drag puck being able to reach the inner edge of the button ring... but I just can't figure out how to do it (with 2 separate controls). 

With a single 'compound control'... more possible, but control.value will look like ...  {x: xDragValue, y: yDragValue, angle: ringClickAngleValue, distance: ringClickDistanceValue}.  Four values... for one controller.  The first two values... are for the drag puck.  The second two... for the button ring.

I think... the last version of the "ipod control" that used a single control... is https://www.babylonjs-playground.com/#91I2RE#38

Anyone, feel free to run with it.  It needs work before it would be ready for core, if ever.

Not that there's been much interest in this project, anyway. 

So, I'm gonna bail on this adventure.  I've been sick quite a bit, lately, and I'm going to get back to more-enjoyable/less-grinding projects.

I hope you have found something usable, Vikk.    Be well.   Sorry if I disappointed anyone.