Camera rotate to the nearest destination

[yzthr]

Hi guys!

I find a problem that i can't make the arcrotateccamera rotate to the nearest 'destination'.

here is the PlayGround.

https://www.babylonjs-playground.com/#RVZ1O#2

Rotate several circles around the center, then click the purple button. You will find meshes rotate back quickly to the original position before rotation. 

I want the purple button rotate to the position which camera.alpha=0 or PI but not rotate to the original position(for instance, the button just rotate a angle about -PI/2).

[yzthr]

I find camera.alpha goes larger when i rotate the scene clockwise. If camera.alpha=0 or 2*Pi or ...2n*Pi, the scene will look the same.  

So i consider to calculate the (2n*Pi)  so that the camera will not rotate too much circles.

Here is the formula: 

camera.alpha-(camera.alpha)%(2*Math.PI);

 

I change the code (line 105) as below:

 

sphere.actionManager.registerAction(new BABYLON.InterpolateValueAction(BABYLON.ActionManager.OnLeftPickTrigger, camera, "alpha", (Math.PI+camera.alpha-(camera.alpha)%(2*Math.PI)), 500, condition2));

 

but the camera rotate back to the original position as usual.

 

new Pg:

 

 

[Wingnut]

Hi Y!

  https://www.babylonjs-playground.com/#RVZ1O#5

I'm doing some experiments in lines 156, 165, 166.

Not sure how well I do.    Still goofing around with it.

Ignore the alpha variable in lines 158-163, of course.  Not used for OUR issue. 

[yzthr]

Thank you, Wingnut!

your experiments can solve the problem partly, but sometimes the camera also rotate abnormal(when cam_initial_alpha larger than 2Pi), it rotates an angle larger than Pi to go back to the original position.

And i think it will be better to put the code that calculates cam_initial_alpha into the leftpicktrigger action. (code in BeforeRender will effect the performance)

BTW: I don't know why the codes don't work.

"sphere.actionManager.registerAction(new BABYLON.InterpolateValueAction(BABYLON.ActionManager.OnLeftPickTrigger, camera, "alpha", (Math.PI+camera.alpha-(camera.alpha)%(2*Math.PI)), 500, condition2));"

 

[Sebavan]

The part in the parenthesis is not a callback so it will be computed only once :  (Math.PI+camera.alpha-(camera.alpha)%(2*Math.PI)), 500, condition2)

To do this you might need to use a ExecuteCodeAction instead so you could then compute it all in a callback.

[yzthr]

Hi Sebavan!

I make a experiment to make sure that it is not the problem with the parenthesis. I use a ExecuteCodeAction before InterpolateValueAction.(add codes from L105-133)

Here is the new PG and the camera also rotate incorrectly.

And I think that there is nothing wrong with the parenthesis and there is no need to use a callback. Because when u click the button, it will calculate a new 'alpha'.

[Wingnut]

Hi yzthr (and @Sebavan too)

   Ummm... I remembered a PG... that I bookmarked... about... shortest rotation to some point.

https://www.babylonjs-playground.com/#CZRC0#2

Right click on grass.  Might be something worth looking-at.  I believe that PG was created by BJS super-hero @aWeirdo

@iiceman also did some stuff... rotating a space fighter to aim at a clicked point in space.  He also used a "shortest angular-distance to get there" Al Gore rhythm, I believe.  I think there's another big thread somewhere on forum... about "shortest angular distance to rotate".  It was talked-about and experimented-over... for quite a few weeks, if I remember right.    Anyway, here's Iceman's space thingy:

http://p215008.mittwaldserver.info/space/

I can't find the playground for that one, but, there's one nearby.  Code stealing is ALWAYS available. 

It seems we need an easier/better tool for camera.setDirection(anything), eh?  *nod*  Basic Astrology util... originally for aiming telescopes.   

Essentially, camera.lookAt({position: anyPosition} or {direction: anyDirection}).  Coool.  Or maybe it's camera.animateTo().  Nah, that doesn't feel right.

