Smooth Camera Follow

[GameMonetize]

We do not have to talk about TargetCamera. This is just a tool for the framework contributors

[Wingnut]

Hey Alex... have you ever used the same 'system' for a FollowSpotLight?  Just thinkin'.  I suppose it would be as simple as parenting the light... to the FollowCamera.  I bet that would look cool.  Not only is the camera following the moving target, but it's also trying to keep a spotlight aimed at the target.

 

And our spotlights have the .setDirectionToTarget(some_vec3) method which could be used, too.  Between the parenting, and the repeated function calling, the spotlight would stay on the target even while the FollowCamera makes (potentially-slow) turns.

 

I may have to build a dark scene just to try that.    I bet it looks cool.  Okay bye again. 

[AlexB]

I suppose it would be better to have a separate follow light, since just parenting the light to the camera wouldn't allow you to make the light track more tightly, or use a different kind of camera with it. I'll take a look at it when I get some free time.

[Dad72]

I tried this camera on my project and made it something that interests me, but it lacks the control with the mouse as with arcRotateCamera.

 

This would be possible to have the same camera but with arcRotateCamera as a base. I need a camera following a character, but can also be in orbit around the character and be able to look up or down and zoom in and out?

 

it's annoying that this camera can not do this. Despite all cameras available in babylon, I cannot find the camera which corresponds perfectly to my project (like camera found in MMORPG)

 

 

 

[Wingnut]

Ooh, maybe a generic follower class.  Not only could you set ANY scene item as the target, but also ANY scene item as the source (the thing doing the following).  Anything could follow anything.  ooh.  That would be fancy, huh?  Probably hard to do, too. 

 

Little Red Wagon object?  Radio Flyer?    Hook the "follower" wagon behind any puller, and put anything in the Little Red Wagon?  hehe.

 

Call it a 'lamb', maybe?  Mary had a little lamb... and that thing followed and followed and followed (her to school one day).  ahem.  Sorry, I'm getting goofy here.

 

The Babylamb 

[Dad72]

Oh, Yes, it's a great idea a generic class that allows you to track any objects (including a camera) and have speed and offset as the followCamera settings.

 

There is also the problem of collision of the arcRotatecamera that sticks rather than to drag along a wall as soon as it enters into collisions. Should a function which allows to detect the event of collision of ways to bounce the camera to prevent it sticking. But I can not find such a function. For example: onColliderEnter(); onColliderExit(); would be super awesome.

[Wingnut]

Colilsions and sliding-along.  Phew.  What a potentially HUGE subject.

 

Let's pretend that a camera ellipse is a box instead of an ellipse.  Now let's pretend that a user has somehow moved a mythical collision-active FollowingArcRotateCamera into a stoppered 'hole' (indentation) in a wall. 

 

Even up/down and forward/backward directions are blocked.  The ONLY direction this camera CAN go... is in the opposite direction of its arrival.  It must exit the hole (back-track... which is also a type of slide-along), and then decide to try sliding-along upward, downward, forward, or backward (to avoid going back into the hole). Then, it must go back to listening to user movement keys/mouse-commands.

 

This is a "worst case scenario" for a slide-along algorithm.  In this example, the slide-along is two steps... one for the back-track out of the hole, and one for the "shift" move (up, down, forward, or backward) that would need to happen next.

 

So, even after the camera exits the hole, we cannot yet listen to user input until we move the camera up, down, forward or backward a bit.  And there could be blockages to THAT move (another instantiation of the slide-along algorithm?)... and the (new) algorithm must be smart enough to NOT allow "go back into the hole" as one of the choices for ITS (new) slide-along determination.

 

And how does an algorithm decide which of those 4 directions... to try sliding?  These "try-sliding-left" and "try-sliding-up" and "try-sliding-down" sub-routines... would need to set flags, so the overall algorithm could make final decisions based upon the 'state' of the camera.  The algorithm would need to know 'how' the camera box is stuck.  erf.  ouch.  :/

 

I pity the poor programmer who sets-out to invent the perfect "slide-along" algorithm. My brain hurts just pondering it.    What a nightmare project that would be... but... what an important project just the same.  The slide-along algorithm would solve Dad72's problems, but does he have a Cray mainframe that can run it?  hehe.

 

I bet the pseudo-code aleady exists, somewhere.  Surely, others have put hard study into slide-along adventures and experiments.

 

I know when I'm viewing a MS Train Simulator train from the side, and it passes a hill along the tracks, the camera slides up the hill until it can clear the top, and then remains at that height until I keypress it back to its original altitude.  So, a "try to resume previous settings" would also be an option for a slide-along system... and an option that MS Train Sim decided not to try. 

 

