Make camera track two objects at once?

I’ve got an attack the player can do in-game which causes him to throw his weapon, and then it returns to him, boomerang-style.

I’ve set the game up to properly spawn a physics actor for the weapon when it’s thrown (which allows its trajectory to be interrupted by objects in the world), which travels out and then back in. The problem is, the player camera stays centered on the player, which makes the weapon difficult to see unless it’s thrown more or less straight forward.

What I’d like to do is get the camera to pan and zoom out as necessary to keep both actors (the player character and the weapon actor) inside the frame.

Is there a simple way to do this? I could try to cobble together something by getting the location of both actors, finding the position directly between them, and offsetting the player camera by this amount… but getting the zoom to work properly would be a nightmare of guess-and-check and I’m wondering if there’s some sort of native camera function for handling this.

I’m really interested in this as well, just thinking of something you might want to consider as well as this though - if you add an offset to the camera so it points a little bit in front of your character you will see a bit more of that area. That might make the camera jump when making the character turn left to right so what you can do is add another camera which will be the actual game camera, set it to interp to the player camera which will make it a smooth transition.

You could do something like getting the average of the weapon and character cam’s transforms and making the camera interp to that as well. I have a handful of days of Unrealing behind me and not at my desktop right now so can’t test anything but that might be of interest to you.

Good luck!

Unfortunately (and this might not have been clear), my game does not use an attack-to-center-screen control setup. You attack the direction you press/are facing, the camera does not remain behind the player when he attacks.

This is part of what makes it challenging; it would be almost trivial to adjust the cam to allow greater visibility if the attack only ever went in one direction relative to the camera (not much different than whatever setup one might use for setting up a shoulder cam zoom-in in a TPS).

But when the player can attack in any direction, the cam logic needs to be more dynamic. If the player attacks forward, it might need only to move forward slightly to keep both the player and projectile in-shot. But if he attacks backward, it would have to move quite drastically backward. And if he does it sideways, or if the camera is overhead, it might not even be POSSIBLE to move the camera and keep both in the shot because of the attack range, and the camera would NEED to zoom out to make it work.

not sure it would work but some people did a tutorial (shame on me i don’t remember who) about using two cameras to change point of view (like 3rd person first person and top down on a toogle event click) maybe you can do that with a second camera focused on the projectiles but always wired to the character to replace the usual one for a delay or to the impact time then toogle again.

You should be able to use the averaged point, like you mentioned in your first post, for positioning. For zooming, yeah, that can be a bit more difficult but if you have a max distance, like, the weapon will never go any further than that distance, then you can work out a zoom pretty easy. Otherwise, you may need to work it out and cap it, so if it goes beyond, then it just doesn’t zoom any further.

I have an area where I track 2 characters and average the camera between them and then zoom in and out based on the distance between them. For my situation I actually have a max distance, so I don’t need to worry about capping it… etc. But in your case if you don’t have a max distance you’ll have to cap it so the zoom and tracking actually stop, or returns to normal.

So the way I have it set up to convert the distance into a usable FOV value is I divide by 50 and then add back 75, and that value feeds the FOV.

To explain the numbers I use comes from what I want my minimum FOV to be, which is 75 and the 50, comes from what the distance need to divide by and add 75, to get my maximum FOV, which is around 90 max FOV.

So, my distances is at max around 900. So 900 divide by 50 is 18 plus 75 is 93. Then at minimum distance it’s maybe 20 or so. So 20 divide by 50 is 0.4 and plus 75 is 75.4. So my FOV stays within tolerance.

Can’t say for sure without actually seeing your scene in action how this would work out for you, but maybe it helps you come up with a workable solution for your setup.

Hello. Another idea in case you are stuck. Why not a minimap camera from the projectile/weapon point of view you want to show. Player will can see himself as usually and what happens to his shoot. And you can add some overlapping reaction when it comes back like red lighting.

Obhib: I like it, though I’ll be using boom arm length rather than FOV for the effect because I don’t want to fisheye (the cam is far enough from the player already that adding some distance won’t seem out of place). The attack does have a max range, though it won’t always reach it (the projectile can be blocked), however what concerns me is that the zoom cannot be calculated JUST by actor-to-actor distance. It has to be actor-to-actor distance AS A FUNCTION OF ANGLE, where the zoom is tempered around the forward-backward axis and exaggerated around the left-right axis (and when the camera is more overhead). Otherwise you get the unwanted effect of extreme camera zoom-out when it’s not necessary because the zoom-out was designed to accomodate angles when it WAS.

I guess I was just hoping that there was native camera control stuff for this, it seems like the sort of thing one might often want to do (keep two actors in view regardless of camera orientation or their position).

The good news is the effort I spend on this won’t be totally wasted because whatever maths I hack together to handle it will also be extremely relevant for a lock-on system.

Fen: A fine idea but not really fitting the aesthetic or style of my game. Makes sense for like a fly-by-wire missile type projectile but this is more like a really long-range melee attack.