Stop Arc Rotation Camera from Moving When Picking

Was writing a help-wanted post and figured out a solution to this problem and thought I’d post it to save someone the hours I spent on it.

To make it clear, I wanted no camera movement (rotation or “panning” which really should be called trucking or translation) whilst interacting with objects in the scene (picking or dragging).

I used this beforeRender set camera.alpha and beta code from this playground by @nasimiasl as my starting point - Babylon.js Playground

And just made it conditional based on onPointerDown and Up and locked panning via .panningSensibility=0. But the scene kept jumping around at the end of the pointerUp call and it was much more noticeable on mobile.

Then I realised you needed to wipe off the inertia from the camera during the click. I’d also suggest tuning the inertia to your needs as my scene was spinning at some crazy speed with the default when all I need is 1~2 rotations from center of the screen.

Final playground -

By the way to people who know more about the docs that I do as I’ve only been here since Friday:

I tried to use the “Customizing Camera Inputs” guide but that doesn’t have the same default setup in it’s code as a recent version of Babylon.JS (like there is no mouse attached by default in my scenes) and detaching the pointer doesn’t do anything for me yet I take it that would have also disabled zoom which you need to get far enough out to get some background to click on to move the camera.

Also I really struggled to understand what panningSensibility actually means. The docs don’t really help there (either in explaining it as limiting translation or what sensibility means).

I do wish more problem/solution code was in the docs so you weren’t relying on the forum posts so much (and I really don’t have the energy to be setting up whole repo’s and making pull requests to make suggestions).

cc @PolygonalSun

Also since the forum wouldn’t let me have more than 2 links in my post here’s the playground showing the problem with the jump/move on pointerUp -

just to address this, we try to make as easy as possible to contribute to the docs, all the pages have this button:

that takes you directly to the doc page, you can edit and submit a PR directly from Github without needing to set a repo :smiley: I do this all the time to make small edits and improvements to the docs :sweat_smile:


Hi and Welcome to the Community,
Despite your struggle with this camera thingy (cams are sometimes hard to master, don’t ask me :grin: :wink:)…despite of this, I hope you are still enjoying your journey with BJS. Know that the forum will always be here to try give a helping hand and the docs are also constantly improved. Trust me when I say that your/our opinion and feedback really matters here :smile:

The thing is, BJS is a very versatile framework. One of the reasons why I like it so much :smiley: There’s nearly always a couple, a few or more approaches to a problem. I’m not saying, it’s not perfect (yet) :grin: Things can still be improved and become more straight-forward and more 'automagical :magic_wand: :grin:)

Let’s take your issue with your arcRotateCamera where you want to ‘freeze’ the cam on pick (and then release it). You choose a way and (applause :clap:) you managed to make it work. As I often say, the good solution is the solution that works for you. The one you can understand, manage and maintain.
But then, I could give you at least 4 or 5 different ways to obtain the same or very similar result.
Here (below) is one for you, using the angular sensitivity. The good thing with this version is that it does not mess with the inertia and also, likely, angular sensitivity (X and Y on the arcRotateCamera) might be something you want to include in your user settings anyway.

So, I’m not saying this rushed PG of mine is the best solution. Same as your solution is not the best solution. In fact, as I said, the best solution is (in my opinion) the one that works for you.

But (again, my opinion only) we cannot have just all of these solutions in the doc for every topic. Nobody would be able to read the docs anymore. This is why we have the forum and the playground.
I understand that at first it can be a bit hard. You wouldn’t know how much I struggled during my first month (or year) of apprenticeship :sweat_smile:.

But eventually, in a short time, you’ll find that BJS offers some of the best doc and support available on the market. And, if you feel improvements need to be done (and improvements HAVE TO BE DONE), you can also simply post a ‘feature request’ or even simply give your feedback without making a PR. I do it all the time and, incidentally, it looks to me like some of my ‘comments’ ended-up in a PR and have been somehow 'automagically :magic_wand: :grin: implemented… or am I just dreaming? :sleeping: :wink:

Thanks @carolhmj, I didn’t notice that icon! If I can think of an appropriate comment, I’ll add it in.

1 Like

Thanks @mawa for your response. I can certainly see the forum is a very busy and generous place. It’s interesting looking at your solution, generally it works better than my hack. I really don’t understand what the panningSensibility, angularSensibilityY, angularSensibilityX, means. I can see what their outcomes are by putting in some numbers but what is “Sensibility” in this context? This word seems to only be used for Babylon.JS around these camera settings.

Yeah, I sort of agree with you. Let’s just say the naming is not always the best. Problem is ‘backwards compatibility’ and ‘breaking-changes’. We cannot simply rename these that have been created sometimes years ago because - with the experience and evolution - we realize they are not explicit.
We sometimes do (I mean, the Team sometimes does) but in general, the philosophy is to avoid breaking changes.

Now to answer your question:

PanningSensibility: The sensibility/sensitivity of the mouse or touch or kb when panning. A value of 0 (zero) completely disables panning. A low value (above zero) makes the panning very reactive to input. Higher the value to make it less sensitive.

angularSensibility: Angular sensibility goes for the sensibility/sensitivity of camera movement. A low number makes it react more to change in the input (mouse, kb or touch). A high value makes it move a lot smoother and slower.

angularSensibilityX and angularSensibilityY: A split of the input on the X (alpha) and Y (beta) available only by default on the arcRotateCamera. Where ‘angularSensibilityX’ controls the sensibility/sensivity on the horizontal axis (alpha) and ‘angularSensibilityY’ controls the sensibility/sensivity on the vertical axis (beta)