PS:  I tried that followcam light thing.  http://www.babylonjs.com/playground/#2FOVLD  Had to do it. This doesn't use parent, though.  It just keeps updating the position as if the light were parented to the camera (.rotationOffset doesn't apply its value to children [rightly so, I believe], and in this demo, .rotationOffset is animated).  Doesn't it look cool?  I think so.  It feels... somehow... circus-like. 

[JCPalmer]

Interesting.  I liked how you pulled stuff out of FreeCamera into a common base class of TargetCamera.  I had started to use the lockedTarget feature of FreeCamera back before you started this.  Did not even notice till now that the implementation underneath had changed.

 

I had spotted that BabylonFileLoader would set lockedTarget, if it found it in a .babylon file.  I knew you could set this from Blender, so I added it to the TOB exporter I was making.

 

There are 2 points of discussion I have:

 

A - When the target's position changes the cameras direction does not keep up.  I had a cheapo work around that I talked about in this thread http://www.html5gamedevs.com/topic/8275-is-cameralockedtarget-supposed-to-follow-a-moving-mesh/?hl=lockedtarget.  Basically I tricked it into recalculating its direction by calling this code every time the mesh moved: 

if (this._activeLockedCamera !== null) this._activeLockedCamera._getViewMatrix();

Might there be a more direct way?  BTW, when I saw this thread I commented this out, and the 'directional following' stopped.

 

B - The follow camera might actually be an even better alternative!  FreeCamera was just tricked into changing the its direction, but it stayed in the same place.  After a couple of turns things could be hard for the viewer to understand where the mesh now was as it moved away.  Imaging flying and the camera was now pointed up so that the ground could no-longer be seen.

 

Switching out the FreeCamera might be alright for the .js & .ts exported, but this would have to be a change in the behaviour for a .babylon file, and I am not sure what to do about it. Editing the BabylonFileLoader.ts is clearly required, but is another JSON 'element' needed to be specified so keep compatibility?

[JCPalmer]

I thought of a fairly clean way of taking this out of the render loop to avoid unnecessary CPU when the target did not even move.

1. Add private property to AbstractMesh, _followCamera, with setter called setFollowCameraDoNotCall()
2. Change FollowCamera.target to private with setter, setter below:

setTarget(target:AbstractMesh) : void{    // un link any prior target   if (this._target) this._target.setFollowCameraDoNotCall(null);   this._target = target;   this._target.setFollowCameraDoNotCall(this);}

AbstractMesh.isSynchronized could add a couple of lines at the front:

if (this._followCamera && !this._cache.position.equals(this.position) ){     this._followCamera._update();     return false;}

The only issue might be how often is isSynchronized called.  I do not even see it called.

[JCPalmer]

I did not notice, until I downloaded the .zip from the playground with all the buttons, that FollowCamera is already out of the RenderLoop.  I have added support for follow camera from Tower of Babel, both for inline .js/.ts and .babylon.

 

TOB 1.0 is out very soon, but cannot put up changes to BabylonFileLoader at the same time, so that data will be ignored from a .babylon right now.  I had already edited BabyylonFileLoader for Shapekey/Automaton meshes.  The .ts will blow up if Automaton is not found.  That is not to far away either though.

 

The Blender custom panel for camera is attached.

 

I did notice that FollowCamera can sort of y axis seesaw.  I cannot publish the actual example.  My Dropbox account is too new, and this is not allowed.  I can make videos though, then post links.  To keep file size down:   window size, time duration, and frame rate is limited.

 

First is the way I was able to directionally follow without moving the camera (My hack):  https://www.dropbox.com/s/5clkhimgyrevedo/Directional%20Follow.mp4?dl=0

 

This is using the FollowCamera version:  https://www.dropbox.com/s/bm8mqksl85odkyd/Dir%20and%20Postion%20Follow.mp4?dl=0

 

It is only recorded at 15 fps, but you can clearly see once the table cloth / flying carpet starts going both vertical and into a banked turn, the ground starts oscillating.  It gets worse as it continues the turn, but this is enough to show it.  Any ideas why?

[Wingnut]

Hi

    We need a playground scene for testing the followCam... for that banking and altitude situation.  I'll try to make a decent tester, but there's people far more qualified than I... to make complicated flight paths.

 

What we're probably looking-for here... is a flight path similar to what a crop dusting airplane might follow.  At the ends of low passes across fields, the aircraft (mesh) does a stall turn or hammerhead turn...

 

 

We/I can make the followCamera try to follow a mesh that does that.  We would get the banking and the altitude-increase mentioned in Jeff's flying carpet situation.  (BTW, a fun animation, JC!   Who ever said tech Gods can't be artists, eh?) 

 

