Hi community. We love the ArcRotateCamera in our project, but often the users look ‘down’ on our models and this is, where it gets difficult.
When you look at this:
Now, start to rotate the scene with small mouse movements and the rotation very often gets weird and changes direction as long as we keep on looking down.
What would be a good way to improve this experience? Do I have to write a new camera or are these simply the mathematical limits of this camera type?
I think you need to avoid Math.PI to target with the camera. I sort of remember something around this.
I suppose a tiny-offset on the cam position and target should make things better (if I understand your problem correctly)
Edit: yes, just found it. There it is in the doc
Setting
betato 0 or PI can, for technical reasons, cause problems, so in this situation,betais offset by 0.1 radians (about 0.6 degrees).
I assume you mean the flip in rotation when crossing the horizon line to keep the camera rotation in the direction of the mouse?
This is how the camera is implemented and is by design. It might be a little “odd” when you rotate in both (pointer) axes, i agree.
Instead of implementing a new camera, you can implement a new ArcRotateCameraPointersInput that will work as you expect it to. @PolygonalSun just extended the great article about it for the docs: Customizing Camera Inputs | Babylon.js Documentation (babylonjs.com)
exactly, the users are not happy with the flip in rotation.
Oh, nice. 
Didn’t see this one. Thx and have a great day 
So, you suggest to control the values given to the beta property and avoid 0 in a new ArcRotateCameraPointersInput?
My suggestion is to change the implementation of the onTouch function to take the camera’s beta into account when changing the alpha. So if you are flipped, also flip the value that is added to the alpha offset.
Ok, thanks. I will try that.
Apologies. A delay in saving. Edited to:
Edit: With that said, I would still recom the above solution on pointers…despite the (little) additional effort 
You commented out the beta limits, but we need to set them to null.
So, I have to go with the pointers. Thanks.
I commented only for testing. You can reinstate them and then, you can also lower the values of offset to make it more of a top-down view… but then, as I said, I believe the change on pointer is still cleaner for a fix. Your choice 
Edit: Did you say ‘null’, didn’t realize that sorry. What does this stand for?
Thinking about it a little more - you don’t want to always switch when flipped, just when you are flipping DURING a movement. So you shoud:
That’s roughly what I would first try 
camera.lowerBetaLimit = null;
camera.upperBetaLimit = null;
that means, you allow to rotate over the top.
Sounds just right. Thx
Sure. But I also saw it on the alpha and in this case, I don’t know what it does. May be you do?
I saw no effect an alpha, I was just testing stuff.
Hi again, I just learned, that turning off the inertia in the onTouch pointer, the flipping does no longer occur - rotations above the zenith work smoothly. You can see that clearly in this playground:
Change the comments from line 198 and following. Does that mean, I have to implement my own inertia methods?
To provoke the flipping just rotate with the mouse by moving diagonally over the scene, so that the beta changes from one side to the other. w/o inertia the rotation is fine.
Interesting finding. 
GJ,
Sounds a bit odd. May be worth calling-in @PolygonalSun at this point. 'see what he would say about this?
BTW, just turning off inertia with the normal arcRotateCamera does NOT help:
This just adds to my confusion…