Now, of course it would be too simple if it was just that :grin:
There’s a lot more and often depending on the type of camera. Reason why we can give custom inputs and reason why there are also some ‘helpers’ for a default behavior.

As I said, best thing when you face a particular issue or have a tech question is to make a PG (playground) and post your question in the forum. Usually, the response time is fairly good.

1 Like

“sensibility” == “sensitivity”.

The english word “sensitivity” is translated into french as “sensibilité”, and “sensibilité” has been translated (wrongly) as “sensibility” when the variable has been created a long time ago (if you didn’t know, you now know from which country the creator of Babylon.js comes from ;).

1 Like

Being a french-native myself, I won’t comment. :face_with_hand_over_mouth: :face_with_hand_over_mouth: You just have to look at my clumsy litterature in my posts to understand that I have nothing to comment here :sweat_smile: :rofl:

1 Like

Welcome to the forums @Skeleton! Just like @mawa said, Sensibility was the original word used for sensitivity and its purpose for being there is backwards compatibility, which can be a bit confusing. As far as Custom Camera Inputs, the docs don’t really get in depth with that feature but the basic premise is that you have 5 endpoints to connect to get your custom input to work with your camera when you add it (ie. camera.inputs.add(<Your custom input class>);). I did write an article a while back to try and break down the parts, as well as provide some code to see how it works: Looking at Custom Camera Inputs. One of the more common questions I see… | by Babylon.js | Medium. It should get a bit into depth with the ArcRotateCamera as well. I think that it would be good to have more examples, maybe even have our community members share custom inputs that they’ve created (hint hint).


Thanks @PolygonalSun, @mawa, @Evgeni_Popov, for all the explanations!

From what I can tell, an analogy for angularSensibilityX and Y, is like the locking knob on a tripod. That an almost zero (but not zero because that seems to be an invalid number for this parameter) number is like having the loosest fluid head tripod ever and a max value around 100000’s will lock it up tight. So they’re force multiplier/reducers.

Also that angularSensibilityX is tied to the Alpha of the camera and angularSensibilityY to Beta.

Q1) Is it right to think that a lot of parameters/properties don’t have defined ranges so you’ll be guessing where the limits are for something or that a value is scaled in relation to another world property so it’s hard to say what effect a certain value will give if it was written in the docs?

Q2) Is there any reason people know as to why the default values for a property aren’t in the docs?

Q3) Now this would have made my life so much easier… as a noob, I didn’t realise how to get the inspector open or that you could get the camera settings within that:

If the camera guides in the docs had a playground that opened with the inspector already open with the camera selected, with some guideline parameters that would speed up understanding how to control it. Yet I see there’s bunch of Camera APIs that aren’t available in the inspector to play with to understand their effect?

Q4) Also whoever is responsible for the playground’s layout, as the inspector opens on the right, wouldn’t it make sense that the right most button in the top toolbar is the inspector? I realise that will temporarily frustrate experienced users, but they already know the icon’s meaning so they should be able to find it. For me the first time I saw the inspector was in a video tutorial long after going through the docs so if the inspector’s icon was also in the inspector itself or looked like a dropdown/toolbar, it’d be faster to find that first time.

And if the play button changed colour/state on change to the code that’d be good (like the dot on a file in VSCode).

I’m clearly a UX designer, not a dev…

I’ll give you my feedback. It’s not an expert feedback. I’m just a simple user or superuser here. And I’m also no dev; - Art dir, PM and UX/UI is more of my kind.

Q1) I found that the values are often very large and often open. Which is of great advantage for the versatility of the tool but can be a bit confusing. In fact, from what I experienced, there’s a limited range only if getting out of this range would break the logic. One thing worth to mention here, since you discovered ‘the Inspector’ which is (in my opinion) a must have tool for experiencing, debugging and developping… the Inspector sometimes has limited range for values/parameters that can be set way above or below with code. One of the reason is UI/UX. I.E sliders would be very hard to use if they would cover a full or infinite range of value. The other reason is may be ease of use and sometimes also because nobody complained. I had some changed where the input did not allow for the correct number of decimals or where the limits were just set too low. For example, take the ‘levels’ of any material (i.e. diffuseTexture.level, directIntensity, emissiveIntensity…). In the inspector these are limited to a value going from zero to two (0-2). In fact you can have negative values and I’m not sure if there’s a limit or not but I sometimes pushed some of those up to 100.

Q2) Some of the defaults are in the doc. But not always. In general the defaults are in the API. Unless it’s missing. If so, don’t hesitate to share your finding and I bet the Team will be happy to implement.

Q3) There’s a tooltip if you hover the buttons. Like any UI, I guess it’s mostly a matter of getting used to it. I don’t find this one particularly disorganized (my opinion only).

Q4) As for the play button highlighting when making a change from the inspector that runs instantly, I think it would be a nice addition. But yeah, just a ‘nice to have’. Here also, once you understand that any change you make from the inspector runs instantly and changes you make in the script require a replay, you won’t really care about this small UI/UX touch anymore. Again, my opinion only.

Edit for Q4) Not to mention that changes done to the inspector are dynamic and run (ideally) at 60fps.
Seeing the play button highlight and flash at 60fps when using a slider would probably not be the best of UX.


@mawa pretty much covered everything here so I’m not sure that I have much to add but if you have any specific examples of things that are missing or camera API calls that should be available in the inspector, please feel free to let us know.

Since we’re a small team, we depend on our community to help us find issues to improve the overall experience, so feedback is great! Furthermore, since this is an open-source project, we also encourage our community to contribute. If you happen to see something amiss and want to fix it, you can also create a PR.