One way to do this test playground (a less-than-optimal way) is to hang a chain of linked physics primitives... from the bottom of a mesh that is tracking-on a flat figure-8.  Then make the followCam target be the bottom linked mesh.  That mesh should be doing climb-altitude banking (loose hammerheads) on each tight turn.  Pendulum ops. 

 

But a decent math master... should be able to give us a simple crop-dusting airplane... playground demo.  Low passes across the field, and hammerhead turns (with adjustable 'tightness') on both ends of the field.  That should be a perfect testbed for us to watch the followCam do its stuff, and potentially add features to stop this oscillating.

 

Volunteers?  Math gods?  I would say avoid the physics (linked mesh) method, and use a simple airplane model made from 3-4 basic babylon.js shape primitives.  I hereby offer 13 U.S. pennies and my left sock.. to the first person who creates an animated playground scene of a simple airplane... crop-dusting a createGround area... doing hammerhead turns at the edges of the "field".

 

No, you don't need to turn-on a babylon particlesSystem as it does the low-passes across the field, but you get extra points if you do. 

 

C'mon math formula Gods... make us a crop-dusting airplane scene... so we can torture the followCamera in ways that pertain to JC's observations.  Let's load-down Alex's followCamera with a bunch of new features. 

 

I suppose a guy should ask if Alex or anyone else... is thinking about a "universal follower" class/add-on device.  FollowManager? *shrug*  If a followManager existed, I guess the followCamera would no longer exist.  A followCamera would simply be a targetCamera that has a set .followManager:

 

camera.followManager = new BABYLON.FollowManager(scene)

 

Or maybe not. 

[JCPalmer]

Wingnut,

I have a longer video, which describes better the situation.  The camera seems to be lagging in its tracking then all of a sudden catches up.  This may be due to a slight pause while the next deformation is prepped for.  Each flap up and flap down is a different deformation.  In that gap of time, the camera catches up, and it makes you motion sick.

 

I would prefer no lag, which would produce a stable tracking with tiny pauses.  Am using defaults on maxCameraSpeed & cameraAcceleration.  I played with these settings and seemed to reduce the effect, but never eliminate it.  I do not know what I am doing.  BTW, if you want to simulate an earthquake set cameraAcceleration = 1.

 

The framerate for this is 25, and it really is that jumpy.

https://www.dropbox.com/s/3s8dquklllpd4pt/FollowCameraLonger.mp4?dl=0

 

 

Jeff

[joshcamas]

Is it possible to add a thingy where if there's an object in the way of the target, the object get's "pushed" in front of it?

 

AKA make it so you can ALWAYS see the target, even though it's standing in front of a tall lamp post of something. That would be sweet!

 

EDIT: I needed a camera that had mouse movement input like freecamera, but the following like this camera. Think minecraft. I ended up making a mashup of freeCamera and followCamera. It works now, (Not perfect of course) and I'll post the code if anyone wants it. It could be merged with followCamera, as it consists of a function, and a line edit in the follow function, as well as one line edit in the update function. (So you could enable or disable the feature) Ima try to add the maxCameraSpeed to the function soon as well.

 

 

EDIT 2: Here's an example of the Camerathingy: http://steinhauer.x10.mx/camera/

[Wingnut]

That works excellent, joshcamas!  An ArcRotate-like camera (minus the mouse wheel zoom) that follows!  Cool.  Don't lose that code!    I may be asking for it later. 

 

