Please apply widescreen adjustments (FOV) to FlyBy camera also

[Hyper]

I switched to an ultra wide screen setup (21:9) and Unreal really handles this nicely. (Fov 120 for me atm)
However, it becomes quite noticeable that the FlyBy camera does not properly use the new FoV value causing a lot of vertical cutoff. You can simulate this by running Unreal in a letterbox sized window, apply a proper FoV and then type "open unreal" in console.

[Masterkent]

It seems, InterpolationPoint actors override user's FOV settings by applying FovModifier to the default FOV (90 degrees?). Such actors are also used, for example, on level ExtremeEnd, and the given effect can be observed there too.

[Hyper]

Can this be changed? Or will that break other things?

[.:..:]

This technically can be fixed, by rather then setting FOV to match exactly the value of InterpolatingPoints. Instead check the FOV scaling value of IP, then set player FOV to DefaultFOV multiplied by the scaling value.

[Hyper]

I never knew that interpolation points had their own FoV setting.

[Masterkent]

This technically can be fixed, by rather then setting FOV to match exactly the value of InterpolatingPoints. Instead check the FOV scaling value of IP, then set player FOV to DefaultFOV multiplied by the scaling value.

I think, it should be something like

FovAngle = atan(tan(InterpolatedFov * M_PI / 360) * tan(DesiredFov * M_PI / 360)) * 360 / M_PI

where InterpolatedFov is the angle produced by applying FovModifiers of InterpolationPoints to the base FOV value (90 degrees, as far as I can see). I don't know how exactly that angle is calculated in the current implementation (it's not in UScript).

[.:..:]

Well the InterpolatingPoint FOV modifier seams to be a scaling value instead of FOV angle, so that means we can simply go with this:
[code]((APlayerPawn*)this)->FovAngle = (Dest->FovModifier * (1.0 - PhysAlpha) + Dest->Next->FovModifier * PhysAlpha) * ((APlayerPawn*)this)->DesiredFOV;[/code]

[Masterkent]

Well the InterpolatingPoint FOV modifier seams to be a scaling value instead of FOV angle, so that means we can simply go with this:
[code]((APlayerPawn*)this)->FovAngle = (Dest->FovModifier * (1.0 - PhysAlpha) + Dest->Next->FovModifier * PhysAlpha) * ((APlayerPawn*)this)->DesiredFOV;[/code]

There is a problem with such a multiplication, because FOV angle is not something that we can scale linearly. An alternative representation of the horizontal FOV angle is the ratio of horizontal projection to frontal projection of a point that lies either on the left screen border or on the right screen border. Unlike angles, this ratio is often scaled linearly when a user wants to adjust horizontal FOV for a wide screen with preserving the same vertical FOV as if we had for 4:3 display and horizontal FOV of 90 degrees (in this case vertical FOV = 2 × arctan(tan(90°/2) × 3/4) [ch8776] 73.74°).

For 16:9 screen we have the corresponding horizontal FOV angle 2 × arctan(tan(90°/2) × 16/9 / (4/3)) [ch8776] 106.26°.
For 21:9 screen we have the corresponding horizontal FOV angle 2 × arctan(tan(90°/2) × 21/9 / (4/3)) [ch8776] 120.51°.

When preserving the same vertical FOV, the tangent of the horizontal FOV angle grows proportionally to the width/height ratio, while the angle grows unproportionally to that ratio.

Now suppose that a mapper decided to set FovModifier of an InterpolationPoint to 1.5 that normally corresponds to 90° × 1.5 = 135°. How should this multiplier (1.5) be applied to the initial horizontal FOV of 120°? Should we just multiply the angle itself or probably multiply the tangent of its half as shown above instead? Let's see what we get in either case:

I) 120° × 1.5 = 180° - insane FOV, we'll get a random bunch of pixels instead of an image.
II) 2 × arctan(tan(120°/2) × tan(90°/2 × 1.5)) [ch8776] 153.10° - scaling the ratio between projections gives a reasonable FOV value. In the middle 4:3 vertically fitting area of a 21:9 display the image should look like it would be displayed on a 4:3 display.

So, I'd suggest to use something like this:

[code]double InterpolatedFov = 90 * (Dest->FovModifier * (1.0 - PhysAlpha) + Dest->Next->FovModifier * PhysAlpha);
InterpolatedFov = Clamp(InterpolatedFov, 0.1, 179.) * M_PI / 180;
double DesiredFov = Clamp(static_cast(this)->DesiredFOV, 0.1, 179.) * M_PI / 180;
double Fov = 2 * std::atan(std::tan(InterpolatedFov / 2) * std::tan(DesiredFov / 2));
static_cast(this)->FovAngle = float(Fov * 180 / M_PI);[/code]

[[]KAOS[]Casey]

not to mention there are other ratios like 5:3, 16:10, 21:10 etc..

[Masterkent]

Probably, PlayerPawn.UpdateEyeHeight should be modified (in addition to the above). Namely, in

Code: Select all

if ( FOVAngle != DesiredFOV )
{
      if ( FOVAngle > DesiredFOV )
            FOVAngle = FOVAngle - FMax(7, 0.9 * DeltaTime * (FOVAngle - DesiredFOV));
      else
            FOVAngle = FOVAngle - FMin(-7, 0.9 * DeltaTime * (FOVAngle - DesiredFOV));
      if ( Abs(FOVAngle - DesiredFOV) 
the first condition should be changed to


Code: Select all
if ( !bInterpolating && FOVAngle != DesiredFOV )

Last edited by Masterkent on Sat May 07, 2016 6:00 am, edited 1 time in total.

[Hyper]

I don't understand a bit about the code, but I'm happy to see that it is being considered / worked at. :-)

[Masterkent]

I don't understand a bit about the code, but I'm happy to see that it is being considered / worked at. :-)

Without proper checking, the resulting implementation can be worse than the existing one

[Hyper]

I don't understand a bit about the code, but I'm happy to see that it is being considered / worked at. :-)

Without proper checking, the resulting implementation can be worse than the existing one

I consider this to be true without hesitation. :-)