With a camera.lookAt()... IF the param is a direction, we allow the optional scale: parameter.  If scaler exists (let's pretend scale = 3)... then we set the direction of the cam... AND we automatically position camera.target... along direction-Axis  away-from camera... at magnitude 3 distance from cam.  WOW!!! 

What a dumb Wingnut idea!  heh.

Aiming things... is one of the most miserable things to learn... in geometry/webGL, in my opinion. 

Okay, maybe materials are worse, but... aiming things... easy for a 3 year old with a flash light...  not so easy for adults with a universal cam.  That's why I once built the amazing setDirectionToTarget() core-func for aim-able lights.  It made me SO famous that I had to change my phone number and residence.  Too many girls wanting to touch me and marry me and stuff.    (yeeeah)

Aimless.    I make pretty good air-cooled racing arrows, but I sure don't understand what makes them aim-at things.    Not pointless, but aimless.

[yzthr]

On 12/2/2018 at 12:46 AM, Wingnut said:

Hi yzthr (and @Sebavan too)

   Ummm... I remembered a PG... that I bookmarked... about... shortest rotation to some point.

https://www.babylonjs-playground.com/#CZRC0#2

Right click on grass.  Might be something worth looking-at.  I believe that PG was created by BJS super-hero @aWeirdo

@iiceman also did some stuff... rotating a space fighter to aim at a clicked point in space.  He also used a "shortest angular-distance to get there" Al Gore rhythm, I believe.  I think there's another big thread somewhere on forum... about "shortest angular distance to rotate".  It was talked-about and experimented-over... for quite a few weeks, if I remember right.    Anyway, here's Iceman's space thingy:

http://p215008.mittwaldserver.info/space/

I can't find the playground for that one, but, there's one nearby.  Code stealing is ALWAYS available. 

It seems we need an easier/better tool for camera.setDirection(anything), eh?  *nod*  Basic Astrology util... originally for aiming telescopes.   

Essentially, camera.lookAt({position: anyPosition} or {direction: anyDirection}).  Coool.  Or maybe it's camera.animateTo().  Nah, that doesn't feel right.

With a camera.lookAt()... IF the param is a direction, we allow the optional scale: parameter.  If scaler exists (let's pretend scale = 3)... then we set the direction of the cam... AND we automatically position camera.target... along direction-Axis  away-from camera... at magnitude 3 distance from cam.  WOW!!! 

What a dumb Wingnut idea!  heh.

Aiming things... is one of the most miserable things to learn... in geometry/webGL, in my opinion. 

Okay, maybe materials are worse, but... aiming things... easy for a 3 year old with a flash light...  not so easy for adults with a universal cam.  That's why I once built the amazing setDirectionToTarget() core-func for aim-able lights.  It made me SO famous that I had to change my phone number and residence.  Too many girls wanting to touch me and marry me and stuff.    (yeeeah)

Aimless.    I make pretty good air-cooled racing arrows, but I sure don't understand what makes them aim-at things.    Not pointless, but aimless.

Thank u very much, Wingnut!

The space demo is brilliant. The above two demos both use mesh.rotation.x/y/z property. But I wanna rotate the camera instead of rotation of meshes because my scene is so big which contains a lot of different meshes(or if i change another scene by import, i will rewrite some code). Otherwise i will rotate so many meshes all together(so much matrix calculation will cost a lot of time(in 3D especially)). It seems that mesh.rotation ranges from 0 to 2PI or -Pi to Pi, but camera.alpha ranges from positive infinite to negative infinite?

I am totally agree that your camera.lookAt({position: anyPosition} or {direction: anyDirection},duration) is needed. It is necessary.(Haha)

I think it's possible to use actionManager to solve roatation problem. When i use a ExecuteCodeAction before InterpolateValueAction, it seems that InterpolateValueAction statement execute before the ExecuteCodeAction. Then i make an experiment to use combineAction, and the execution is in the same order. Is there any posible way to make sure that the actions execute in the correct order or is it possible to pass return result to InterpolateValueAction statement?

Thank you again for your reply.

[Wingnut]

Hi Y!  I don't have any answers to your executeCodeAction/interpolateValueAction... order-of-execution question, sorry.  I never studied combineAction or "then" features for actions, so I'm learning WITH you, on that stuff.    If I said that you can trigger a interpolateValueAction... from within an executeCodeAction function, would that help anything?  I think there's some posts on the forum about manually-causing AM actions... on demand... anytime/anywhere you wish.

Meantime, I built yet another playground.

https://www.babylonjs-playground.com/#RVZ1O#10

Just a circle of mesh with AM's on them... all execute the same func upon click.  Cam is in the center (elevated 15 units), but feel free to pan/tilt/mousewheel cam to anywhere.

All this does... is use line 27 onBoxClick()... to move the nearly-invisible targbox... from one mesh location to another.  It uses the moveTo() in lines 1-5 for the eased animation.

Line 70 in the render loop... needs to remain active.

*sigh*  I dunno.  Are we getting any closer to success?  I think I need "the objective" redefined.  What is it that we're trying to do, again?  I forget. 

Note:  It appears that camera.lockedTarget... actually changes the POSITION of the camera... when the .lockedTarget mesh... changes position (and maybe even same for rotation).  I don't think that's good/right.  That's the same as parenting the camera to the .lockedTarget.... which isn't the desired goal/functionality.   hmm.  I'm not sure .lockedTarget is useful at all, in its current state.  Needs core-modding, I think.  Line 70 avoids having to use .lockedTarget, and probably doesn't use many more CPU cycles than .lockedTarget internal-processing... uses.

Extra:  In PG #11, I put a few more things in the renderLoop.  Some camera.radius limiters.  Although mousewheel ALWAYS works fine after a .targbox move... I wanted to see what "automatic mousewheel adjusting" would act-like.  Mostly, helpful for clicking on a mesh that is far away, or very near.

[yzthr]

Hi, Wingnut! So nice of you!

Your PG inspired me. You use animation to your box in PG. So i think it will be possible to use animation in my camera. I find a topic about ArcRotateCamera animation, it's very useful.

As to the problem of smallest angle to rotate, we can determine whether the rotation angle larger that PI(L105-125). Then  i use the function in ExecuteCodeAction and it works.

Here is my new Playground. may be it will help somebody.

And I think that camera.lockedTarget act incorrectly. It acts like camera.setTarget but not "locked to" mesh.