First let me explain the behavior,
When the camera is under or on top of mesh. Like a satellite to be on north pole or sud pole, and then you drag the mouse to the right or left, the floor rotate on himself.
But I want to know if there is a way to use the ArcRotateCamera but instead of just rotate on himself the camera will rotate around the mesh.
@PolygonalSun who is coming back next Monday might have a trick for you also adding @Cedric who might have done smthg for this recently ??? (completely unsure… I am getting old)
I think I see what you want: moving mouse left right, will always rotate camera left/right whatever is its previous orientation.
I’ve started a quick test but I don’t get the intended result. In substance, I would do what’s been done in https://www.babylonjs-playground.com/#K4UGI8#9 and attach the camera to it.
AFAIK, there is no such camera behavior in babylonjs by default but I might be wrong.
I think I didn’t explain it clearly because I have trouble explaining it, but it seems that the camera rotate well around the mesh most of the time, but for some unknown reason when you got to the top of the mesh (north pole) or the bottom (sud pole), and then you want to continue to rotate the camera around the mesh, you drag the mouse left or right but the camera rotate on himself instead of rotate around the mesh.
Maybe this PG will be easier to show the behavior: https://playground.babylonjs.com/#6XIT28#828
Turn the mesh cube until you see the 5 number and then drag the mouse right or left and you will see the 5 number rotating.
I’m a little out of my depths here, but I think I understand what you want.
What beta you set on your camera at start doesn’t matter since it will change as soon as you move your camera. I think @JohnK was referring to the weird change in rotation direction that often happen when you reach the exact north or south pole. But I don’t believe this concerns you since you don’t want this rotation at all, no matter the direction.
I think this describes pretty well what you want. And if that is the case, I’m afraid the only solution is to rotate the mesh according to the mouse input, instead of moving the camera. Because here, that would mean that alpha-betas on camera move would depend on curent alpha-beta. Wouldn’t this mean a depth overflow because of recursive dependance ?
i think i understand . basically the arc rotate camera works with alpha ,beta ,radius properies and , alpha and beta works like constant x and y world axis so you can’t rotate it relatively to it self . what u have to use is a freeCamera with the method of target to target the mesh u want ,then u can rotate it on it local axis
A big thanks to all of you for all the answer, I think I have more understanding of how the camera interact and work with the scene now. I have many feature using the ArcRotateCamera in my project so I will leave it like this for now and live with the behavior but I will surely try the freeCamera for my next upgrade.
I will tag Nova_hovekh answer as the solution but all of you really help thanks again!
Any updates/improvements on this? Having the same issue. ArcRotateCamera is super useful and I’d rather not replace every instance in my code with a much more custom solution just to solve this annoying issue where the behavior around the poles is strange/not desirable.
One potential solution I had in mind (though I haven’t been able to implement it) is this: use ArcRotateCamera, but after each rotation finishes (or in real-time throughout the rotating action/motion), re-orient the entire spherical coordinate system (alpha, beta) such that the direction (alpha = pi/2, beta = pi/2)* is aligned with the camera’s pointing direction. This way, the camera never reaches an (alpha, beta) which is close to the poles.
*Or any other direction away from the poles.
If this is indeed still very difficult with ArcRotateCamera, a PG example with another camera/a completely different approach would still be appreciated. Better than nothing.
A potential solution is to extend the freecamera to your need then replace all instances of arcRotateCamera. I feel like I’m not sure the behavior you want when reaching gimbal lock.
I feel like I’m not sure the behavior you want when reaching gimbal lock.
The intended behavior is to continue revolving around the poles, and show the same behavior as if I’m on the “equator” of the sphere.
Did you try to implement your solution in a PG?
Not in a PG, but from my experiments, I’m not sure if it’s possible. Attempting to re-orient the spherical coordinate system of the camera after a rotation is complete does not seem possible; instead, it acts like I want to point in that direction. Don’t have a PG handy unfortunately, but if we could somehow re-orient the entire spherical coordinate system to automatically rotate the sphere so that the forward-facing camera direction ends up at the equator (e.g. (alpha = pi/2, beta = pi/2)), then this pain would be significantly relieved.
Amazing!! That’s exactly what I needed, thank you! I managed to implement 3 more functionalities I needed in the following PG:
SHIFT + Click & drag to pan
CTRL + Click & drag to roll camera (around its pointing direction)
Scroll to zoom in/out towards the direction of the cursor
The only bug I’m trying to solve is this: after zooming towards some direction, if I click & drag to revolve the camera around the scene, its position kinda resets? Any idea how to fix this?
Thanks, but that’s not quite what I’m looking for unfortunately. I do want to zoom in/out towards the cursor, rather than the direction in which the camera is already facing. This is working fine — as I said, the only issue is that clicking & dragging to revolve the camera around the scene isn’t working properly, after I zoom into some direction.
No quick fix here, unfortunately It’s a math problem at its core.
But I did notice this: in the code, there’s a variable named cameraTarget that seems to be conflating two different concepts:
Look-At Target - The point the camera is currently looking at (Babylon’s definition of camera.target or what you pass to camera.setTarget())
Barycenter - The point around which the camera rotates when orbiting (aka the pivot point)
In an ArcRotateCamera, these are the same thing. But in your case, they may not be, especially after you zoom toward the cursor.
Some ideas for starting points:
Separate cameraTarget into two distinct variables as described above. This would clarify what rotates around what, and what the camera looks at.
Work with the camera’s rotationQuaternion instead of its target. After orbiting, instead of calling camera.setTarget(), directly update the camera’s orientation using quaternions. The math might be simpler than reconciling look-at targets with pivot points.
also adding 
It’s a math problem at its core.