I think I see it in your nice demo.  ( http://steinhauer.x10.mx/camera/MouseFollowCamera.js )  You rock!

 

I'm a bad coder, lousy 3D guy, blow hard, and a dreamer, but I have big plans for 'follow'.  I'm really not done dreaming, yet.  As mentioned earlier, I am becoming convinced that 'follow' needs something wonderful... like maybe a FollowManager class.  I am dreaming of a system where anything (that has installed a FollowManager) can be told to follow any target.  Your demo is SO CLOSE to being a following ArcRotateCamera, that, it should actually be one (later maybe).

 

Another issue that was raised recently... was about how a followCamera acts...  when the target banks like an airplane might do.  A FollowManager could have settings for that.  Also, many objects could follow a single target mesh... without being children of the target. 

 

But here we are getting into physics... where the mass of each following object... determines its easing characteristics.  It would start to resemble physics "links" in many ways.  But still, I am seeing some real nice "easing" happening from AlexB and yourself, and I would love to see what we could get-away-with... in building a "rubber cord" linking that didn't need a physics engine.

 

In a way, camera .inertia is a physics thing... faking camera mass.  .inertia would also be a property on a FollowManager... and would affect easing, one would think.  Inertia would also affect "whip" / "overshoot" (if those things were possible at all).  And the velocity of the moved object might be a factor, or could be told to be a factor.

 

Lots of issues with a FollowManager, though.  Two primary problems are collision and physics (for things that are following), I suspect.  No concerns for camera and lights that follow (except if they have .inertia).  They can't be physics objects (but their parents can be).

 

But following mesh (mesh that follow)... phew.  I suspect we would get some less-than-optimal results if physics objects were allowed to have an active FollowManager.  For example, in joshcamas' demo, what would happen if the avatar was walking along a narrow alley with tall walls on both sides, with camera collision ON, with wall collisions ON... when the avatar turns 180 degrees to go the other way?

 

Without collisions, the camera would swing-around outside the walls, and if those walls had backfaces, you would lose sight of the avatar (player) until the player completed the turn.  This is related to joshcamas' thoughts about things standing/getting in the way of the view, but in this example, things are also getting in the way of the follow path.

 

With collisions ON, who knows what would happen?  As Dad72 mentioned somewhere, collided FreeCameras do slide-alongs when blockages stop the camera.  ArcRotateCameras don't.

 

Followers are a SUPER handy tool, but, there sure are a ton of issues involved, eh?  :/ And in general, "following" is not really a 'framework' issue.  Its a game-maker tool issue.  But ActionManager is similar in that way, so I think we're safe, and I think the Babylon.JS gods are still reading along... although they are likely laughing at Wingnut's goofy dreams. 

 

Thanks for the camera code, joshcamas!  Well done.  I think Dad72 was recently looking for a camera like yours. 

 

I think there can/will be many future versions of FollowCameras... and I think we want them all.  (greedy, eh?)  But in order to keep them organized, I think it might be wise to do a FollowManager with lots of cool knobs to adjust. 

 

Then we can put a FollowManager on ANY of our basic cameras, lights, or mesh.  THAT would be excellent... and likely an impossible dream...  maybe.    Thoughts, anyone?

[joshcamas]

Please remember that I basically did nothing, other than mash two bits of code into one

About collisions - remember that we don't want collisions per se - that would result in the camera hitting a wall as the player goes around it, and all sorts of messy stuff.

We need to make the camera always see it's target no matter what. Detect when there's a mesh or something in the way and get in front of it, basically. If that makes no sense here's a beautiful picture:

I don't know much about physics, so I can't say much about that.

 

I think that a follow manager is a way better idea than a followCamera as well - this allows for more editing, and of course more than just a camera, but other stuff.

I can't think of a specific reason a light or mesh would be extremely useful, but it sounds cool! xD

 

On a separate note, I'm having trouble making this camera more like a video game. I have tried enabling pointer lock on the engine, but that's messed up cause when you move your mouse all the way to the right or left, it locks. D: I don't want to have to drag the camera around all the time. :/

Also, in my demo your rotating-origin is the camera. Does anyone think it would be better for it to be the targeted mesh? So your always looking at the mesh?

One possibility could be:
*When moving mouse, camera moves around, but is always looking at target

*When holding down left-mouse and moving mouse, camera rotates like it does now.

Any ideas? All these would be options.

 

Also, don't put yourself down! I am brand new to 3D, and know next to nothing! Being a dreamer is better than having no dreams!

[AlexB]

joshcamas, perhaps the best way to approach this is to add a boolean property to the follower, defaulted to false, which if true would run an additional function on each frame update. Maybe not every frame even, but that could be another setting.

 

If you know two points in space, then you could start from the camera position and check for a raycast from the camera using it's direction. Away3D had something similar:

 

http://away3d.com/livedocs/away3d/4.0/away3d/core/pick/RaycastPicker.html

 

I wonder if this can be ported over to Babylon? Something like this could be useful for camera tricks as well as creating shooter games.

[joshcamas]

hmmm...

You can check to see if a mesh is in a certain location...

so maybe before each update...

raycast to the mesh...

and loop down the line picking for meshes...

 

I have no idea how porting works, however.

[AlexB]

Porting just means copying the code into Typescript and making it work with Babylon:-)

[joshcamas]

ik what it means, I just don't know how away3D works and such ;D

[AlexB]

For what it's worth, someone already ported Away3D to Typescript, and here's the Raycast class:

 

https://github.com/awayjs/awayjs-core-ts/blob/207a8993e636ecaab6b27921e8570e0f3c9075b7/src/away/core/pick/RaycastPicker.ts

 

If anyone has time to study it, we could possibly use this code.

[joshcamas]

Am I crazy or did you just change your avatar from orange to green? lol!

[AlexB]

I have no idea how that works.

[GameMonetize]

We have a ray cast engine in babylon.js

 

Here is a simple example:

http://www.babylonjs.com/playground/#QM57B

[joshcamas]

ahh so would one send rays from the camera,

then check all meshes in the area if they intersect? 

[GameMonetize]

yep