Replicating view from FreeCamera in an ArcRotateCamera

Hello Everyone,

It is my first post on the forum, but I am a frequent lurker and found a lot of solutions to problems I have encountered at work.

I am facing a problem relating to translation of the views from Free Camera to ArcRotate Camera. In a nutshell, I would like to mutate the arcRotateCamera to replicate the view of an exported Free Camera.

For example, I have a scene with two models. The view from the default arcRotateCamera is shown in image1 attached to this post.


In the glb file, I also have two Free Cameras.The first looks at one model:


While the other has both models in its viewport:


In order to replicate the view from FreeCamera in the arcRotateCamera, I perform the following steps by mutating the arcRotateCamera:
a) Position the arcRotateCamera in the location of the Free Camera (i.e. attaching to its parent mesh)
b) Set the target as the middle of the model (setTarget)
c) Update the alpha and beta as well as upVector

When I am performing these actions on the scene with single model, I am able to achieve the desired results.

However, once the scene contains more than one model, the derived alpha and beta of my arcRotateCamera becoming slightly incorrect.

My gut tells me this might me related to the fact that the worldExtends of the scene with single model are different than in a scene with multiple models.
I would like to provide a playground, but my model files are quite big and there is a lot of custom code, what makes it difficult to replicate.

I was wondering whether anyone has encountered similar issues before or had any suggestions how this task could be approached differently?

Any ideas are highly appreciated!

1 Like

Adding @PolygonalSun our Camera expert and I bet it could help greatly if you could provide a repro in the playground.

1 Like

Hey @wtm,
Without seeing any code, it’ll be a bit difficult to pinpoint exactly what’s going on. So when you said that you’re using worldExtends, do you mean that you’re using scene.getWorldExtends()? If you do, then my next question would be, are you providing a custom filter predicate when you call it or do you leave the parameters empty? The reason why I’m asking is that getWorldExtends should use the bounding box for info of all meshes that fit that filter (by default, it won’t filter anything).

For updating the angles, what values are you updating them with? For example, are you just retaining previously used values and reverting them after calling setTarget or is there a different process.

In any case, you might also be able to use the ArcRotateCamera’s zoomOn function or FramingBehavior to produce the desired results.

1 Like

Thanks @PolygonalSun. I am replying on behalf of my college WTM whom is on holiday this week. If I can follow this up with you that would be great. I can also provide some more information. A playground would be ideal but am not sure it would be possible. However, I can take another look at it.

Originally, we created a single model 3D viewer using Babylon, with custom GLTF format to support our models, which can include, animation, contours, and many other custom things.

We have now moved onto additional functionality that includes multiple views and these can include annotations on a model or have multiple models in one file with different annotations associated.

We have gone with the solution of assigning meshes of parts and assigning them to a viewport or viewports that are controlled by layermask value changes. this allows us to only show what is needed.

In relation to a model that include annotations we use the createDefaultCamera as our default and we translate all our exported cameras from FreeCams to ArchRotateCams that will give the correct positions etc. if there is one model in the scene it works.

However, when we have multiple parts all around the world, we cannot see to position the camera correctly using the createDefaultCamera. Our thinking was we should create own cameras using the source code from

This is where we derived worldExtends from and we thought we may be able to tailor this to give the results.

Below is an annotation export that has multiple parts spread out, as you can see the positioning is off. I believe the dev site is still using the defaultCamera and trying to work from there. However, on my dev branch am trying to go with multiple custom ArchRotateCams to try it out, not sure if that is correct.

You may need to zoom out abit on the first link as the parts are spread out.

WTM has been working on this longer than I have, he will be able to provide a lot more information, but I thought I’d add some extra information for you.

FramingBehavior behaviour is set on any camera we use, zoomOn is new to me. I can investigate that.

Sorry in advance for any typos and grammar :slight_smile: Really thankful for your time

I am trying to understand the issue. This is a basic setup to switcy between a free camera and arc rotate:

Babylon.js Playground (

right click will switch between the two. As long as their target and position are correct, it should work without an issue, unless I missed something fundamental :slight_smile:

1 Like

No, I believe we take the values we need from the freecam or orth cam export and update the default camera, the issue is around getting the camera in the correct position and angel.

All our translations work from my knowledge.

if you download the file below and put it into the Babylon sandbox, all the exported cameras are positioned correctly, however we cannot achieve that for some reason. My college will be able to better explain when he is back on Monday.

1 Like

@PolygonalSun @RaananW can you please advise

playground working but we are running into issues creating new cameras with the exported information from our free cams.

There are four exported cams we are working with in this playground, if you check the insepetor tool kit under root you can see the exported cams

@RaananW is off at the moment and will be back next week :slight_smile:

Is the only issue with the free cameras that they are flipped?

no not just that, there is an issue when a ray doesn’t hit anything any how the camera is positioned. we have some internal camera people looking into it now and hope to edit the offsets and get the correct position. I will reply when i hear more, don’t worry about it at the moment

1 Like