Hi guys,
is there a workaround for the shifting axis at the point of beta = 0 or beta = PI? This happens for me in case i define a camera where the upper and lower limit of beta is not defined. In the following example the camera movement shifts at rotating around the Y-Axis. How can i deal with this so that the camera always follows the cursor?
Thanks for your help!
Bernhard
Hi @Bernhard and welcome to the forum !
I am having trouble to fully understand the question. Maybe @JohnK or @Wingnut have some amazing tricks in their sleeves for you 
I thought my english would improve but I am still lost in translation after this time
I’m wondering he’s asking about the 0.1 offset applied at either of those values to avoid a race condition. If so, don’t believe there’s a workaround.
“Setting beta to 0 or PI can, for technical reasons, cause problems and in this situation beta is offset by 0.1 radians (about 0.6 degrees).”
https://doc.babylonjs.com/babylon101/cameras
Welcome Bernhard, and hi to others, too.
Sebavan: “lost in translation” (hey, that’s what the camera/axis is doing, too! haha)
The camera “flip-over” at the poles… is not easy to describe, NOR easy to understand someone’s description. When I first “dealt-with” arc-cam polar issues, and whined to DK about it… he thought I was speaking Swahili. 
(it was back before I knew what an UP-vector was) (I still don’t) 
We should give this common arc-cam issue… a “cute” name… perhaps “polar bearing”. When standing on the north pole, ALL compass directions are south. (err something like that). Thus we need an epsilon… something to prevent the pivot on the compass needle… from sitting perfectly atop the north or south poles. (phew)
Needless to say, I’m no expert at arcCamera “trouble at the poles”, but… there are 2 or 3 “polar behavior properties” on ArcCam class… https://www.babylonjs-playground.com/#ESNNAN#2 - lines 21-23.
No promises… but maybe there’s something useful, there.
Yeah, that’s involved, for sure. yep, yep, yep. Some people call that “micro value”… an “Epsilon”. https://github.com/BabylonJS/Babylon.js/blob/master/src/Maths/math.constants.ts (line 15)
“race condition”? I like that term (but not racing - Wingy not a competer). Is race condition… the same as a divide-by-zero condition? shrug. Maybe they are relatives.
All in all… yeah… there’s interesting things that happen at the poles of an arc-cam “orbit”, and some work-arounds are active and perhaps adjustable. Polar bearings. 
Loooks more and more like the issue is about gimbal lock if you want to look it up and unfortunately besides @Wingnut answer, I am not seeing a lot of possibilities here.
Hi @Bernhard and welcome from me. As @Wingnut described there are problems at the poles. (It is to do with a division by sin(angle) which is 0 at angle = 0 and PI)
If you particularly wanted an ariel view in your project as in https://www.babylonjs-playground.com/#ESNNAN#4 then you could change you point of view by rotating the ground and camera direction by pi/ 2 changing vertical to horizontal as in https://www.babylonjs-playground.com/#ESNNAN#5
You will have to remember axis directions have changed.
@JohnK you are my hero
Hi guys! Thanks for this incredible response and special thanks to @JohnK for this smooth and easy solution. I think it would be be its worth to put this solution into documentation close to the point of the pole issue.
https://doc.babylonjs.com/babylon101/cameras#arc-rotate-camera