Switching from Universal camera to ArcRotate camera mode does not work properly

[Dilshad Roshan]

There are two buttons in my page for switching to ArcRotate camera and to Universal camera. When I click the button for Universal camera, it immediately switches to the same. But it always takes too many clicks on the ArcRotate camera button in order to switch to it. Why is it so?

var cameraType = {
    FREE: 0,
    ARCROTATE: 1,
    WALKTHROUGH: 2,
    UNIVERSAL: 3
};

var cameraMode = {
    PERSPECTIVE: 0,
    ORTHOGRAPHIC: 1
};

this.setCameraAsArcRotate = function () {
    _cameraType = cameraType.ARCROTATE;
};

this.setCameraAsUniversal = function () {
    _cameraType = cameraType.UNIVERSAL;
};

 

[Wingnut]

Hiya DR, welcome to the forum.

Perhaps you have a JS problem, and not a BabylonJS problem.  Use console.log to 'watch' every action of your button-press event (the button onCLick event, the onClickHandler code, etc).  Ensure that the button handler code is called EVERY button click.  I think you may find issues... in those areas.

Here is a little playground demo... to test BabylonJS camera switching:

https://www.babylonjs-playground.com/#ZBTJP#6

It seems to work ok.  (This uses dynamically-generated HTML buttons.  BabylonJS GUI buttons available, too.)

Can you edit this playground demo (and save more versions of it)... and make it repeat the stated problem?

The playground app is our friend.  It makes it easy for everyone to help. 

If you can reproduce the problem in a playground demo save, that would be great.  thx, and again, welcome.

PS:  The demo above has a minor issue with "stored camera inertia" after the switch.  I need to think about how to remove that. 

[The Leftover]

Yo, Wn!

Thanks for the playground link.  I have a question.  OK a preamble, then a question:

For me, most of the value of a camera is a change in controls.  I may be missing something so feel free to chime in.  I have not, for example, seen view-radius (like zoom in a normal camera lens), as a software parameter.

I started with the Arc Rotate camera probably because that was in the demo code I started from.  It's a great starter but it has some obvious limitations.  I was going to try the Universal Camera next.

The main issue with cameras for my application is that my users are not presumed to be tech savvy or gamers.  They are happily doing their job on a computer and then - whoops, 3-D!  The Arc Rotate camera seems to be a good starter because it is fairly simple and fool-proof.  It doesn't allow me to see all the angles I want, tho.

Now where is my question . . . hmmph.

[Wingnut]

Hiya TL!  Um... have you seen this PG:  https://www.babylonjs-playground.com/#3U658N#13

HTML buttons, and 7 ease-animate to various arc-cam positions.

Look carefully at lines 174-201.  Each camera-mover func... animates TWO things.  The camera position AND the target position.  (two vector3's)

People often forget to move the target, which is the arcRotate cam's center-of-orbiting.

Also, you COULD... animate the camera target, radius, alpha, and beta (never setting a camera .position).

You never mentioned animating, so, I'll get back on-subject. 

You said "most of the value of a camera is a change in controls".   I'm not exactly sure what you mean.  "controls" is a rather widely-defined term.

Cameras have... um... "traits"?  Characteristics?  Sometimes called "riggings"?  (but really, rigging is only one of many camera traits)  I dunno. 

Often, instead of changing the "traits" of a camera, it is easier to just change camera types.

The user really doesn't need to be involved.  You can analyze what the user is trying/doing, and switch camera types whenever YOU, the programmer, think it is wise.

But understand... that users are quick learners, especially when you put-up a little GUI panel that always tells users what type of camera they are using, what traits it has, and what "inputs" are active.

Although "inputs" are one of the "traits" that define a "type" of camera, the .inputs are changeable/customize-able. 

Conversely, "traits" such as rigging... those are NOT recommended to be changed on-the-fly.  Easier and wiser to change camera types.

With me on all this?    If so, you're doing better than I.    Cameras have something called "behaviors", too.  Strange things I know little about.

Anyway, for arcCams, and other cams with .target, setTarget(), .lockedTarget, etc... always remembering to move the camera AND the target... might help you view "all the angles". 

I hope I've been helpful.  Party on!

NOTE about #13 PG:  For me, in FF52 ESR,  in "Latest", ArcCam dragging is failing.  Switch to "stable" version to make ArcCam dragging begin working.  Possibly/likely a Wingnut coding mistake. 

Dilshad Roshan... thanks for letting us "borrow" your thread for a moment. 

[Dilshad Roshan]

Thanks for the answers. But sorry Wingnut. It took some time for me to realize that the actual problem was not the camera switching. The camera gets switched back to arc rotate camera. The problem is that the axis of rotation of the arc rotate camera changes when I'm trying to switch back, standing at the point I've reached using universal camera, so that the rotation looks like looking around using universal camera.

[Wingnut]

HI DR!  Yeah, the universal cam, and the arcRotate cam... utilize their targets differently, don't they? 

A possible good first step... might be... when you switch to arcRotate cam, un-parent all cams (if any are parented), and then parent the universal cam to the arcRotate cam.  And when you switch to universal cam, un-parent all cams, and then set arcRotateCam.parent = universalCam.  You may need to do arcCam.position = universalCam.position (or opposite) just AFTER un-parenting all cams, and before doing a "fresh" parenting action.  Not sure.

This MIGHT keep the cam positions the same, no matter which is being used.

BUT, this will not set the target in the same direction... for both cams.

You are wishing for a "seamless" (un-noticeable) change... when switching-to EITHER type of cam, yes?  Not an easy challenge, but interesting.

I have never tried this, and I will give this some thought.  Setting the arcRotate target DISTANCE-FROM-CAM (the camera's radius)... after switching to arcRotateCam... might be a difficult thing.

There IS a possibility... to modify a universal camera to make it ACT like an arcRotateCam.  That way, you never really switch cams.  Instead, you turn ON/OFF the "universalCamActsLikeAnArcRotateCam" -mode.  This idea might not be easy to do.

Perhaps other forum people will have ideas and tests, too.  Stay tuned.

[Dilshad Roshan]

Got it done as follows, when switching from UniversalCamera to ArcRotateCamera.

var position = camera.position;
var target = camera.getTarget();
var distance = BABYLON.Vector3.Distance(position, boundingBoxCenter);

target.x = position.x + (target.x - position.x) * distance;
target.y = position.y + (target.y - position.y) * distance;
target.z = position.z + (target.z - position.z) * distance;

camera = new BABYLON.ArcRotateCamera('ArcRotateCamera', 0, 0, 0, BABYLON.Vector3.Zero(), scene);
camera.attachControl(canvas);
camera.setPosition(position);
camera.setTarget(target);

 

Edited November 16, 2019 by Dilshad Roshan