OK, thx for the PG. Definetely not what I thought it was. Actually, should be fairly ez.
In fact, since both targets are positioned at the same height (on the y-axis), the point is you cannot make an arc rotate (maths based) translation on the beta to the new target since, well, there’s no difference between A and B. So, I guess the solution to achieve this kind of animation would be to have a delta (variable) to create the encurvature on animation. In essence, pick the target(s) position.y and apply a delta to it for the mid animation key and ease it.
Last question may be: Should the curve always go upwards OR could it be inverted if the target is positioned below zero? Is it ever positionned differently on the y-axis or are all targets always at the same y-pos anyways? I’m asking because in your PG, some spheres are placed at different heights.
Hi. The curve does not to go downward (-y). The example shows a manual definition of an arc. I am trying to create an arc with spheres. However, I am glad you get. maybe you can show me a PG with the delta doing the job easier and better
Sorry, I have some domestic constraints I need to handle. Understand it’s time for me to make dinner 
I so far figured part of a possible solution but my animation doesn’t make an arc so far. I know the reason and I believe it can be done through a bezierCurve ease. I also think it’s not just the target but also the beta of the camera that should animate simultaneously to give a good effect. If nobody else kicks in tonight and gives you the solution out-of-the box so to say 
then I will look back at it tomorrow morning.
Okay. Thanks for your time. Looking forward to hear from you again later then
Good Day,
I’ve been thinking again this morning with a fresh mind and figured this approach will never work.
I’m not sure how to show this case to explain the problem. The point is the arc rotate camera is not repositioning when setting a new target. Acting only on the beta of the camera will make the camera move upwards or downwards while looking at the target, but if the new target is positioned differently on the z-axis from the camera (depth or distance), then you would need to somehow compensate with the radius to simulate a forward move towards the new target.
Certainly, there must be another approach to this. May be even using a different camera or a custom version of the camera. As I said, I’m also missing the Math skills to make this.
Here is how far I went this morning trying to simultaneously change the target, the beta and the radius to form (kind of) an arc move. The easing and or tangents and blending is also not just correct but I don’t think I should spend time on it because I really think the approach should be different.
Let’s call in again cc @Evgeni_Popov on your case. Hopefully, he can put this back on tracks? 
I think you need to provide the points on the curve that the camera should follow, as well as the targets to which the camera should point.
Here’s what I came up with:
For the position, I generate a list of points on a semicircle in the xz plane that starts at p0 and ends at p1 (see code). For the targets, I interpolate between the directions (p0, sphere0) and (p1, sphere1) to generate the keyframes.
Thanks for the response @Evgeni_Popov
But I think you are not getting the worry. Actually, the end goal should have nothing to do with depth. an arc movement semi-circle from point a to b. That’s it. dealing with x,y only. No z. (maybe z in the maths but no z movement on front end result)
This should be the expected output https://media.discordapp.net/attachments/1096020612041949184/1113586876331348019/070548bbfec0ab16a67d3e40a9180ea2.png
Thanks for your contribution. But the arc goes up, Not inside. just like the picture I shared
I am sorry if my PG had some z depth movement. this was an error since I was trying to make a workable solution
How about a mathematical solution?
First define a path and put a pseudo-camera on it and let it go from point to point. So you can first verify if the path is correct.
camera path 1 | Babylon.js Playground (babylonjs-playground.com)
Second set a real free camera on the box and let it run.
camera path 2 | Babylon.js Playground (babylonjs-playground.com)
This one is moving the camera in the xy plane instead, Z coordinate remains constant:
I still didn’t see the beta arc movement. I am not sure why.
This is a modified version from @mawa work above https://playground.babylonjs.com/#7KQ6UB#10
The only problem is the arc movement is not really a semi-circle because we’ve manually defined the spawn points within the camRadiusKeys array.
Is there any way to use a formula that estimates the distance effectively rather than using this
camRadiusKeys.push({
frame: 0,
value: 20,
});
camKeys.push({
frame: 100,
inTangent: 0.1,
value: 18,
outTangent: 0.1
});
camRadiusKeys.push({
frame: 200,
value: 16
});
a little hack of it 
( the arc camera position is not something you generally set, it is derived from the target , radius and alpha beta , so I just animated the target and then the radius using a circ easing )
Thank you for your sharing, it helped me solve a difficult problem.
I found that the properties of the Vector3 type need to use AnimationGroup,
and the property of Float type can use scene.beginAnimation.
I am very happy to share my problems with you!
There is a large scene, where the animation transition between position and target is performed on the camera, and there is a freeze effect display from position 1 to position 2. This happens when the animation is only used for the camera, and there is no freeze problem with the Mesh material.
I switched to gsap to achieve it, and the camera animation transition did not freeze.
Do you have a repro in the playground ?