How to use a virtual joystick to control object?

[ozRocker]

I've used the virtual joystick before and that worked pretty well.  I'm wondering how I can use it to control something other than a camera?  Is there a way I can tap into the existing virtual joystick in Babylon.js and use its values to control something like a mesh?

[GameMonetize]

Hello

 

yes you can

look how the camera uses the virtual joysticks here: https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/Inputs/babylon.freecamera.input.gamepad.ts#L15

[Wingnut]

Hi again, ozR!

   Are you ready for this? 

http://playground.babylonjs.com/#OORFZ#5

ooookay... first off, after about 20 seconds, this playground turns off the virtual joystick, so you can edit in the playground again.

The rest, I'll let you examine for a while.  I over-rode the event handlers on the joystick, and put them into hacking scope. 

An old joystick gets stuck on-screen at RUN-time, occasionally.  I haven't quite figged the reason for that, yet.

Holler if you have questions.  This should get you rolling, though.  Your code may vary (almost surely) 

 

[ozRocker]

On 4/10/2016 at 11:23 AM, Wingnut said:

Hi again, ozR!

   Are you ready for this? 

http://playground.babylonjs.com/#OORFZ#5

ooookay... first off, after about 20 seconds, this playground turns off the virtual joystick, so you can edit in the playground again.

The rest, I'll let you examine for a while.  I over-rode the event handlers on the joystick, and put them into hacking scope. 

An old joystick gets stuck on-screen at RUN-time, occasionally.  I haven't quite figged the reason for that, yet.

Holler if you have questions.  This should get you rolling, though.  Your code may vary (almost surely) 

 

Sweet!  Best answer eva!! Thanx mate

[ozRocker]

I've put some commands in the onPointerUp event but when I do that it completely overrides the existing event and doesn't execute the code that removes the joystick graphic off the screen.  Is there a way I can add to the existing event, or call some code to hide the joystick?

 

	vj._onPointerUp = function (e) { 
		if (this._joystickPointerID == e.pointerId) {
			window.joystickDown = false;
			window.joystickUp = false;
			window.joystickRun = false;
		}
	};

 

[dbawel]

Hice work @Wingnut!

