solved Zoom to cursor position

[Arte]

Hi All,

I am trying to achieve camera zoom (mouse wheel) to cursor position, but no luck 

http://www.babylonjs-playground.com/#PVE71R

Any suggestions

[Wingnut]

Oh, Arte, I didn't even see this post.  I don't like letting 0-reply posts get this old.    Sorry.

Yeah, what you're trying... is actually working fine.  But... it's all about that stuff ya smoked before coding this.  (just kidding, of course).

https://www.babylonjs-playground.com/#PVE71R#3

I hope you wanted to click-first, and THEN mousewheel in/out, right?

Or are you wanting to determine where pointer is located in screen x/y position?

This has always been a troublesome area of perspective geometry (like I know what that is).  Screen-space, world-space, difficult to wrangle, mentally.

This newest playground doesn't do any mousewheel crap, but it uses some pieces and parts from the playground drag-and-drop demo... to determine "Where on the ground did the click just happen?"

Then I just move camera.target to there... and mousewheel operates normally without any need for special processing.

But maybe... you want... "Zoom to position upon ground where target would be IF I clicked here."   (more hovering, no clicking).  Essentially, the camera target would get glued to the pointer... whenever teh mouse is hovering ground?  Yep... bet that's what ya want.  I have NO IDEA how to do that. 

https://www.babylonjs-playground.com/#PVE71R#6

Okay, that's just bad.  Lots of stolen code from the drag and drop demo.  Red box camera target TRIES to follow pointer-tip, but no.  Instead... mostly chaos. 

But, mousewheel still works correctly... to zoom-into the camera target, no matter WHERE our out-of-control onPointerMove has positioned it.. 

getGroundPosition() runs continuously when mousing-over ground.  It returns current to onPointerMove, and to console (line 83).

In lines 86 and 87, I tried some /4 movement "tamers"... trying to get things calmed-down.  They shouldn't be needed at all.

This thing needs some serious repairs. 

[Arte]

Wing...

I think I found a solution 

https://www.babylonjs-playground.com/#PVE71R#7

Thank you for pointing me out.

[dbawel]

Hello @Arte,

I'm glad that we've got @Wingnut to keep us on our toes assisting when we can. His solution works, however, it tends to get messy - and a real issue when you're not mouseDown on a mesh. Consider using evt.clientX and evt.clientY (evt is simply your mouse event) to avoid conditional issues in your scene:

function get_mouse_position(e){
    posx = e.clientX;
    posy = e.clientY;
}

From my personal experience, I can control most any operation much better by using the mouse X,Y positions from the canvas. Hey Wingman, I just pitched 1,000 on the forum. I remember the day when you broke your cherry on this site.

DB

[Arte]

Hi @dbawel

You method is not working for me. I need ground position to start zoom, not client XY.

Congrats on 1000! 

[Wingnut]

Hi guys!  DB... good to see you.  Personally, I said goodbye to client XY when scene.pointerX/pointerY was added.  Otherwise, we need to do some calculating for non-fullscreen canvases.

But I think scene.pointerX and scene.pointerY would still have issues in a multi-viewport scene.  Perhaps the viewport class should have a .pointerX and .pointerY.  *shrug*

Anyway, yeah, getGroundPosition()... so Arte can set his camera target there. 

Arte, to be frank, I couldn't  get #PVE71R#7 to do very much at all, but I could be driving it wrong.

Speaking of viewports, I suppose quite a few users... use a "mini-map" in a small viewport in the corner of the scene... with a view from an overhead camera.  They do their target-choosing from that mini-map.  *shrug*

I don't QUITE understand what Arte wants, other than knowing he wants to move the camera.target based upon something.  He's doing some inventing, here.  I'm just throwing some dangerous tools at him, so when the scene explodes... we get nice fire-colors and plenty of shrapnel.    It's all part of the fun of demented inventions. 

[Arte]

When i'm playing around i'm learning more 

In my project 'Parametric cabinets' I'm using zoom instead of pan.

#PVE71R#7 suits all my needs 

[Wingnut]

ahhhh, you are using IE or Chrome or Opera or Amaya or something.  I booted into IE, and now I can see what's happening.

In my Firefox, onPointerWheel is never called.  uh oh.  THAT'S why I am experiencing no sugar-frosted goodness... in the #7 PG.   hmm.

We got trouble (we got trouble)... right here in River City (right here in River City).  And that starts with a "T" and that rhymes with "P" and that stands for Polyfill.  errr...  hmm.

[Arte]

Honestly I did not try on firefox. Hmmmm 

