A bit of an odd behavior I just noticed when launching my third person game: if I alter the aspect ratio of my game window, the camera’s default behavior seems to be to retain how much of the horizontal scene it can see…? The end result is that the wider my scene, the closer the camera wants to pull in to my player.
This is not desired; I’d prefer that the camera be defined in terms of its relation to the player. If the aspect ratio gets wider, we should be “revealing” the extra scene off to the sides, and retaining the camera’s distance from the player.
It’s not that I can’t adjust the camera follow distance to account for the difference between in-editor play and gameplay (since the editor window is 4:3 or close to it, while the main game is widescreen), it’s that the game design expects a certain camera distance, not a certain field-of-view, and it would be non-trivial to adjust the camera boom length based on any aspect ratio the user happened to set. And I would honestly expect this to be true of MOST games…? Is there some camera or boom variable I’m missing here that guarantees a fixed camera follow distance?
As it turns out, UE4 is hard-coded to fix Horizontal FOV, and cannot be told to fix Vertical FOV instead.
But since fixing Vertical FOV is probably something many games will wish to do, I’ve got a simple solution here that you can use, which uses the current screen aspect resolution to determine what the Horizontal FOV should be based on a given vertical FOV.
Note that in mine, I update the FOV every tick in case the window is resized. You don’t have to do it that way (though it doesn’t seem to have a noticeable performance impact…), though I should note that it seems to cause bad behavior if run from the character BP construction script.
To get the Vertical FOV multiplicant, take the Horizontal FOV and multiply it by the inverse of the aspect ratio. I use 67.5, because this value is what you get with the default 90 hFOV and 4:3 Play-in-Editor Aspect ratio. So this will let you maintain the in-editor camera distance when launched or running at any aspect ratio.
EDIT: Actually, this is still not an IDEAL solution. It works, but it uses horizontal FOV (i.e. fisheyeing) rather than simply adjusting the camera boom length. I’ll play around and report back.
Okay, NOW I’ve got a proper solution.
Here, what we’re doing is determining the ratio between the current aspect ratio and the desired one (“desired” here being the aspect ratio at which the camera distance is appropriate, i.e. 4:3 if we’re working with the Play-in-Editor camera as the proper distance, which we should be).
What we then do is scale the length of the camera boom arm by this ratio so that the natural zooming-in done by increasing the aspect ratio is offset. As luck would have it, just scaling directly like this provides what APPEARS to be a 1:1 correspondence in distance (if it isn’t 1:1 the difference is invisible to me).
Note that in order to make this work, we need a new float var which stores the “expected” boom arm length at the correct aspect ratio (i.e. the boom arm length which, when multiplied by a scale of 1, produces the desired length). What we’re doing is scaling the boom arm AT THE CORRECT RATIO to match the new ratio. We can’t just use the default value for Target Arm Length anymore since we’re changing it. So this new var needs to have the same default value as TargetArmLength (so when it’s multiplied by 1, it produces TargetArmLength as we expect). This ALSO means that any situation where we dynamically altered the boom arm length, such as pulling the camera in tighter over the shoulder when RMB is pressed or whatever, needs to instead be refactored so that THIS variable is set, INSTEAD of TargetArmLength. This way, those dynamic camera adjustments don’t attempt to overwrite the camera boom length being set by our aspect ratio correcter. This is, incidentally, why we multiply by a new var rather than just multiplying by the default TargetArmLength; using this setup still allows us to move the boom arm around in all the ways we’d expect.
Note that this ALSO lets the user still change their preferred FOV and it should work exactly as anticipated.
Man, thanks a ton ! This is exactly what i needed 
can you share the blueprint image again? the link is broken
1 Like
Hey, I’ve been looking for an answer to your original question for ages. Can you provide a blueprint example on your “proper solution” on your last post. Would help a ton.
did you find the link mate