I spent a while reviewing the VirtualJoystick code in the master file, and love what you've done with it. It appears that @davrous adapted this for babylon.js, but I'm guessing you might be the one to come up with a solution if @davrous, @Deltakosh , or another Guru (the list is fairly long, so I don't mean to leave everyone else out - including yourself) doesn't get to the answer before you read this:

I spent a few minutes trying to modify your playground scene to limit the VirtualJoystick to a specific (x,y) canvas position and limited range, so I can use the VirtualJoystick and camera control at the same time. And when I wasn't able to do this, I tried modifying the babylon-master.js file; but failed miserably after spending about 20 minutes. This is not for anything I'm currently working on, but know I can use this in the near future, and believe others could make use of this as well. So if someone could point me at the lines in the master file which are relevant (it appears this may be several areas within the function), and if I need to change the camera case as well, this would be helpful.

But I believe I know you well enough now "Wingy", so I'm sure if you have the time I'll see a whole new series of playground scenes.

Cheers,

DB

[Wingnut]

hi guys, thx for the kind words and confidence, but if you would have seen me modify Davrous's virtual joystick yesterday, you would have laughed at the dog... digging in the garbage can.  I am no expert on this thing, and Davrous is a genius.  But Dav writes good code, and it's reasonably easy to understand.

In my opinion, a great way to learn how something works... is to "hijack" the entire 'system'... into a playground or mainline project code.  SO, let's hijack a virtualJoystick.

http://playground.babylonjs.com/#OORFZ#7

Lines 92-384, there it is, in all its glory.  A noisemaker in line 101 ensures that we are spawning a vj from the hijacked code and no longer spawning from framework code.

Now it's easy to see that MY custom onPointerMove function (line 27) is NEARLY identical to the default onPointerMove (line 222).  In the first playground, I did a partial hijack... the onPointerMove func.  This time, we have the whole thing... and thus we can erase my func (though I left it installed).  Lines 62 and 63 in my custom function... were the only deltas (changes from normal).  We can easily insert them in the line 255 area, and then erase my custom function.  We can also remove lines 17-21, because our new "complete hijack" has those lines included in the hijacked code.

With all that now explained, back to work we go.  Of particular interest... ANY place in the VJ code that uses window.innerHeight or window.innerWidth.  In MY opinion, that should be changed to rendercanvas.height and rendercanvas.width.   In a recent VirtualJoystickCamera issue that Arktius had (he wanted VJ's to work properly on a non-full-screen rendercanvas), I needed to do a hack.  I did not know where, on-screen, Arktius placed his canvas, nor did I know what size.  So, I first tried to "derive" the needed size for the vjcanvas, by querying/measuring the RENDER canvas.  I failed at that, so I forced the vjcanvas size and position to match the renderCanvas... by setting identical CSS rules:

#renderCanvas {
   width: 50%;
   height: 50%;
   position: absolute;
   top: 10%;
   left: 25%;
   touch-action: none;
}

In line 89 of the Arktius vjCam demo, I did this...

var vjcanvas = document.getElementsByTagName("canvas")[1];

scene.executeWhenReady(function(){

	// when in doubt, force it.  :)
	vjcanvas.style.top = "10%";		
	vjcanvas.style.left = "25%";		

	vjcanvas.style.width = "50%";			
	vjcanvas.style.height = "50%";			

	vjcanvas.style.border = "red 2pt dashed"			
});

Keep in mind that the vjcanvas... is a regular HTML canvas element... appended as the last element in the BODY element of the page.  It's the second canvas.

var vjcanvas = document.getElementsByTagName("canvas")[1];

Unfortunately, it has no id="foo" so we cannot use getElementById("foo").  But we can fix that now, if wanted, because we now have the code that creates it.  vjcanvas.id = "foo" might work, but if not, try vjcanvas.setAttribute("id", "foo");  After that, we can "look up" that vjcanvas with document.getElementById("foo");  It MIGHT be important to EASILY be able to get a ref to the vjcanvas, so we can see if it exists.

SO, now, @dbawel, you have seen how I hacked the vjcanvas to make sure it is the same size as the rendercanvas.  That is step #1 to your "limit" issue, and maybe that's all of it.  Your vj's need to stay on-canvas... like they do in the Arktius demo.  But, as you can see, the starting locations of the vj's is not correct per where the touch happened.  Work is still needed there.

Now, back to @ozRocker.  Being able to easily/quickly/permanently get a reference to the vjcanvas... is important to your "how do I disable/hide" issue. Although I have never tried this, you might be able to hide the vj and its semi-annoying add-on vjcanvas... by setting vjcanvas.style.display = "none".  I would avoid using style.opacity or style.visibility... because those will only make the VJ invisible.  It will still be in your way and not allow events to reach the renderCanvas (...can't use the playground's editor, for example... UNLESS... you have perfectly sized and positioned the vjcanvas atop the rendercanvas as I did in the Arktius demo - tested by putting a red border on vjcanvas so I can see it).

IF you match the size and position of the two canvi PERFECTLY, the playground editor MIGHT still work while the VJ is activated.  No promises, though.  Save often, and perhaps paste code to an offsite text editor... for safety. 

Ok, I hope that covered some of the questions.  Sorry for taking the long road to get there, but, every forum post is also a tutorial for everyone, right?  Once we all understand the "layer system" that our VJ's use, we can ALL start experimenting with them, and with many other overlayed-GUI systems of similar nature.  It is likely that our debug layer/overlay uses this very same method... and we all must admit... that is a SWEET system.  The vjcanvas is a 2D touch-screen "grid", yet it is a HTML element.  AS an HTML element, we gain fun power... like style.zIndex  (we can place it BEHIND our renderCanvas, possibly another way to "hide" it, right OzR?). 

Again, I would avoid using style.opacity and style.visibility.  I suspect that style.display = "none" is the wise move, and style.zIndex is worth testing, as needed.  My goofy CSS3 click-thru-to-spec quick-ref might come in handy.  Party on, gang!

[ozRocker]

9 minutes ago, Wingnut said:

Now, back to @ozRocker.  Being able to easily/quickly/permanently get a reference to the vjcanvas... is important to your "how do I disable/hide" issue. Although I have never tried this, you might be able to hide the vj and its semi-annoying add-on vjcanvas... by setting vjcanvas.style.display = "none" or maybe "hidden".  I would say "none".  I would avoid using style.opacity... because that will only make the VJ invisible.  It will still be in your way and not allow events to reach the renderCanvas (can't use the playground's editor, for example... UNLESS... you have perfectly sized and positioned the vjcanvas atop the rendercanvas as I did in the Arktius demo (tested by putting a red border on vjcanvas so I can see it).

I can't access the vj canvas.  I've looked through the vj object and its just events and joystick stuff, no HTML elements in there.  I went through existing code and it looks like there's a list of pointers in memory.  On pointerUp that pointer is removed from the list.  However, I can't seem to access the pointer list either.

[Wingnut]

Hi OzR... yeah, I can't access it well, either.

Let's try a power hack.

http://playground.babylonjs.com/#OORFZ#9

Line 30 fails for me.  Lines 32-33 work, and so does line 35 (which needs help from lines 2 and 148). 

But I bet you are going to tell me... that you are using an Android thing.  Rumor has it, they don't talk DOM well, so line 32 might fail for Androidians.

Do ANY of those 3 console.logs in lines 30-35...  show [object HTMLCanvasElement] ?  Please say yes, even if the answer is no.  heh

[ozRocker]

Woh! There's a fair bit of code in that one  

I did a simple alert on pointerUp http://playground.babylonjs.com/#OORFZ#10 and it worked on desktop, iPhone and Android.  Thanx man!  I just gotta find a way to pack all that code in nicely

[Wingnut]

  Yeah, in #7 and beyond, I hijacked-in the entire VJ code from the framework.   It makes it easier to do experiments and console.log lines... to "watch stuff happen".  You can trim and snip as needed.  But, maybe just use the entire code... and that way you have full control.  Soon you will have the OzRocker Virtual Joystick v1.0 and maybe you will share it, and add power, or change things, etc. 

For example, you spoke of a "router".  First the VJ is hooked to a mesh.  Then it's hooked to a camera.  Then to a spotlight.  Then to a different mesh, etc.  That "router" is a hot commodity... but you will have to deal with sensitivity and value ranges... as your router selects its targets.  20 hours ago, Deltakosh gave us a HUGE hint.  He said...  code it like our new camera inputs system.  Moreover... code your router... with THAT router in mind.  Cooperate with the routing that is happening in our new camera input system... and everyone wins.  The new OzRocker Joystick will be ready for anything... the new defacto standard for virtual joysticks in BJS.  OzRocker becomes a hero.  Yay! 

[ozRocker]

ok, I separated that joystick code into a separate JS file and added prototype functions that can hook into those events which allows you extend them, so I'm on my way to being a Joystick Hero  (sounds like the title of an 80s arcade movie).  It works on iPhone too but I notice there's bits of joystick that get left behind when I'm moving it.  I'm looking at the pointerMove code and it looks like its just changing position, can't see where these trails are coming from

 

This is the webpage I'm working on http://www.punkoffice.com/animtest

[Wingnut]

Good job, that's getting pretty far in a short time... nicely done.  I'm sure you can see where the "erase" is happening in the code (just a few lines above your "POINTERUP" alert.)  BUT... those clearRect's are not working well... because vjcanvas size not equal rendercanvas size.  But here's a cheat.

See that vj._clearCanvas(); in the line 88 area?  Put one of those... inside your onPointerUp.  That should wipe-off any graphics debris.  It's a "kludge" fix.

A REAL god... would completely rewrite the vjcanvas sizing things... saying goodbye to window.innerHeight/Width and using rendercanvas.height/width, instead.  Then use ALL percentages.  Convert clientX and clientY to percentages of distance from top-left corner of the canvas, not the screen.  Size the joystick rings to maybe 10% of canvas width/height, and then clearRect commands in onPointerUp... would clear an area that is x/y% from top left, and clear an area that is 10% of canvas width/height in size.

Converting to ALL-percentages!  It is no task for children.  The canvas could be anywhere on the screen, but clientX and clientY are giving SCREEN coordinates, not coordinates, and NOT coords from canvas top-left.  Offset troubles!  (yech) 

But if you (or anyone) wants to really kick butt and take names... that's how it's done.  Perhaps, keep a border around that vjcanvas (vjcanvas.style.border = "3pt outset cornflowerblue") ... so when the browser crashes... at least you get more pretty colors.    (j/k - knowing where your vjcanvas is located... is kind of important.  Also, when the border disappears, the joystick is off).  *shrug* 

Am I being any-what helpful, here? 

[ozRocker]

The trails aren't coming from onPointerUp, its coming from onPointerMove.  onPointerUp cleans it quite well, its only when I move it around and unfortunately I can't find the code in onPointerMove that cleans it, it looks like its just translating it.

[Wingnut]

I think that happens in requestAnimationFrame(function () { _this._drawVirtualJoystick(); });

The first two lines of _drawVirtualJoystick()... are clearRect's.  See those numbers at the ends of them?  Those are likely hard-coded pixel values that would be better as percentages.    Unfortunately, this joystick is not coded for anysize and anyplace screens. 

First, _drawVirtualJoystick() clears a 126 x 126 area, and then a 82 x 82.  (It wipes both rings)  Those 63 and 41 numbers, those are offsets... 63 is half of 126, 41 is half of 82.  These are finding the upper left corner of the base ring, and the moving ring... and trying to use those as a starting location for the clearRect.  Careful here.  Possibly, canvas graphics are drawn from bottom-left corner... to upper-right... much like a texture is mapped.  But event.clientX and clientY almost surely start at window top-left. 

If the VJ graphics are not being completely erased... that means one thing.  It's broken.  haha. 

Um... no... it means that something is being scaled.  The joystick rings are not 126x126 and 82x82, or... _joystickPointerStartPos and _joystickPreviousPointerPos... are distorted.  _joystickPointerStartPos/_joystickPreviousPointerPos THINK they know where the joystick rings are located, but they are wrong... for some reason.  *scratch scratch*

All this position converting sucks, eh?  window.innerHeight/Width, canvas.height/width, clientX/Y, and joystick ring1/ring2 center positions and areas around them.  Yikes.  This is the stuff that nightmares are made-of, eh?  Sorry.  I wish I could make it all better, but I think better coders than I will be needed.

[ozRocker]

Thanx @Wingnut!  I went through all the ClearRects I could find and increased the offsets.  That seemed to fix it    I'll have to go through it later to convert to percentages.

[Wingnut]

Bet ya won't.    If you actually decide to convert to percentages-of-canvas-width/height... for this whole system... make sure there is an emergency medical team standing-by, eh?  Man!  And make sure you have food, water, flotation gear, and tents... for TWO WEEKS of camping and whitewater rafting. Maybe for a month.  Rent a generator and consider keeping a dog nearby... cuz it could get lonely.  Take an emergency cell phone with you, and call me once per day!    Once you walk out into that swamp, there's no returning.  But, we can keep @davrous in a helicopter, standing by... propellers spinning. heh

Actually, you might be imagining completely NEW methods of touchscreening, eh?  Do you REALLY need colored rings on an add-on canvas?  No, not really.  Really, what YOU want... is WHERE on-canvas... did touch x/y happen.  Now code YOUR OWN onPointerMove...  to hell with the rings and extra canvas.  You want the "delta" values in the console... you want to see the numbers change. 

Now, let's talk about a different kind of "layer"... the BJS Layer class.  It can be used to put backgrounds into scenes.  What if that background image... changed... depending upon if the user was touch-dragging up/down/left/right, etc?  What if that were 8 pictures of compass flowers... you know, the arrows around compasses. 

But let's not stop our imagination there.  You have values ... delta values... streaming to console as you drag!  Think about the power you have.  How about opening another little viewport in the corner of the screen, and in its camera view or in that renderTargetTexture... is a beautifully modeled chrome joystick... and as you drag upward, the handle of the joystick moves forward... etc etc etc.  How about a robot's head... when you drag-left, his head tips left, etc etc.

 I guess my point is... YOU can separate the "presentation" of the joystick (the gfx)... from the VALUES returned from the drags.  You can re-route that data into any "graphical representation" that you wish.  There's opportunities here.  By ridding yourself of the canvas BS, and using some sprites or abs-positioned html elements, a whole world opens up to you.  Just kiss the rings goodbye, and hello image-swapping and extra viewports and lots of other fun stuff.  The "rings" are really, ONLY, one example method of giving user feedback. 

Goodbye virtual joystick, hello OzRocker CanvasListener v1.0 (with 25 different snap-on navigator widgets!)  yay!

Maybe one thing to keep in mind.  Possibly, hmm... Davrous' VJ's... are similar to analog joysticks, not digital.  Not only do VJ's set forward/backward, etc... but also allow set-and-forget (no change onPointerUp).  Set the throttle at 30% forward... and it might stay there... until the "center the joystick" button is pressed.    The distance between the 2 rings... is pertinent.  It's a "how much".  But maybe a digital joystick is more for you, Oz.  One joystick is forward backward left right (switches) and the OTHER joystick or knob... is throttle (that's where the "how much" amount comes from).  (military tank-like?)

Yeah, like any of us REALLY needed to think about digital vs analog joysticks at THIS point, eh?    Do we enjoy brain strain?

[dbawel]

@Wingnut - I'm glad you don't mix words:

Quote

Bet ya won't.  

I personally had to learn your humor at my expense.

DB

[Wingnut]

You tried it, DB?  (Wingy quickly checks you over... for signs of profuse bleeding, compound fractures, and brain tumors) 

If you did, what did you learn?  Can you talk about it, or is it too emotional for you, yet?    Scary!

Once we THINK we have it done, then we'll set the window to restored condition (mid-sized with the corner drag-to-size active), on a webpage with a 73% wide canvas, and see if she still operates correctly.  Then we'll do some drag-resizing of the window.

Ohh, there's SO MANY things that can screw-up.  (Wingy offers everyone aspirin and moist towelettes.)  heh

Thank goodness "they" don't allow drag-resizing on the corners of the canvas itself.  We'd need a Cray to calc all this, then.

[ozRocker]

I think @Wingnut should write tutorials.  His language reminds me of how they speak on the Ray Wenderlich site, and those are the best tutorials for iPhone ever written (the only online tutorials that I've ever paid for in my life!).  I like how the answers come out more as narratives, instead of tech specs.  Torley Linden, the crazy Asian guy that does the official Second Life video tutorials also has a cool teaching style.  He sounds excited about everything!

[Wingnut]

That's very kind, Oz!  I enjoy watching your creativity... you have good taste and feel.  You've done some real nice things, and it hasn't taken you long.  You're a "natural".

There's one problem with narrative tutorials.  Those who need to translate, and those who struggle with English... prefer that I get to the point much quicker.    So, there's always a trade-off.  Quite often, I like to try to promote a communal "campfire", where experts and freshman get together around an issue.  Around these campfires, freshman get to hear "the big picture" from the BJS experts, and the experts get to "remember" what the framework/community "feels like", from the freshman perspective.

There is a phenomena called "treehouse teaming".  Treehouse Teaming (tt) is where neighborhood dads get together (often with "abandon" - throwing caution to the wind) and build something for their kids/community to share, without bosses, without wages, without rules, and with much enjoyment and job satisfaction.  The moms get together on a team, too, (campfire-up) and make sloppy joes, provide beverages and bandages, and enjoy the "company".   Treehouse Teaming is what causes "Miller Time" at the end of the day, with a fat belly, a cold beer, and a profound sense of self-satisfaction.  A day of TT... beats ANY day of "standard" labor.

Often, or maybe always, it takes one "insanely enthusiastic idiot" to get a treehouse team gathered around a cause.  Mix some crazy over-enthusiasm, with plenty of comedic self-degradation (call yourself an idiot, often, and make fun of yourself)... and that is the "fuse" for a treehouse team.  Plus, the people in this forum... are very kind and tolerant.  They all seem to somewhat like me, or at least somewhat tolerate me, no matter what I say or try. 

So... this is a great place/way for me to learn about forming loose-knit teams, and sometimes these teams work on programming or design issues that are quite important to the author with the problem.  When conditions are right, we "rally around their cause" and this makes the campfire grow brighter.  Under certain conditions, our treehouse teaming can build HUGE bonfires... and the team dances around it with Millers in-hand... toasting to our success, and to our failures.  Both situations... are packed with adventure, experiments, and learning.  Our failures are never really failures.  They are fun food for further contemplation and future campfire discussions.

Ozrocker... YOUR enthusiasm... YOUR fuel... causes these campfire rallies.  You are kind, yet determined.  You have goals, and you're going after them with plenty of spirit.  Some of us... feed on that spirit... and treehouse teams form.  I just try to add to the campfires that YOU start... with your spirit.  What is the saying?  Enthusiasm is contagious?  *nod*  In this forum, we prove that statement true... daily.  We're all a part of it, and it began with a rally around BabylonJS/Deltakosh/CoreTeam.  Not a bad thing to rally-around.  Party on!

[ozRocker]

I can understand people wanting answers to their problems quickly, but with tutorials a bit of storytelling helps.  Well it does for me, 'cos I usually come to tutorials as a complete noob!

Also, thanks for the kind words @Wingnut   I am very enthusiastic, but I'm also desperate.  I'm in so much debt after building this 3D scanner.  I thought people would be knocking down my door to get scanned, throwing money at my feet!  Turns out most people don't even realise you can get a high-def scan down to 1MB and display it on a web-page without plugins.  The general public (tech people included) still think 3D is big, slow, works only on expensive computers and requires plug-ins.   I had one modelling agency tell me that they "don't have enough space to host" the 3D models.  I asked "Really?  You don't have 1MB on your server??"  I'm almost certain one of her tech guys told her "Oh we can't use 3D.  Those files are huge!"  Babylon.js is my chance to show people how easy it is to integrate 3D models into websites.  When I don't have any work coming in I just make demos and post them around social media as a way to educate people.  I'm checking my work e-mail constantly just waiting for that big project...

[Wingnut]

*nod*  Yeah, you are having to chisel-away stale, traditional ways.  Your potential clients have fears and resistance-to-change.  Most of your selling effort... is reassuring them that they won't lose their old ways of doing things.  They still get to keep those.  If they can't keep the old ways nearby, they feel alienated.  I guess that's human nature.  But that causes you to constantly try to get them in the mood for something new, and you probably need to make it look like it is THEIR idea.   What a blockade to surmount!

Yuh, you're going to need a degree in psychology... to blast through THAT wall of reluctance.  Your system almost HAS TO BE an "add-on" and not a replacement for their old ways.  It cannot threaten traditional ways... because folks often "hug" old ways... like familiar teddy bears.  If you (seem to) threaten to take away their teddy bears, they will reject and run.

The other part.... making it look like their idea... that is plenty difficult to accomplish, too.  One of the better ways to do this... is to get a story about your system... published in a trade magazine that is targeted toward that industry.  Generally speaking, YOU don't get to talk directly to them... about your system.  You need a respected "voice of the industry" to speak about your system in Modeling Tech magazine.  If your system can cause an 'envy'... where the modeling agencies YOU are targeting... think that they NEED your system in order to keep-up-with "the other guys" and with "modern trends of their industry", that helps promote "their idea" methods.  Maybe.

Article writers in these modeling trade magazines... sometimes need ideas to write about.  Perhaps, do everything in your power to get these trade magazines to review your system, and write about it.  When your potential clients see your system in their favorite trade magazines, talked about by folks who they have heard talk many times before, then your system will seem less alien to them. 

"Jim, at Modeling World magazine... thinks this system is a good idea.  Maybe it IS what we need."

By having a "familiar" like Jim from Modeling World... mention or talk-about your system, it relieves some of their reluctance and fears...  maybe.  It's endorsed by Jim.  And, of course, the system should have a "cute" name... which can also help remove the fear of change.  I think you will need to invent about 100 different ways of presenting your new system to potential clients, and you'll need to try them all.  Later, you might be able to determine which methods of presenting your system.... work best with which type of psychological landscape (what type of person/company policy).  Psychology.  Sales is a surprisingly complicated activity, especially when the thing you are trying to sell... seems like a big change.

Possibly, put your system into the hands of other sales people who already sell things to modeling agencies, and write-up a commissions contract for them.  Maybe try it with one sales person, first.  Or perhaps, just show your system to one of these sales folk, and ask "How would YOU sell this?" and see if you can get them to talk.  The same psychology applies as before, but in this case... someone besides you... is peddling your system.  Someone other than the system's inventor... is highly enthusiastic over it.  And this third-party enthusiasm is coming from someone who the industry is familiar-with, because they have sold other things to that industry.  A familiar face (to the client) is excited about this system... so... "maybe it IS good and ok... considering Jim likes it".

These things will apply to many webGL apps and their authors.  WebGL is new, and scary, at a time when stockholder dividends are strained (when aren't they?).  I don't know how much of an "industry expert" you currently are, but, you might seem like an alien entity to them.  Possibly, your target should be sales folk who regularly sell things to that group, or write articles about that industry.  I don't guarantee that this will work... but it's a different approach vector... one with a splash of sales psychology.

I don't have much to offer, eh?  Hell, I'm still trying to get my mother to lose her fear of web browsers... so I'm no expert (or even any-what proficient) at these things.  I'm anti-capitalism, so I'm the LAST person anyone wants on their sales team.  hehe. 

I hope it all works out for ya.  I think it will, but it sucks when "work out" is under time pressure.  Could you use a couple mil for product packaging, launch/IPO party, and huge media buy?  I'm sure I have a couple million laying around that you could use for a while.  (yeeeeah) 

@dbawel Did you try the all-percentages VJ?  The suspense is driving me bananas!  I guess what I really should ask is... "Are you still alive?" 

(It killed him, I bet.  He tried to make a completely scalable canvas-tracking virtual joystick, and IT KILLED HIM!  OH NO!)  hah

[Wingnut]

Hi Davrous and everyone.  Davrous is now visiting this thread, so this is mostly for him.  (He's a VJ pro)

You have heard the issues from users.  Users have problems clicking-on HTML elements, and problems picking mesh... when the vjcanvas is covering the entire screen (likely because VJcanvas uses window.innerHeight/Width).

For example, when a user has a renderCanvas that is 50% of screen width/height, centered, and wants to use a VJ, they must work very hard to resize and re-position the vjcanvas atop the render canvas area ONLY.  resizeToCover(vjcanvas, rendercanvas) 

Also, please add id to vjcanvas, so we can get a ref easier, to manipulate its size and placement (and destroy it easily, as needed, when we vjRingOut of renderCanvas).  Good feature.

======= [end reading here, as wanted] ======= 

This is why resizeToCover sounds good.  Resize VJcanvas to perfectly cover render canvas.  @DezOnlyOne would like to go further, and allow resize-to-cover ONLY bottom 1/4 of render canvas, so users can still pick mesh on the upper section of the render canvas. 

Perhaps Dez wants lower 1/4 of screen.  Not sure.  And, he didn't state "1/4".  I use as example. 

So, lower 1/4 of screen, or lower 1/4 of render canvas, BOTH could be options, ideally.  Good feature.

I tried to "derive" better size/placement of the vjcanvas... via measuring size/placement of the render canvas.  I failed, so I simply set VJcanvas with identical CSS as render canvas.  A "smart" vjcanvas could automatically "cover render canvas area only"... derived.  DBawel might have tried a hack, too, but we haven't heard from him since.    The above thread... is an entire adventure about VJ's... a delicious campfire novel that will take months for a Frenchy to read.  heh.  Good stuff... good story... great character interactions.  But we lost DBawel.  He might be stuck inside a VJ. 

Also, Dav, let user override which HTML element in document... the vjcanvas will be appended-onto.  *shrug*  please?  Good feature. heh

If you are going re-coding, you should consider a DIGITAL VJ as well.  Instead of traveling rings, it would use 4-way rocker switches, thereby needing far-less screen-area to operate-within.  Difficult feature... no delta values in rocker switches... just on/off.

Sorry that this required more sentences than you wished, but I want to be clear.  Mis-communication happens often here in the forum.  Thanks for your concerns, thoughts, and ideas.  Some playing done here .  (20 secs of VJ, then turns off, with entire vj code hijacked into the pg editor, for hacking-on)

[DezOnlyOne]

Thanks @Wingnut! 

This is exactly right. I have been able to use the click through to html by doing something like this:

$(window).mouseup(getPick);

Instead of:

scene.onPointerUp = getPick;

with the VJC I can click through with the $(window) mouseup, because it works with the VJC and fires the getPick, but then another problem arises where I have layered html content on top of the canvas but under the VJC layer that I cannot interact with. I think this actually would not be that difficult to fix if I can arrange how the content is layered, but I want to only have clicks in most of the viewable area and the controls at the bottom of the screen. 

This demo uses static images at the bottom that appear where I would like them to. If the canvas was just in this area, I could use the rest of the screen above it for user interaction. 

http://babylonplayground.azurewebsites.net/babyoncharacterwalk/

Thanks in advance