continued_at_new_forum The Wingnut Chronicles

[GameMonetize]

Pinging @davrous

[Wingnut]

Does anyone have any news on the yoda/monaco errors in the playground?  Anyone else getting them?  Something I broke locally?  help?

SecurityError: Failed to load worker script at "http://yoda.blob.core.windows.net/monaco/vs/base/worker/workerMain.js?service2" (unknown)
SecurityError: Failed to load worker script at "http://yoda.blob.core.windows.net/monaco/vs/base/worker/workerMain.js?service1" (unknown)

(that's Firefox)  I think this is causing my lack of intellisense and lack of syntax checking in the playground.  Been dead for about a month, maybe 2. 

Same problem in my IE...  but the errors look slightly different:

SCRIPT5: Access is denied.
File: workerMainCompatibility.html, Line: 1, Column: 1

SCRIPT5: Access is denied.
File: workerMainCompatibility.html, Line: 1, Column: 1

I bet I broke my computer somehow.    I bet my CPU bearings need grease or something.

[GameMonetize]

I was not able to reproduce it unfortunately.

The new playground will be out one day  (I'm struggling with the monaco team to get a feature we need)

[Wingnut]

Hey kids...

   A newer version (v28) of my famous Wingnut Flyer is available... http://webpages.charter.net/wingthing/webGL/flyer28.zip

Fixed a few things, changed a few things, things got smaller, etc.  Uses the newest BJS and recent CannonJS (both included).  It's fun if ya like precision flying in zero-g.  Uses HTML buttons which I plan on converting to Canvas2D primitives, soon.  Control and shifted cursor keys + pgUp/pgDown active, as well as control and shifted numeric keypad keys.  Dual redundancy, just like NASA would do. 

Everyone is welcome to steal all code, or flesh this whole thing into being a game.  Right now, it's a flying 4-poster bed frame (somewhat similar to a SAFER unit that spacewalking astronauts wear).  Translation and rotational power is settable at the top of controller09.js.  Remember that you can HOLD-DOWN thrust buttons... as needed.  Floor is now transparent, using the opacity setting of our new GridMaterial extension... so take the flyer over the wall and under the floor. 

Seems to work fine in FF or IE.  Have questions about this?  Just ask, here.

This is made in prep for a nostalgic game called Space Taxi, but in 3D.  It is also the basis of a movie idea I have (with spin-off game?)... called Docking School - © Wingnut Productions.    Party on!

[Vousk-prod.]

Ah ah, nice !

La NASA et Elon Musk n'ont qu'à bien se tenir!

[Wingnut]

http://www.babylonjs-playground.com/#7LDGB#0

Ain't that a great playground?  Sit and watch it for a bit... it is phasing in/out... the ascii-art post-processor.  I think this PG was made during dev... and I think that is alpha-grade code at the top of the playground, there.  It has since been completely accepted into the BJS realm... because... we can.

It has to be THE STRANGEST post-processing thing ever.  Completely demented in some way.    Then, let's make it MORE demented by using it on THE MOST HI-REZ pg demo ever.  Big fat HDR file, skybox from hell, glass, metal, plastic, wood, PBR mat... just a hog.  Let's phase... between super hi-rez, and the lowest of low-rez.

That... is pretty cool... and demented.    I love it.  Had to brag it up a bit.  I didn't build this - I found it leaning against a tree in Playground Park.  I just brought it to the campfire for analysis and laughs.

Can you imagine... enter the wrong room in a dungeon, and enter Timex-Sinclaire land... or accidentally fall into a pit of Univac.  BOOM, the scene is now ascii. hah.  But if you keep your wits, you can feel-around to find the anaglyph machine, which makes all that ascii text be 3D, if ya got some 3D glasses. 

[Wingnut]

Ok, so, where are we at... chronologically?  Oh yeah... observables.

Did you see where @Nabroski said he was running low on money, and had to go traveling across Germany, doing "medicine shows"?  Does anyone know what the hell he was talking about?  hmm.  I hope he is ok.

That guy is as weird as @Pryme8, and I didn't think that was possible.   (j/k, of course).

But... Nabs sure adapted to Observables and Observers quickly, eh?  I think he has a vast background with Java... and maybe they are used there.

Need more links to things I don't quite have a grasp-of, yet?  Okay, here we go:  EventState

One more?  https://en.wikipedia.org/wiki/Observer_pattern

Ahh, Java and Python... yuh yuh yuh.  But let's keep chasing that EventState usage.  If you take a look at the link in the previous sentence, we see that someone added this comment about BJS EventState:

"A class (that) serves as a medium between the observable and its observers".  hmm.  It's NOT the event itself.

It might contain a "history" of which observers have been serviced so far, in the case of multiple observers... observing the same observable.  (I just spit a little.)

Go WAY down to the bottom of that github source search - to the canvas2d.js thing on the bottom. 

eventState.skipNextObservers = skip;  That is surely the work of Captain @Nockawa. 

Recently, we ran into multiple forum concerns regarding clicking/picking THROUGH a ScreenSpaceCanvas2d, which you can think-of as a piece of clear cellophane... stuck to the back-side of your monitor glass.  It works great for over-layed GUI, but, since it covers the whole screen, even where there are no buttons, sprites, prims, etc... it can block clicks from getting to mesh. 

Okay, okay, a ScreenSpaceCanvas2D has sizing and positioning origin, so it need-not cover the whole screen. But to use ssc2d-based GUI on all 4 edges of the screen, you need 4 ssc2d's.  That sort of sucks.

Anyway,  skipNextObservers looks like something interesting, eh?  *nod*  If anyone gets bored, and wants to teach us all (me) about observers, observables, and eventStates... via a playground or two, that would be great!  I would pay close attention, I promise.  And while you're at it, how about a tutorial... "A Beginner's Guide to BJS Observers".  Hell, just write it here, if you like, and I'll move it to .md and into the docs site myself, no problem.  Glad to do it.

What is the point of this post?  Umm... would it be okay with everyone if it didn't have one?  Thx! 

I guess I still have some curiosity about the ScreenSpaceCanvas2D sheet-o-cellophane issue.  It's a rough one.  I think we will end-up NOT allowing clicks on screenSpaceCanvas2d... at all... not even when they are filled (non-transparent).  ALL picks go through ssc2d's... and onward to the scene/mesh.  ONLY when a group2d, rect2d, etc... is put into/onto the ssc2d... will THOSE be clickable.  The ssc2d NEVER is.  (imho).  This would mean that clicks on the gaps between GUI buttons/prims, even if the ssc2d is filled and completely opaque... WILL travel to the scene/mesh that could be behind the panel.

"But Wingy... how do we allow dragging a ssc2d, to change its screen position (origin)?"

Well, you'd need to add a prim/button.  A ssc2d dragging widget.  When it is dragged, the ssc2d changes it's .origin as the drag progresses.  That would work... in theory.

There's one other option... perhaps.  The ScreenEdgeSpaceCanvas2D.  (what?)  You heard me.  A ssc2d... with an adjustable-sized hole in the middle.  Click in the hole area, you hit the scene/mesh.  Click on the ssc2d, filled or not, and IT services the click and denies or allows all future observers.

But maybe, IF the ssc2d is completely transparent... unfilled... perfectly see-through... then the ssc2d ignores clicks (on it)... and passes them to scene/mesh.  Naturally, ANY primitive2D including group2d... would intercept the click... before the click got to the scene.  But, click on a transparent area between buttons, and through-the-cellophane she goes... unblocked, unobstructed, unmasked, unimpeded, unoccluded, unfettered, un... (I can't think of any more) 

You aren't still looking for a point to this post, are you?    If so, me too.  All comments welcome.  Have a fine weekend, everyone!  Be safe.

[gryff]

5 hours ago, Wingnut said:

What is the point of this post?  Umm... would it be okay with everyone if it didn't have one?  Thx! 

 

5 hours ago, Wingnut said:

You aren't still looking for a point to this post, are you?

@Wingnut : You seem to be making the point Wingy, that your post above has no point. So it does have a point ...

Why do I get the feeling I'm wandering into "when trees fall in the forest ..." and  "what is the sound of one hand clapping..." kind of thinking.

Better stop now!!

cheers, gryff

[Wingnut]

Yeah!  If a rooster laid an egg in the forest, where would they bury the survivors?    errr... something like that. 

But yeah, you were Möbius-bound.  Good idea to bail... before you got a Too much recursion error.

[Nockawa]

On 9/3/2016 at 1:43 AM, Wingnut said:

Recently, we ran into multiple forum concerns regarding clicking/picking THROUGH a ScreenSpaceCanvas2d, which you can think-of as a piece of clear cellophane... stuck to the back-side of your monitor glass.  It works great for over-layed GUI, but, since it covers the whole screen, even where there are no buttons, sprites, prims, etc... it can block clicks from getting to mesh. 

Okay, okay, a ScreenSpaceCanvas2D has sizing and positioning origin, so it need-not cover the whole screen. But to use ssc2d-based GUI on all 4 edges of the screen, you need 4 ssc2d's.  That sort of sucks.

Anyway,  skipNextObservers looks like something interesting, eh?  *nod*  If anyone gets bored, and wants to teach us all (me) about observers, observables, and eventStates... via a playground or two, that would be great!  I would pay close attention, I promise.  And while you're at it, how about a tutorial... "A Beginner's Guide to BJS Observers".  Hell, just write it here, if you like, and I'll move it to .md and into the docs site myself, no problem.  Glad to do it.

skipNextObservers were designed to be able to have a fullscreen Canvas and still be able to select 3D things below. I just didn't have the time to finish coding it (and somebody added a regression that made it less possible it could have been). So now it's supposed to be fixed and thanks to skipNextObservers you can do either: "Canvas2D took care of this event, 3D objects must not be aware of it" or "Canvas2D wasn't interested about this event, the 3D objects might be..."

To be perfectly clear: I think having a fullscreen Canvas is a totally reasonable thing and that I have to support it as much as possible.

Quote

I guess I still have some curiosity about the ScreenSpaceCanvas2D sheet-o-cellophane issue.  It's a rough one.  I think we will end-up NOT allowing clicks on screenSpaceCanvas2d... at all... not even when they are filled (non-transparent).  ALL picks go through ssc2d's... and onward to the scene/mesh.  ONLY when a group2d, rect2d, etc... is put into/onto the ssc2d... will THOSE be clickable.  The ssc2d NEVER is.  (imho).  This would mean that clicks on the gaps between GUI buttons/prims, even if the ssc2d is filled and completely opaque... WILL travel to the scene/mesh that could be behind the panel.

This is the behavior we have now!  you can read this post and see the PG working (hopefully)

 

[Wingnut]

Thanks @Nockawa!  Want to address another issue that I didn't see in your Trello cards?  Remember the thread/demo where a camera was put in the middle of the circle-of-boxes-with-labels... and the labels from the mesh BEHIND the camera... were still seen in front of the camera?  Sorry if that has been solved and I am not up-to-date.

On another subject (for everyone)... ready for a good laugh?  Check out Deltakosh's fine deviceOrientation tutorial... https://www.eternalcoding.com/?p=213

A little down-scroll, and you will see DK say "And as you can see it ROCKS!"

Yeah, it rocks, DK.  It rocks back and forth... and side-to-side... that's what deviceOrientation is all about.    hahaha. 

Too funny.  @Deltakosh is getting quite good at English... already doing comedy with "plays on words".  I laughed some coffee out of my nose. 

[GameMonetize]

Being able to play with words will be quite an achievement for me

[Wingnut]

   Let's see... hmm... you moved to Seattle USA.  Now you mastered English.  Next step to Americanism:  Weekend dirt-track racing (with car named-after your daughter).  Yeah!   Vvrrrrrooooooom!  (Money drain). 

Moments ago, I reported a broken playground, but I needed a browser cache clearing.  Now, all is well.  PARTY!

[GameMonetize]

I will spend this week end in texas learning how to ride horses will eating ribs

[Wingnut]

Really?  Coooooool.  Oh, you're going to have SO MUCH FUN (if the weather is good).  I did some time in San Antonio... too fun!  Buy lots of carrots (after arriving)... horses love them. 

Really, I have nothing to say... except... check out this playground I found in Playground Park...  http://www.babylonjs-playground.com/#14VFYX#0

Beautiful!  I have no idea what is happening there... but these are 100% dynamic mesh.  No loading, no external libs... just tasty math.  Wonderful!  (drooool).

Ok, party on.  DK, have a great time in Texas, this weekend!  Don't eat those brown-colored "trail apples", okay? 

[Wingnut]

SO, um, what is Babylon toolkit and what is babylon.tools?  Are they the same thing?  Where am I?  

Deltakosh and I recently talked (in a thread about "where are the helpers?")... about helpers.    We talked about showAxis, showUVs, ShowNormals, showLightGizmos, showCameraGizmos, boxify, etc, etc.  These are also things that could be integrated-into debugLayer/menus, too.

Deltakosh gave approval to add these tools to "toolkit".  Does anyone feel like spearheading (leading) a movement (team)... to gather great versions of these "tools", and add them (probably with TypeScript)... to our framework?

I think Deltakosh's idea of "fleshing" our tools collection... is a good idea, and would shine a good light (gizmo) on BJS.  So, somebody competent... please run-with this, if you have time.  Recruit help, if you can.  Code tightly, but not weirdly.  Keep 'em small and fast.  Attempt to ask permission-of, and give credit-to... whomever wrote/donated the helper, if possible.

Perhaps, there should be a division.  Code tools and scene tools.

If folks assemble a powerful tool collection, I promise to write a tutorial about using every tool in the (scene) toolkit.  thx for consid!  Party on!

PS: We also need a refactor of virtualJoysticks... using Canvas2D methods... if someone wants to take-on that adventure.  Make the graphics (originally context 2d graphical rings) easily changeable by the programmer, including no graphics at all.  Test carefully after resizings, and with multiple viewports (for example, in overhead map-view viewports). 

VirtualJoysticks are primarily-used for touch inputs.  Interested parties might want to contact @davrous first, to see if he has a plan... already in-mind.  I think he is the author of v1 of that system.  thx!

[Wingnut]

More thoughts on virtualJoystick(s):

There is an issue with window.innerHeight/Width vs. rendercanvas.height/width.  For example, WHEN in playground, do we allow a virtualJoystick atop the editor area, even though the render canvas is only 50% right-screen?  The old VJ's used window.innerETC.  Sometimes the VJ canvas that was appended onto doc.body... would get stuck ON, and you couldn't type in the editor anymore, or hit playground top buttons.

(Later I learned that I could open my browser f12 dev tools document inspector tab, scroll down to find the last <canvas> in <body>, highlight it, and then hit delete key.  Worked fine for removing vjCanvas that got stuck ON.)

BUT... is left-VJ-atop-PG-editor... a desired behavior... sometimes?  I think so.

If so... we got trouble. 

A ScreenSpaceCanvas2D won't apply atop the playground editor (or atop any other html area), under any circumstances, right?  Or will it? 

One could ask... "Why DID Davrous use window.innerFOO... and not canvas.width/height?"  hmm.  SHOULD the VJ's be allowed ANYWHERE on the screen, even if the rendercanvas is left, right, or small?  Probably yes.  That allows more hand comfort... when doing touch-device 2-thumb fun. 

Deep thoughts, eh?  hmm.

[davrous]

Yes, this is our 2.5 roadmap to refactor VirtualJoystick using @Nockawa Canvas2D engine. It will solve all the issues you've mentionning.

[Wingnut]

Hi again.  Sorry, I have to ping-up @davrous and @Nockawa again... to raise one more concern.

First, I want to remind everyone that Nockawa is beginning his new canvas2d-based widgets library.  Coooool.  It is my opinion... that the graphics for virtual joysticks.... be part of that library.  And I have another hope.  That folks make MANY different "GUI-packs" for virtualJoysticks... and share them with others.  These could be "VJ extensions" for Nockawa's widgets lib.

So, if you would be so kind... Davrous, could you try to make the GUI for VJ's... nicely detachable/replaceable?  I mentioned it earlier, and you agreed... but I wanted to talk about this "next step"... where everyone shares "VJ Gfx Packs".  I think that would be excellent.

I have a question about mobile devices... where we might use that "two-thumb fun" mentioned earlier.  Two-thumb fun... refers to a way a "pad" is held... often when playing games or touring VR's.  A hand is on each side of the device, and two thumbs are on the touch screen... all very comfortable and natural.

Now for the question.  Do ANY of these devices... place ALT, CONTROL,SHIFT physical buttons... on the border of the device... within reach of thumbs?  To be brief, could one or both thumbs... reach an ALT or CONTROL physical button on the pad somewhere?  I have no hands-on time with mobile devices.

OR... would we place primitive2D-based control/alt/shift buttons along the screenSpaceCanvas2d bottom edge... making them be within reach of thumbs?

The important part is... the graphics of a virtualJoystick... could be modified... by control/alt/shift keys. ("buckies" - Stanford U. term for control/alt/shift/meta keys, etc).  For example, a blue arrow is active ahead of your right thumb... indicating you are traveling forward in the scene.  You want to keep right thumb in-place, to maintain motion.

Now tap the control button (physical or prim2d) with your left thumb, and camera goes double-speed... RUN mode.  The arrow could change... become a different color, or longer, or on-fire.  The VJ's GUI... went from normal mode... to ALT mode, or to CONTROL mode... or to SHIFT mode.  Three "buckie" modes... and one normal mode... for a total of 4 modes.

Ok, back to VJ graphics widget packs... that we hand-around with friends.  Can we agree... that a properly-equipped VJ GUI Pack... must have 4 sets of graphics included?  One for normal mode, three for "buckies"  (control, alt, shift).  A truly fully-fleshed VJ GUI Pack... would have all 4 gfx-sets included, yes?

At least... the template... for a VJ GUI Pack... should be ready to facilitate 4 sets/modes of widgets... yes?  Maybe?  No?  Thoughts?  Drag widgets, swipe widgets, pinch widgets... a fully-fleshed touch-screen widget pack... could be quite a challenge.    Thanks for dealing with my prattle.

[Nockawa]

What I can say is that the control's logic will be separated from its visual display, through templating/styling.

e.g: a button has a "click" behavior, is has many states: normal, hovered, pushed, disabled. there's a default visual template for the button's normal state and variations for each of the other states.

So you will be able to apply this logic on the Virtual Joystick control, providing a default style but letting people create their own while still benefiting of all the control's core logic.

[Wingnut]

*nod*.  I'm not sure a VJ graphic will have characteristics of a button.  They will actually be more related to a hand-pointer or crosshairs.  More indicator than button, I guess.  Maybe not.  Perhaps, in some situations, it would be 8 buttons.

More examples:  https://www.google.com/search?q=virtual+joystick&num=300&source=lnms&tbm=isch

I guess... at it's core, a thumb placed on a touch-screen... IS a button press... but after the initial touch, it's often all about drag-distance FROM that initial touch-spot. 

Have you seen our old-version of VJ's @Nockawa?  It was dual rings for each joystick... one smaller than the other, smaller one inside the larger one.  Upon touch, both rings came ON, (or sometimes they were ON all the time), and then as drag happened, the inner ring followed the thumb-drag, and outer ring stayed where it was.  Inner ring would often travel well outside of the outer ring.

I don't know if your widgets system will need to take these things into consideration, or not.  I just wanted to let you know that there is a future use-case for these things, and to give you a heads-up.  This way you can keep it in the back of your mind... and perhaps get some good ideas.

And I can foresee normal drag, control-drag, alt-drag, and shift-drag.  These might affect how you design your events processing.  For example, do you need to make major adjustments to your events processing... to honor control/alt/shift button clicks?  (such as changing the CSS cursor depending upon if control/alt/shift are held... before a click).  Will you be ready with "grab", for example?  (for drag'n'drop).  What about "not drop-able here" cursors? 

I'm very inexperienced in these things, so, sorry if I'm worrying unnecessarily.

All in all, thx for keeping VJ's in mind during your dev.  I think VJ's have a big big future.  Etch-o-sketch... without the knobs. 

If you get bored, I would be interested in knowing if a SSC2D... can cover an entire web page... HTML and all.  (comfortable 2-thumb-fun in a playground scene... with left VJ atop the editor area?)  thx.

[Wingnut]

For those wondering why-the-hell is Wingnut so concerned with e-controllers (like touchscreen/virtual-joysticks)...  whelp, a long time ago when the Earth was green... Wingnut thoroughly thought-out a way to make our transportation systems... better.  Although I was not the first to ponder drive-by-wire systems (fly-by-wire is common in aircraft)... my thoughts were to make the interior/body of a car... easily detachable from the chassis of a car.

One of the important parts of that idea... is the connector(s) that hook the interior control systems... to the on-chassis actuators/servos.  Triple redundancy was what I determined would be needed... to convince the DMV/DOT... to allow cars to be drive-by-wire.  One primary system, 3 backup systems.  (Not triple actuators on the chassis.  Triple connections from the driver controllers/encoders... TO the actuators.)

Another aspect... was DOT-approved chassis-worthiness checks.  In a trip across a nation, you would leave your chassis behind at a high-speed rail depot, get your mini-van "crew cabin" loaded onto a rail car (which would give it power, internet, cable tv, and maybe potty tube)... and you "live" in your mini-van interior for the entire trip (with a porta-potty).  Zoooom!

When you arrive at your destination, you rent/custodian a DOT-approved chassis, and get your mini-van interior placed atop it (by a small crane at the rail depot).  Then... the chassis and the interior do quite a thorough handshaking.  The chassis must pass its 450-point wear-and-operational check... or else your mini-van interior would refuse to operate atop that inferior chassis.

Then, the calibration.  Encoders calibrate with the brake slop, the steering slop, the throttle sensitivity, on and on.  When the calibration is complete and successful... the drive-by-wire controllers turn ON... in the interior of the vehicle, and you are allowed to drive away with your communal chassis under your family's mini-van interior.

And then, finally, since we have drive-by-wire, triple-redundant, chassis-worthiness checks, and perfect calibration, DOT will say "ok, fine.  What will you use for controllers?"

Yep... here we are, joysticks, touchpads, you name it.  The type of controllers used in these drive-by-wire cars... might only be limited by one's imagination, and could get REAL non-standardized (personalized).  Soooooo.... what could happen... is that we EACH have our own DOT-certified digital controllers and encoders... and we carry them from vehicle to vehicle.  Maybe wifey Jane likes to drive with a touchpad.  Perhaps hubby George likes to drive with a flight stick.  Daughter Judy... she's using the Vive.  Boy Elroy... he's using an old-style classic automobile steering wheel... but it's still connected to chassis ONLY by wires (and maybe by digital radio backup).

And how will the controllers hook to the dashboard?  Yep... triple redundancy wiring.  In fact... a radio signal or internet connection.... could drive your vehicle... from afar.  But let's not think about that right now. 

Anyway, I just wanted to show WHY I have such a corncob wedged-up my butt... about controllers, and graphics/indicators related to them. 

("Yeah Wingy, we don't care, and you've bored us to death!") 

[Wingnut]

Hi gang.  Forum user @thiendv and I will begin an ongoing project here.  EVERYONE is encouraged to help.  This is a branch from this post.

@thiendv wishes to have pop-open interaction menus... on mesh... using Canvas2D.  He wants to use an imported scene, and possibly have video on one of the mesh.  We start with a @Nabroski scene, imported, with video.  It HAD 8 mesh, but I removed 2, so now it has 6.  Here is our starting scene.

http://www.babylonjs-playground.com/#BUWYF#16

Six boxes, 4 purple, 1 gray, 1 with video playing.  I have put actionManagers on all 6 boxes (line 35) with right-click triggers (line 36) which call a function rightclick() (lines 24-26).  Line 28 is a jQuery call that disables the default right-click menu from the browser.  Watch console, and you can see that right click is working on all 6 boxes, and the event.source.name (right-clicked-mesh.name) is printed to console with every right-click on a box.

All is well... so far.  Thiendv... study this, please.  ActionManagers on each mesh... with OnRightPickTrigger... with executeCodeAction... is a nice start, right?  In the rightclick() function, we could do lots of things. We could build an HTML pop-open menu, or a worldSpaceCanvas2D/group2D pop-open menu, and also test if a mesh named 'Thien' was clicked.  If yes, perhaps give THAT mesh a "special" pop-open menu... for doing video things like pause, play, restart, etc.

We are at a branch point.  Basic "interaction" is done.  We have good right-click and good function call.  Now, the hell begins.    I do not believe that ANYONE has built pop-open mesh menus using Canvas2D, yet... ever.  So we are in a new world.  But look at this playground, please:   http://babylonjs-playground.com/#1N9RJY#39

Our camera is in the middle of a circle-of-cubes.  Each cube has a group2D associated with it (line 19) with a trackNode parameter (pointed to the cube).  Each of those group2D have a text2D as a child (line 23).  This is how the labels are placed on the cubes.  The important thing... we can build pop-open menus using similar methods.  They will "track" any mesh.  We would build these pop-open menus... inside our rightclick() function (of the #16 playground)

But there is one problem with using a screenSpaceCanvas2D (ssc2d) with multiple group2Ds (like the #39 playground).  We can see the labels from mesh that are behind the camera.  We don't want to see those.  But perhaps, no problem for pop-open menus.

Or perhaps... we will need to use 6 worldSpaceCanvas2D (wsc2d) instead of 1 screenSpaceCanvas2D (ssc2d) with 6 group2D's. 

Wsc2d (WorldSpaceCanvas2D) and ssc2d (ScreenSpaceCanvas2D) are the two primary ways to use Canvas2D.  To use Canvas2D, one or both are required... but we can mix them, and we can use many.  Wsc2D automatically has a trackNode/trackedNode, so IF we use six wsc2d, we might not need to use group2d at all.

Okay, @thiendv and I... need a break, now.  We are pooped-out and our brains hurt.  

Here is where we need Canvas2D experts... to help us make a pop-open and pop-closed multiple-menuitem menu.  A little one.  Let's call it...  mesh context menu  (mcm).  Would anyone like to help us... maybe @Nockawa?  We would like the menu items/choices to use left click.  Right click is for opening and closing the MCM. 

CAMPFIRE PROJECT!  YAY!!!   Who's with us?  Ya'll gather 'round, because we are beginning to play with fire.

Talk soon.  Everyone, feel free to post anything, but stay on-subject for a little while, okay?    We want to get @thiendv rolling forward on his project... soon.  Thanks!

PS: Latest version of Firefox (49.0.1) fixed some "flaky" video loading (inconsistent - often hangs).  New version, smooth sailing, for me.  Yay!

[Nockawa]

I'm working my *ss off to build a GUI library, which will include context menu for sure. The foundations are important and I got delayed because of two things:

1) We decided to split Canvas2D/GUI from the main babylon.js source directory and js file.

2) I've been working with @Temechon on a new very super cool feature that will help everybody using C2D/GUI.

Nonetheless, the GUI is going on fine, as expected, the delay is mostly due to "new stuffs" that were unplanned. But I can't rush it more or change the priorities.

So it's still the same since C2D is release: it's up to you guys to wait....or do it yourself. I know there're expectations and I don't want to deliver something average and buggy...so it takes time.

[NasimiAsl]

35 page is very small for Wingnut chronicles