ArcRotateCamera panning behaviour different in 5.0.0 than in 4.2.0

The panning result of doing a mouse2 + drag with an ArcRotateCamera in the @latest version is different from what it used to be in 4.2.0. In previous versions, the panning would follow a plane perpendicular to the viewing axis. Now, while the response to horizontal mouse movements is still the same (panning along an axis parallel to the viewport’s horizontal dimension), vertical mouse moves end up only panning in the 3D space’s Y axis. Is this an intended change, and if so is there a property I can set to mimic the old behaviour?
Thanks for the help!

I tried to pan in x/y in this PG and could not see any different between 4.2 and 5.0?

Could you provide a repro of the problem?

1 Like

Yeah, I tested it quickly in the playground yesterday before posting to make sure I wasn’t seeing things that weren’t there. This is weird if it isn’t happening on your side, on my side the simple PG you linked replicates the faulty behavior. (I tested on chrome and firefox). I think it was introduced with either alpha.4 or alpha.5.
Here’s a quick screen capture showing it with your PG: babylon-js-arcrotate-pan-difference on Vimeo

1 Like

Ok, my bad, I was testing in the default starting position, I was not looking straight down: I can reproduce the problem.

The difference in behaviour comes from this PR:

I don’t know if it’s intended, @Cedric will have a look when he comes back from his holidays beginning of next year.

Hi @emmbema

Can you add this line to your PG and check if works as expected:

camera.panningAxis = new BABYLON.Vector3(1, 0, 1);

1 Like

Hi Cedric,

It’s similar, but not quite what I’m looking for. In previous versions, the panning resulting from a mousemove in the screen’s Y dimension used to occur in an axis relative to the camera’s angle (and would update accordingly to new camera angles). To illustrate the desired behavior more precisely, here’s a simple PG replicating it by doing a cross product of a right vector and the camera’s viewing axis vector:

var viewAxis
scene.registerBeforeRender(function() {
  viewAxis = camera.position.subtract(camera.getTarget()).normalize();
  camera.panningAxis = BABYLON.Vector3.Right()
    .add(BABYLON.Vector3.Cross(BABYLON.Vector3.Right(), viewAxis));
})

What I’m wondering is: is it expected that we have to implement this behavior ourselves although previous versions used to abide by it?

Thanks for the help!

I think the panning axis vector is not properly defined in the API. It’s not meant to be world axis or local and depending on the use case, it doesn’t work.
I guess here is to define if we want each panning axis component to be world or local to camera space.
What’s your thoughts here @PolygonalSun ?

I cant think of panning ever being anything else but camera local space since that is the orientation the user is mentally aligned to.

I’ll take a look to see what’s going on but I can repo what @emmbema is seeing. My general expectation for panning, by default, is that it should work like it does for 4.2. I would even go as far as to argue that this behavior is broken for the 5.0 alpha.

So I made a couple of changes to the ArcRotateCamera panning code to make it work closer to how it originally worked (PR 9756). As far as defining the panning axis, I feel like defining it with respect to the relative camera space makes more sense to me rather than world space.

2 Likes

Hi,
since 5.0.0-alpha.7 my ArcRotateCamera is not considering PanningAxis anymore.
I have tested setting camera.panningAxis = new BABYLON.Vector3(1,0,1) in one of your Playgrounds above. In version 4.2 the expected behaviour is, that the camera can only move on a global horizontal plane. However, in latest v. 5 this is not the case anymore. So for me it seems the behaviour was not reverted to 4.2 but broke.

PG: https://playground.babylonjs.com/#WMKU86#7

Which one is the desired movement direction? Looking from camera or from target plane or even both?
Do you have a temporariy workaround to achieve the old behaviour of panning globally.?

Seems like setting camera.target.y = 0 can do the trick. Though I guess the speed of movement is different to the old version.
PG: https://playground.babylonjs.com/#WMKU86#8