@Wingnut Good catch ! Thankyou. 

[Wingnut]

Remember that big fat code-chunk that's nopped-out in https://www.babylonjs-playground.com/#PVE71R#3

Lines 65-130.  I got that from somewhere on the web.  When I saw all that code-fuss... I knew there was a storm on the horizon.    Lots of browser checking in that wench.

I don't know if I'm qualified to help with a better solution, but there's Gods nearby.  And you might have some good ideas too, Arte.  Show/tell all discoveries, of course.  (thx)

[Arte]

'I don't know if I'm qualified to help with a better solution'     Yes you do!!! 

I will study it later

[Wingnut]

What, are ya goin' to bed already?  pffft.  Work?  Skip it.

What we you need... is something from Mister Scene Class.  He has no onWheel observer... and that is just a crying shame.

But, while I was wandering around in Scene Class... I saw that .hoverCursor... and .meshUnderPointer.  hmm.  Might be useful (something in their framework code) for improving getGroundPosition  (keeping it from needing to run for EVERY onPointerMove, perhaps).

Not sure.  You seem to concentrate rather highly upon using a wheel-move... to trigger "Start pointerTargetCam mode".   But but but... won't this thinking... ruin arcCam default zooming?  User will be examining an object... then the dog gets in a fight.  Then, while user is AFK, the mouse cord weight pulls the mouse pointer down to screen-bottom.

Then user returns, and spins the wheel, thinking they're zooming-in onto current targeted mesh.  But suddenly, Arte's mousewheel trigger activates, and backs-out the camera target all the way to Zanzibar.

Just... thinkin'.  Me... I would position a crosshair/reticle (decal?) around on the ground... while scene.meshUnderPointer = ground.  Then... perhaps if user RIGHT-clicks... that's when the invisibleMesh.position camera.target... uses my cool moveTo animator... to animate camera.targetMesh to decal x-z position.  Niiiiiiiice.  *shrug* 

No mousewheel listeners/handlers needed at all.  Mousewheel always uses standard arcCam mousewheel  (if that would work).

[Arte]

Work?  Skip it. *shrug*  

[Wingnut]

Time for a 5-week side-project... to code-up the typescript... to contribute Babylon.Scene.MouseWheelObserver()  ?  Got nads?    Scary, eh?  I hear ya.  But maybe we would become local heroes or something.

[Arte]

I still have a long way to go, to become a hero.

[dbawel]

Hi @Arte -

I know it appears to be a potential solution. However, I think you'll like using the HTML canvas better. There is a bit more calculation for you, but this opens up a world of possibilities. One common method is to apply the same math used on your Xbox and other controllers applied to the HTML canvas as found on the following topic:

However, I'll re-post just the following to so you don't have to sift through many posts to find it:

Quote

 

Ok.  I have doubters that this math works 100% of the time or controllers (Iceman, love ya!), but I thought I'd post this as I've seen this question asked many times.  The question as how do you steer a ship on the screen - or use any controller to direct vectors?  Roughly stated.  Here is the my reply..

 

If you register the pick point on the canvas, the math is easy.  Let's ASSUME you have a canvas of 1024X1024 and clicking in the center of the canvas returns a value of (0,0) on our pick point of canvas (x,y).  I know this isn't the case with HTML, but this is simply an example - primarily for using any external controller. Using conditional statements:

 

 

if (x > 512) {

    a = ((x - 512) / 5.12));

}  else  {

    a = 0;

}

 

 

if (x < 512) {

    b = -((x - 512) / 5.12));

}  else  {

    b = 0;

}

 

 

if (y > 512) {

    c = ((y - 512) / 5.12));

}  else  {

    c = 0;

}

 

 

if (y < 512) {

    b = -((y - 512) / 5.12));

}  else  {

    b = 0;

}

 

 

If you look at the math for each of these variables a, b, c, d then you have a value of 0 to 100 for each variable.

Then you'll want to average these so that you can direct your ship in a blended direction, and not simply as an additive.

 

This math is:

 

var Blend = (a + b + c + d)

 

