Matinee/Camera: FOV Value of 180 causes the engine to crash

Reproduction steps:

  1. Create a Matinee Actor
  2. Create a Camera for it
  3. Animate the FOV to 180 or above
  4. Unreal Engine will crash when it hits the point where it is 180 or greater.

I have a crash report submitted for this one.

May be related to: https://answers.unrealengine.com/questions/197178/ - different bug but could perhaps be fixed by the same commit.

Hey Xaymar,

Would you mind taking a look at our How to Report a Bug sticky on the forums, which will provide you with instructions on how to report a bug in order for the process to run efficiently and smoothly.

You have already provided us with some simple repro steps, which is fantastic, but whenever you receive a crash and want to report a bug, we will request your crash logs and .dmp files generated from the crash. We will also ask for your computers ‘dxdiag’ so we can determine if what you are experiencing is a hardware related issue as well.

To that end, I did attempt to reproduce the crash you are report, but was not able to get any sort of crash. Perhaps my steps differ from yours…

  1. Create Matinee
  2. Add new Camera Group
  3. Add Director Group
  4. Cut to Camera Group
  5. Added keyframe at 0 seconds for FOV at 90
  6. Added keyframe at 5 seconds for FOV at 200
  7. Added key binding to begin play of Matinee in level blueprint (M)
  8. Press PIE (Play in Editor) and Pressed ‘M’ key
  9. Wait for crash.

If my steps do not produce the crash you are expecting on your end, please let me know.

Thanks,

Hello Andrew,

here’s the info you requested:
Branch: Binary/Launcher
Build Version: 4.10.1-2791327+++depot+UE4-Releases+4.10
Detailed description of the issue:
Engine crashes when Matinee increases the FOV of a CameraActor to 180 or above, probably due to a rare NaN (unable to check as no debugger intercepts the crash before it happens). Been able to reproduce it every 1 in 10 with a keyframe at exactly 0s with 90.0 fov and one at 1s with 180.0.

The issue no longer appears in the current master branch, it was probably fixed by the same commit that fixed the other report, so this one can be closed as solved/duplicate. (I built the master branch with Visual Studio 2015.)

Sincerely,

Xaymar