ArcRotateCamera collision behaviour

Bugs
1

Hi everyone, not sure if this is a bug or not, but here it goes:
When defining an ArcRotateCamera, if there is a collision at the initial position, and we try to re-position the camera to avoid this collision, the radius value seems to be ignored. I’ve made a playground with an example:

https://www.babylonjs-playground.com/#A9PJE6#3

Locally I was able to fix this by calling computeWorldMatrix() right after calling .setTarget(). However, in the playground example above, this doesn’t seem to fix things.

Any thoughts?

2

Adding @PolygonalSun and @RaananW as they both worked on similar topics recently.

3

Hey @GeraldoOfTheRiviera, just out of curiosity, what version of Babylon.js are you running locally?

4

Locally, I’m running babylonjs version 4.2.0.

I should clarify, locally my issue is the same as in the playground (radius not being respect), however my setup is slightly different: I’m using an upperRadiusLimit. Here’s what I’m thinking: when I do a computeWorldMatrix() right after my .setTarget(), babylonjs detects a collision, sets a new radius, which is above the one I set for upperRadiusLimit. So when the _checkLimits function of the ArcRotateCamera is called, the camera radius is set to upperRadiusLimit, and the camera is now in a position where no collision is happening. And then, when I set the new radius, I get the correct radius value (because now the camera isn’t colliding with anything). Or something like that :thinking:

If I don’t call computeWorldMatrix() right after .setTarget(), I’m guessing babylonjs detects a collision, this collision sets a new radius value, and babylonjs ignores the values I set for the camera’s radius (and possibly alpha and beta as well).

My final solution was: after doing the .setTarget(), setting alpha, beta, radius, I did the following:

arcRotateCamera.checkCollisions = false;
arcRotateCamera.computeWorldMatrix();
arcRotateCamera.checkCollisions = true;

This way I know collisions won’t affect the position I just set for my camera.

5

So here’s what I’m seeing. It looks like it’s first adjusting the radius to 1 without updating position. Next, it handles the active collision with the sphereThatCollidesWithCamera object, which would modify its radius as it shoves the camera to a valid position (min modified distance should be something like sphere radius [2.5] + cam collision radius [3]). Finally, it would update the camera’s position, with respect to the given radius and current target (still 0,0,0).

In the PG, I didn’t see that upperRadiusLimit was set and when I tried setting it myself, it worked as intended. I don’t know that I’m seeing a bug here, per se.

6

Thanks for the reply! What you’re saying makes sense.

It looks like it’s first adjusting the radius to 1 without updating position. Next, it handles the active collision with the sphereThatCollidesWithCamera object

Personally, it’s not obvious to me that there would be a collision in the first place, since I just set a new target and radius to avoid said collision.

While we’re at it, if we do something like:

cam.setTarget(newTarget);

followed by a cam.getTarget(), we will not get a vector with the newTarget we just set. Does this make sense :thinking:? PG:

7

Yup I will fix the getTarget in the next nightly