if (Blend > 100) {

    BlendDivide = ((a + b + c + d)/100)

}  else  {

    BlendDivide = 1.0   {

}

 

var dir1 = (a / BlendDivide)

var dir2 = (b / BlendDivide)

var dir3 = (c / BlendDivide)

var dir4 = (d / BlendDivide)

 

And you now have a blended direction for each (x,y) vector from a value of 0.0 in the center of your canvas for whatever the pick point is.  This will give you perfect control in whatever direction the user wants to steer.  If you want your (x,y) center to be in a different position on the canvas or more force in any direction, just change the math.

 

You can also use a Triginometry function, but this math is much simpler and easy to add more controls to the blend.

 

 

 

This requires knowing the canvas size and is a simple example of how to built your own virtual controller. This doesn't specifically apply to your question, but hopefully will provide enough info for your specific needs. This is to show how you might approach generating a (0,0) value for the x and y position anywhere on the canvas, and this is also the same math we use for complex control systems such as puppeteering controllers for film.

 

There is a really great post I found outlining the various versions of this, and some real world examples and explanations. It's very interesting, as some approaches are quite clever.

https://stackoverflow.com/questions/16919601/html5-canvas-camera-viewport-how-to-actally-do-it

 

DB

 

[Wingnut]

Nice.  That's for determining "direction", right DB?  Direction to move player... so they arrive at the location of the pointer/pick.

If someone wanted to move a painted-on-the-ground crosshairs/reticle (via hovered pointer)... none of that is important, correct? 

DB, I bet you thought that the crosshairs/reticle was vertical... to indicate a direction of player movement.  That blending stuff... makes a perfect sync between where target was aimed, and where player actually goes, eh?  (This is kind of deep for simple folks like me, but I bet Arte is "on it".) 

Spaces.  Yuh, yuh, yuh.  (Wingnut burns a 9th grade Algebra textbook in effigy.)

 But yeah, in Arte's case, and pretending that he decided to use the on-the-ground pointer-tracking cross-hairs, he'll be moving camera.target to decal.position, because the decal was essentially glued to the end of the pointer when mousing over ground.  (using getGroundPosition() from PG drag'n'drop demo). 

Note: Decals are a poor choice for moving-around... IF the ground/surface is not flat.  ie. Rolling terrain.  Decals are "depth-shaped" at the time they are created, but that shape will not conform to new terrain/mesh contours... if moved.  The latest rumor says that the best way to move a decal over bumpy terrain/mesh... is to dispose old decal and create new one... onPointerMove.  Demented, eh?  *nod*   That's about what?  1000-5000 decal creations/disposals per slow pointer-swipe across entire width of terrain?  Ow!

Of course, it doesn't need to be a decal moving around on the ground.  It could be a "gizmo-widget".    Let's see... what is the #1 camera target on the planet, currently?   Sunsets/landscapes, I suppose.  Not the kind of thing to move around on the ground... for a "target THIS with cam" (on-right-click?).

So, #2 most popular... probably nipples.  Arte's Camera Target Nipple.  Yeah. I like it.  Nasty puffy pink thing... perhaps with a couple of hairs sticking out of it... YUM!  Shoot a little particle fountain from the top?  NippleObserver/Observable.  heh, ahem, phew.  Moving right along...   

Thx DB... nicely explained.

[dbawel]

Hey @Wingnut-

To paint a target is certainly what he's already doing. I just like using the HTML canvas, as often I'm working out of WebGL and in JS and PHP (thanks to @Pryme8.) But the link that I sent is rich with examples, and in my opinion, everyone should know as much as possible about natively working in HTML. With JS frameworks, you otherwise might never know when the framework is simply using HTML functions adding another layer onto the complexity of your code.

DB

[Arte]

Thanks guys 

DB I will try your suggestion and then I'll decide what's best for my project 

[Wingnut]

10 hours ago, dbawel said:

I just like using the HTML canvas,

I think you mean a context2D canvas, right?  (versus a webGL/3D context canvas).  I think they are all HTML-based, at some layer.

But yeah... virtual joysticks (their graphics) uses/used an "extra" context2d canvas.   Babylon GUI full-screen-mode might use one, too.  Maybe.  hmm.

Scene.pointerX and .pointerY... is returning context2d (HTML) coordinates ALREADY, yes?  Why would anyone want to add (another) canvas atop the render canvas?  Doesn't THAT make the scene more complex? 

I know the virtual joystick canvas uses/used browser window.innerHeight and .innerWidth as it's size, so when it turned-on and accidentally stayed-on, you couldn't focus the PG editor or use any PG GUI buttons... without first using the document inspector to delete that add-on context2d canvas.  It sucked, but mostly because it didn't match 3D canvas size.  And that "virtualCanvas" didn't have a class or id either, so HTML getByClass or getByID... were/are both impossible.

I'm still confused, but I guess that is normal.  (sorry)  Anyway, it's not about me, it's about Arte's thing.

I wish I had your brain and comprehension, DB.  Gimme 10 more years... I'll catch up, I promise. 

[Arte]

It's getting hot up here 

I better stay neutral. 

[Wingnut]

DB is a bit famous, Arte.  He gets to dance with Hollywood girls, sometimes.  Even though he's way smarter than I (so I barely understand what he teaches us)... there's no doubt that he has his technology ducks in a row.  I also think he's nicer than most other Califolk, but I don't have statistics to back that up.  

I like him most... because he has unique and interesting "approach vectors" to everything.  He's... different.  I wish I could have been standing next to him... during all the things he's worked-on and worked-with.  But, to get onto DBawel's mental frequencies, we need to tune between approved channels.   

Pryme8 is another one like that.  NasimiAsl, too... he has shader-brain.  Jerome - vertices-brain.  Geniuses, all.  They see (or maybe feel) things that others can't. 

I think these guys are somewhat polyhedrally-psychic.  heh.  I learn tons from all of 'em, but I can't remember it the next day. 

But, yeah, DB is a superstar... and I'm pretty glad he's willing to teach us things (even if some of it IS over-our-heads to a degree).

DB and I have gently bumped heads at times... but we always laugh after we do it.    I usually win the head-butt, physically, because I'm fat-headed.  Intellectually, he cracks my skull open and my brains fall-out... if I'm not fast with the gaffer's tape.    Roger Rabbit, Rocky & Bullwinkle movie, all those "real actor interacting with 3D character" things... are done with knowledge of "spaces" like DB understands, and it has a HUGE future.

[Arte]

Person not having his own opinion - 'Not a person'

We all have advantages and disadvantages. 

Team power is a key to SUCCESS! 

[Pryme8]

5 hours ago, Wingnut said:

Scene.pointerX and .pointerY... is returning context2d (HTML) coordinates ALREADY, yes?  Why would anyone want to add (another) canvas atop the render canvas?  Doesn't THAT make the scene more complex? 

Depends, there are situations where it could be advantageous. I've done it in the past with canvas and divs.  Usually has to do with hijacking events and normalizing input for some particular reason.

[dbawel]

@Wingnut-

 If I were the "superstar" you make me out to be, then I might actually believe my own BS. At the very least, I've been fortunate in my career - only since I was early into 3D and 2D media development - when there were very few people in the game at all. Thus I had the opportunity to be a part of a pioneering graphics industry; and offered a role in creating many classic projects and productions. For me it was "right place, right time." So I'm never happy when I hear you down play your contributions and understanding of so many various approaches to questions on this forum. There's so much I've learned from your due diligence, as well as so many other talented developers on this forum. And I must say that I truly got schooled by @Pryme8 as I've had the opportunity to work with him on a paid project, and have also been assisted by others on this forum when I was stuck on issues I've never been exposed to previously.  So I appreciate the props given to me, however, it truly troubles me when I hear you ignore your personal tenacity to understand practically every aspect of the WebGL framework... and your willingness to assist anyone at any level in trying to solve issues which for many are highly conceptual in any time. So I hope you know the respect you are due in helping others when they are stuck on any given problem they need to solve in BJS. You always put yourself out there, and treat everyone equally regardless of their experience level or skill set.

There are few people on this forum who give their time to anyone to help resolve the most remedial question to the extremely high concept approaches in the WebGL framework and Javascript languages. And I've never seen you step away from the most difficult issues asked by the most seasoned developers on this forum. So please know that everyone here appreciates the immense amount of time and effort you give to everyone who has an issue they need to solve - regardless of the complexity. You've pointed me in the right direction so many times that I owe you a high degree of respect for always taking any question and exploring potential solutions with the developer posting the question; regardless of whether you are familiar with the issue or not at the time.

And @Arte... you appear to have the perfect motivation for helping others, as we all know that we have limitations in our personal experience as developers. Again, I'll mention @Pryme8 since he is as close to genius as anyone I've met in my life as a developer. And I mention this as we all think ourselves "smart", however there's something to learn from everyone - regardless of their level of proficiency in any given area - as I find that everyone has another area of expertise in which they can draw from.

But back to the "zoom to cursor" question... @Arte - is your questioned answered? If not, please let all of us know, as I'm certain that if you require additional information, then an example can be provided by someone on this forum specific to your query. So if you don't have the solution you need already integrated in your scene, please let this forum know and I'm certain you'll get it now. Just let us know what might be missing from your scene which doesn't provide the specific behaviors you need to control your camera.

 

Cheers,

DB

And @Wingnut - this pics for you... my buddy Hugo. Not to mention my "hot" girlfriend (at the time) Rachael from Malta. Agent Smith, anyone?