Hi guys. HD, I found another playground that does some “eased” arcCam animating.
https://www.babylonjs-playground.com/#3U658N#32
If I remember correctly off the top of my head, this one uses animateCameraTargetToPosition() to move cam target to a location “on the far side” of the selected mesh. Apparently, we found this to be important, and NOT just let cam target stay at selected mesh position. “Far-siding” the cam target might not be necessary for YOUR applications. Moving/animating cam target to selected mesh.position… might be all you need to do. Either way, you have funcs there… to animate both cam.position and cam.target… easily and smoothly. These animators are also rigged with onAnimationEnded funcs, too… lines 173-181.
So, two animations run with each button press… animateCameraTargetToPosition() and animateCameraToPosition()… and a function called forceRebuild is called on the camera… after anims end. That forceRebuild is needed… because we are force-animating camera.position to a new position… which does NOT automatically update cam .alpha, .beta, and .radius properly for the new forced-position. forceRebuild sets those values correctly… PER the new camera position/orientation.
Earlier versions of this PG (#17) put the forceRebuild() function call… inside the renderLoop. This was before I added the onAnimationEnd functions. I THINK the rebuild is only needed after the anims end… but that depends upon IF/NOT user interaction is allowed to cancel an animation before it ended.
Generally speaking, the rebuild is needed BEFORE normal user-driven arcCam operations can be re-started.
shrug. Just another example, and this does not use any invisible mesh, as far as I know. It might be a place to “borrow” some code/ideas. And obviously, camera.position IS a set-able/animatable thing. (I was mistaken on that point, in my previous post.) ArcCam rotations are based-upon target position, of course. Free/Universal cams are likely different. A property named .lockedTarget might be worth investigating. Party on!