Apply min / max bounds to ArcRotateCamera target position.

[TheGrumps]

I'm using the ArcRotateCamera and controlling pan by updating the inertialPanningX & inertialPanningY properties, and it's working well. However I'm not clear on the best way to limit the target position within a box.

I have attempted clamping the target position in the render loop, however it creates a wobble effect when near the edges. Is there another way that a limit can be defined? (I see the camera allows limiting the rotation and distance, so am I missing the pan limits?)

Thanks in advance!

[Wingnut]

Hi TG, welcome to the forum.  Sorry for the slow replies!

camera.lowerAlphaLimit = Math.PI / 2; // or any radian value

camera.upperAlphaLimit = Math.PI / 2; // or any radian value

...should do the trick.   More stuff... http://doc.babylonjs.com/playground/?code=upperAlphaLimit

There is some advanced things that can be done with camera.isInFrustum(someMesh)... but we won't visit that, yet. 

Also, cameras can have BJS Camera Behaviors, one of which is Framing Behavior.  I haven't used it much, but it sure looks interesting and powerful.

Keep in mind that ArcCam targets... are a vector3 value.  It is common for folks to animate .vector3 values... or even invisibleMesh.positions... from location to location... as a way to aim the ArcCam.  People often want to adjust camera alpha, beta, and radius... to aim an ArcCam.  They sometimes forget about moving its .target vector3 and letting the camera aim itself at the new location.  Just a little reminder.

I once built some little eased animator functions... and put them on all mesh...  https://www.babylonjs-playground.com/#HH1U5#72

(lines 2 - 50)  As you can see, they are just "wrappers" for the cool BABYLON.Animation.CreateAndStartAnimation() func.  Might be handy for... myInvisibleMeshCamTarget.moveTo(someVec3Position, speed) 

I hope this helps.  Write back, as wanted.

[TheGrumps]

Hi Wingnut, thanks for the welcome and the response. ?

Sorry, I think I wasn't clear - I see limiting rotation and radius, but I'm not clear on how to limit the pan. To make things clearer, I've put together a playground: https://playground.babylonjs.com/#XEIQ25

Welcome any suggestions!

If need be I can always implement the pan behaviour myself to support the clamping of the target position, but the amount of math involved would be a pain so I thought I'd double check I haven't missed anything obvious before heading down that path.

Thanks!

[Wingnut]

Hi TG!   Umm, I'm not sure I understand.

https://playground.babylonjs.com/#XEIQ25#1

Like that?   See lines 22/23 set to tiny tiny values.  I gave you Math.PI numbers in my example, but I figged you would set them real small, after some experiments.

Set lines 24/25 to ... oh... 1.5701 & 1.5700... and that will do the same for cam tilt/pitch... if wanted.

That would result in a rather input-less aim-at-.target cam... which is maybe what you want.  We might have been able to do the same... by removing "mouseInput" and/or "keyboardInput"... from the camera.inputs property.  I don't know much about adding/removing camera.inputs, but playground searching could help.  Using a freeCam with .lockedTarget might also work.  The cam.lockedTarget could be an invisibleMesh.position, and that could be animated/moved to anyOtherMesh.position.  (Fun with moving cameras-around - the adventure.)  :)

But, let's stay on subject.  "Panning" (orbiting) is now disabled, yes?

Control + left-mousebutton-drag... is still active... and that is sometimes called "dolly left/right"... and sometimes called "strafe" and sometimes called "slewing".  It is a moving the .target position, which makes the camera come-along.  Right now... when you say "pan", I am assuming that you do NOT mean... control + left-mouse-button-drag.    You mean... WITHOUT using the control key == pan.

I just want to make sure that I'm not confused.  I get that way, sometimes. 

[TheGrumps]

Hi Wingnut,

Thanks for the response!

8 hours ago, Wingnut said:

Umm, I'm not sure I understand.

Sorry, I think I'm confusing you with the terminology I'm using - by "pan" I refer to moving the camera and target around in the scene. (I agree that "pan" isn't really the correct term for this - "track" seems more correct to me, but the ArcRotateCamera uses the term "pan" for this.)

8 hours ago, Wingnut said:

when you say "pan", I am assuming that you do NOT mean... control + left-mouse-button-drag.

Yes, that's what I'm referring to. ? (All the settings for this on the camera, such as intertia and origin target refer to this as "pan" - sorry for the confusion!)

In my original playground, you can control + left mouse button drag to move the camera (and the target) around the scene, and the target position is being clamped in the render loop. However this results in strange behaviour when the target reaches the clamped boundary - you can see this by moving to the edges. (There's some wobbly and "elastic" camera behaviour.) Therefore I assume this is not the correct way to limit the target position, and was wondering whether there is a way to achieve this correctly?

As mentioned in my previous post, no problem if there isn't one since it would be possible to achieve by manually handling panning and only updating the inertialPanningX and inertialPanningY values when suitable, but the amount of matrix math involved is likely to be a pain! But if I do go that route I'd be happy to share if anyone needs.

Thanks!

[Wingnut]

Ah yes, ok, I see it.  (thx for the clarification, tg... well done).

Strange camera behavior... at the edges.   (reminder to others... this PG - control-drag to edges of screen - clamp troubles.)

I don't have a solution or a reason figged, but I'll think about it.  Probably over my head... but that doesn't matter to me, I'll talk anyway. 

Could camera.useFramingBehavior... possibly be of assistance?

http://doc.babylonjs.com/how_to/camera_behaviors#framing-behavior

It's sort of new-ish... I have very little experience with it.  Ok, stay tuned... show'n'tell.    Issue open.

[Wingnut]

Hey TG... any good news on this issue?  Fellow forum helpers... we could use some input on this, if anyone has some.  thx.

[Guest]

I would go with a simple per frame check. Unless I misunderstand here (happens a lot recently :)), you can just check per frame if camera.getGlobalPosition() is where is should be and if not just call camera.setPosition()

[Wingnut]

Thx DK.

https://playground.babylonjs.com/#XEIQ25#5

Wingy goofin' around.  Checking control-drag limits.

I couldn't get camera.getPosition() or camera.getGlobalPosition()... to work.  Funcs not found.  hmm.  Maybe I need a browser cache clearing.

I played with camera.target, instead.   (tiz ok, because we are talking about CONTROL-dragging, here, which IS camera.target dragging.  Camera.target is a vector3.)  (for those following along at home)

All BJS-provided camera constraints are OFF.  (lines 15-25)

Lines 36-43 is the "target corral"... where we fence-in the camera.target to a 10 x 10 box/corral.    Round-up!

Seems ok.  The only weird part... is when you orbit the camera about 25 degrees (or any odd angle)... and then start control-dragging.  When the "fence" is encountered... sometimes the camera moves closer-to/further-from target... a small amount.  That seems weird... but maybe expected.  Maybe I need else-ifs instead of ifs.  Comments/code welcome.  (thx)