Thanks for testing, here is the dxdiag as requested.
Interestingly my friend has a nearly identical system (R290 non X) and cannot replicate the issue either.
I see that a slightly newer version of your graphics card driver is out (version 14.4). Could you install it and retest? Make sure you don’t download the Beta driver, because they are generally unstable.
Just wanted to make sure that this is still on someone’s radar at Epic. This is a showstopper when working with the Oculus. It’s bad enough on the PC but really bad on the Oculus.
We are facing the same issue with a Nvidia GTX 790 and same with Nvidia GTX 570. We are running UE4.2.1.
Our scene is quite heavy so just to make sure I’m running PIE with r.screenpercentage to 50 to make 100% sure I had enough horsepower and the problem still occurs (less often though). I tried to limit the FPS to 60 and still also have issue. I think the problem occurs when the framerate fluctuates. I’m going to compare the FPS with maybe the position of the camera and try to confirm that they are directly linked. I will come back and post the results soon link text
What UE version are you using?
After some investigation I think its related to the way EPIC calculates the position of the spring/camera. The method’s math is based on your framerate and works well if it is stable (which is a bad assumption as framerate always drops somewhere even for a fraction of a second). If the frame rate fluctuates too much the positioning of the camera can be incorrect for a frame or two hence the stuttering. If you set a histogram based on the framerate you will notice that there is a direct correlation to ‘strong’ fps fluctuation and this stuttering effect although I noticed sometimes only a ~3fps fluctuation is enough to cause the problem.
In other words the stutter you see is not directly because of framerate fluctuation which mostly goes unoticed by our brain but its because the math to position the camera assumes a certain framerate to know where to place the camera and sometimes that assumption is wrong, it has nothing to do with your graphic card or drivers and everyone is affected by it if the conditions framedrop+enough speed to notice it are met.
It would be great if Epic could change the way they handle the update rate, I also love the effect!
glad someone got to the bottom of this problem I gave up months ago 
I think you are correct though as my PC specs are pretty cack in the grand scheme (gtx 470 and quad core Q6660).
I just made my own camera system in the end anyway as the spring arm with the lag enabled isn’t very good for 360 rotations, horrible gimbal locking going on. Need quarternions rather than euler rotation.
Bumping this - has any progress been made as to a solution? Gets pretty bad at times.
Hi ,
This is still being looked into by our developers but it has moved up in priority. For future reference here is the number for the issue in our tracking software: JIRA #3685.
Cheers,
TJ
Nice that someone is on this! I’ve got the same problem. Look forward to a fix going through!
Also, where do we find the JIRA database to check progress on the fix?
Hi rcdarcey,
Currently our JIRA database isn’t public, but this may change at some point going forward. As for it’s status, I’ve messaged the developer that is working on this issue and I hope to post an update here after the holidays.
Cheers,
TJ
Great to hear that, the effect is fantastic on our vehicles if you overlook the stuttering issue of course.
I also have this problem when using the spring-arm for a vehicle. I replaced the interpolation code with some custom smoothing code of my own which is proven in previous projects and I also checked the algorithm using a spreadsheet model with different frame rates - which it passed.
However, I’m still seeing jittering of the camera connected to the spring-arm, albeit much reduced from the jittering produced by the standard spring-arm interpolation code.
I can only assume that the car itself is jittering about and doesn’t have the smooth, linear velocity across frames that the numbers would have us believe. Is the actual rendering position of the car for any given frame the same as the physics position of the root bone?
I have an Nvidia 760M for the record.
Hey everyone,
I’m sorry it’s been a while on this issue. The investigation of several non-critical bugs had to be delayed while we prepped for GDC and this was one of them. We plan to investigate this issue soon and will post back here with updates.
Cheers,
TJ
I haven’t had the occasion to test it out yet but I think there was some kind of improvement done in 4.7 no?
Here’s what I saw:
New: Added substepping to camera Spring Arm Component to address variance at different frame rates.
Is this a temp solution or is this for something else?
You’re right, there was some improvements made in this area in 4.7. We retested this after that fix went in and we were able to reproduce some ‘jittering’ in certain scenarios, so we reopened the issue to investigating it a bit further.
Hi TJ Ballard,
Any update on this issue yet ?
I am on 4.12.5 and the jittering when camera lag is activated is still there… I confirm that it is somehow related to frame rate and it happends both on desktop & laptop.
Even when you do not use spring arm, it jitters for some reason. I tried to APlayerController::SetViewTarget to watch other’s player pawn (in a multiplayer with dedicated server and listen server) walking around, it jitters with or without blending turned on. (Also no camera lag enabled on pawn’s cameras)
And yeah, I’m using 4.13.1, problem still persists I’m afraid, trying to get to the root of it myself.
, expand the advanced properties in the “Lag” section of your spring arm component by clicking the small down arrow at the bottom of the section in the editor. there are settings in there to help remove the jitter caused by variable framerate.