Hi
A number of users have complained after switching to 5.7 of a jumpy/glitchy viewport. These are animators that use control rig and also fur, so its relatively heavy on GPU and CPU - but I can reproduce it in the default starter level with just a cube and the landscape. See attached video. It’s was reproducible in the launcher versions of 5.7.0 and 5.7.1 as well as the VP partner stream of 5.7.
[Attachment Removed]
Steps to Reproduce
[Attachment Removed]
Hi there,
Thank you for the attached video and the repro steps. Even though it’s clearly evident in your video I unfortunately haven’t been able to reproduce this issue. I’ve made attempts with 5.6.1 & 5.7.1, both using the Epic Games Launcher and a source build of the engine.
Could you please provide any further information that could help in reproducing this issue? e.g:
Cheers,
Louis
[Attachment Removed]
Hi Louis
I found a good way to reliably reproduce it with specific mouse actions:
In 5.6 this works as expected, the camera instantly changes between zooming and orbiting, with no unexpected jumps.
in 5.7 there will be a camera jump, when you switch from orbiting to zooming or vice versa
I did this on a completely new project (Thirdperson template, startup level) from launcher version of 571 with no modified settings/plugins. It is also reproductible in asset editor viewports like the SKM editor and control rig editor. I also ge the jumps, but much less frequently when using WASD style navigation. I updated drivers to latest studio version 581.80 and same behaviour. The users experiencing this are on a range of driver versions from the past 6 months and a mix of hardware. Generally A5000 cards and xeon cpus on windows 11.
> Other processes that are running simultaneously.
I’m skeptical another process could be causing this as i can have a 5.7 and 5.6 project open simultaneously and can only repro the issue in 5.7. Hopefully you’ll be able to repro it with the above steps 
cheers
Luke
[Attachment Removed]
Thank you very much for the details so far they’ve been very helpful. However, I’ve been attempting to reproduce the issue again and I still haven’t been able to do so.
At this point I would like to submit a bug report for this. However if Epic is unable to reproduce the issue they are likely to not action anything. So in that case could you a bit more info to help epic narrow down the cause? Given that you are working with fresh projects I understand there isn’t much more to provide but anything that might help diagnose the issue would be helpful. Also, more specifically:
Thank you for your assistance gathering this info.
- Louis
[Attachment Removed]
Hi Louis,
Thanks for the hint. I tested it on i9-14900KF with RTX5090, Windows 10, and I couldn’t reproduce it there either. However it does happen on Xeon E5 with RTX 5500, Windows 11. I’m not sure if it’s the hardware or OS, but there is a difference
cheers
Marty
[Attachment Removed]
Thank you for your assistance gathering this info. I’ve submitted a bug report which you will be able to track here once it is available publicly.
Cheers,
Louis
[Attachment Removed]
Hello!
We would need and Insights capture of the editor to be able to research the problem further. The trace should allow us to determine the source of the hitch (CPU or GPU) so we can have the right people work resolving it.
[Image Removed]
You can open the Trace menu on the lower right of the main editor window. The default settings should provide enough information so you can just Start the trace from the menu item. Please capture for 20-30 seconds while reproducing the problem. This should give us a few occurrences to analyze based on the video you shared. The trace can be stopped from the same menu item that you used to start it. Once done, open the trace stors (red arrow) and send us the latest trace as an attachment to this case.
Regards,
Martin
[Attachment Removed]
Hi Martin
Attached a .utrace recorded with default channels. The glitch happened about 8 times during the last 20 seconds of this recording. I wouldn’t characterize the issue as a “hitch” - there is no freeze or stall or unresponsiveness. Its just the camera instantly jumps to an unexpected location. Hopefully there is something in the trace you can use
cheers
Luke
[Attachment Removed]
Hello!
Are you using the “Highlight objects under mouse cursor” mode? It can be enabled in the editor preferences under Level Editor -> Viewport.
Martin
[Attachment Removed]
Thanks for all the precisions. We now have an internal bug report that was accepted by the engine team. You can follow its resolution here: https://issues.unrealengine.com/issue/UE\-358382
[Attachment Removed]
Hi Martin
Saw this commit on ue5-main,
https://github.com/EpicGames/UnrealEngine/commit/8b1f296db88ce0daef02b2de97eab3407cb0183b
just wondering if you know if this was intedended as a fix for our issue or if it’s for something else?
[Attachment Removed]
Hello!
The change was not made in relation with the bug you reported. I reviewed the history of that code and I don’t think you want to try it. That file was part of some refactoring that involves a couple of changelists with multiple files implicated.
Sorry!
Martin
[Attachment Removed]
Hi,
The trace shows some small spikes in Slate’s TickPlatform from calculating the hit proxy to see what you’re clicking in the editor, which is what I’d expect to see if the mouse was released and re-clicked. Can you try enabling the Slate Console Debugger and reproducing this on your end? I’d be curious to see if there’s an unexpected MouseUp event happening, you can filter out some of the debugger input with the following console commands:
SlateDebugger.Event.DisableAllFocusFilters
SlateDebugger.Event.DisableAllInputFilters
SlateDebugger.Event.SetInputFilter MouseButtonUp True
SlateDebugger.Start
Then, keep an eye on the output log as you zoom and see if “Mouse Button Up” shows in the log. That would typically indicate a hardware issue, but since you’re having multiple people report the same issue there may be something causing focus loss; the Slate debugger might give us a bit more context. If you don’t any mouse up events, we’ll be able to rule that out.
Best,
Cody
[Attachment Removed]
Hi Cody
Thank you for suggesting an additional thing to test. I don’t see an unexpected MouseUp event, to my eye the order and type of events is equivalanet in 56 and 57. One difference I did notice is though that the delta value in 57 is always (0,0). Not sure if that is related or not to our issue
thanks
Luke
[Attachment Removed]
Attaching output log from 57. For some reason I couldn’t attach 2 files in above reply
[Attachment Removed]
Hey guys, I tried it a few more times and I get an impression than only the distance from the object jumps. The angle seems fine. [mention removed] is it the same for you?
[Attachment Removed]
Hi Martin,
No I wasn’t using that “Highlight objects under mouse” mode. When I turn it on I can still reproduce the issue.
[mention removed] For me I get lateral/orbiting jumps as well as truck in/out jumps. The zoom (as in focal length) does not jump. I was using term “zoom” earlier to refer to truck in/out, sorry if that caused confusion
[Attachment Removed]
Hey Louis,
Thanks for filing this in.
There is one thing in the description though. In the bug report you say that repeatedly zooming in/out causes the jump or repeatedly orbiting does that.
To reproduce the effect, you need to switch between zooming (actually trucking in/out) and orbiting. You truck in/out and immediately orbit, then orbit and immediately truck in/out.
The jump happens when you go from trucking to orbiting or from orbiting to trucking.
It feels as if the camera reset itself when going from one action to another, but only when you change the action very quickly
cheers
Marty
[Attachment Removed]