I searched for a similar thread and found none, sorry if this has been covered.
I have a good size map with a lot of BP that has been working perfectly in 4.17 and 4.18 a long time. No errors, no warnings, squeaky clean. When I open it in 4.19.0, same thing no errors or warnings, fully functional, packages to an EXE that performs perfectly like it did with 4.18. In 4.18 I’m getting a solid 70-80fps in the editor viewport.
However in 4.19 the entire editor hangs/freezes momentarily about once every second. The viewport, interface graphics, the log window - everything, like it’s a graphics driver(just a theory). It is subtle at first, but the longer the editor stays open the worse it gets and the “pauses” get longer and longer. The FPS still shows about 70 but of course freezes with the screen and recalculates every after every pause again. It happens during preview play as well just as bad, and makes player capsules lag during the pause and create false collisions, etc.
Basically the editor is unusable. It does not stutter with say a single UE4_Mannequin in a blank environment, but that is running at a pegged 120fps because of virtually no/textures so it points to a graphics again. I have a fast 4ghz+ PC and 980GTX running the latest drivers, and the last three drivers have had the same stuttering in 4.19.0. My hardware has never been an.
Once again, runs smoothly/flawlessly in 4.17 and 4.18 and opens and “functions” flawlessly in 4.19.0 - except the stuttering screen freezes.
Is anyone else seeing this crippling stuttering?
Please verify or advise, what’s going on? Is this a 4.19 bug or are Nvidia drivers crap for 4.19 right now?
I got once an ocasion where I have changed a material (ocean one) and the whole screen was like you described. The only solution was to close the editor and open again. After that I didn’t see it happen again, but that left me really worried. I might get in touch at that same map and material again and see if it is consistently reproduceable or not. Seems like not worst than yours, but definitely turns the editor unuseable as it gets worst after some time.
Thanks Nilson, interesting. It definitely happens every time I open the editor, starts almost not noticeable and gradually becomes much worse. I don’t see any relation to a fancy shader either.
Very strange, please any one else comment on this and possible cause and fix.
When it’s giving you this problem, what does your Task Manager==>Performance page look like(cpu/gpu/mem/hdd)? What do your temperatures look like(could be thermal throttling? Are you running out of ram? If you are, then it could be stutter coming from HDD thrashing the page file. Are you simulating the viewport, if so, could it possibly be some bad blueprint of yours that has a glitchy loop in it?
This would be one of those test questions where the answer would be D) Not enough information.
Plenty of RAM overhead - 10gb remaining out of 24, CPU is chilling at about 29%. About the same stats as when running it in 4.16-7-8 where it has always been(and still is) smooth as silk. Seems to not be related to machine performance at all. (Except it acts like a “4.19 hates the graphics drivers” issue as originally stated)
Glitchy BP? Who knows what evil lurks, but everything has been performing squeaky clean to date and they all look and function clean, so so why simply opening in 4.19 does the editor stutter worse the longer it’s open? It happens ALL the time, not just during simulation while BP’s are running, so that tells me it’s not a bad BP.
I can just open the Project, let it sit there and the stuttering goes from barely noticeable to drastic freezes. Manipulating the viewport, scrolling the log, everything. 4.19.0 introduced something funky, but what is it? It seems to hang every second, like clockwork. A clue there?
I’ve gone through everything again and just can’t find anything “wrong” with the Project itself causing the hanging. I really think it is rendering/graphics/viewport at the root of the problem. Hiding the viewport with another tab/window makes all the stutter go away from all other open windows. The viewport rendering is causing the stutter, everything is pointing to that, I’ve had Maya and Motionbuilder run awful with a new rev. that hated current video drivers similarly.
As I mentioned - 980GTX with last three current drivers has identical problem/symptom. I know Epic played some games with up-sampling and AA for 4.19, I’m wondering if they changed some default Project rendering setting or such viewport code that is causing a problem on my specific card. I can’t be the only one.
If Epic (or anyone) can please suggest or think of what was tweaked and/or new default//render 4.19 settings that could be affecting my viewport so adversely, I’d really appreciate the input.
Hmmm, yeah, it could very well be a driver then, but I don’t know. One last thing to check: Open up the task manager, open up the performance tab, click the open resource monitor button. Open up the disk page, sort by “Total B/sec” and see if anything is using the hard drive like a virus scanner or other programs.
Also, what kind of temperatures were you getting up to on your CPU and GPU? It’s possible that you need to clean fans or check thermal pastes. You say it does it every second or so, and if it’s not something directly wrong with the project(bad loops, etc) or with the hard drive thrashing, that screams thermal throttling to me.
I just know that I’ve actually found 4.19 to have a massive increase in performance on this laptop and find it odd that you’re having problems with it.
Now that [USER=“37063”]Motus Digital[/USER] mentioned, it might be a driver since I have recently updated mine for 391.35 (NVidia) and I have a GTX 1080 in this machine. If I can reproduce the same again in a consistent way, I will try rolling back the driver version and see if it persists.
Just chiming in here with a similar experience. I’m also getting a stutter/hiccup on 4.19 every 30s or so for a quick second, then it recovers. Usually only after the editor has been open for about 30min. Nothing odd in task manager. The stutters are either too quick for them to show up on usage stats, or Its not affecting my PC at all.
I’m at work and don’t have my PC driver specs handy, but its any map, any circumstances. Happens on both launcher build and source built version. I originally thought it was because I had both builds installed and didn’t really think anything of it until I saw this thread. When it starts to bug me, I have just been saving and re-opening the engine.
No effect on any other software, just a quick hiccup in the engine itself. I can check driver version later tonight. (also Nvidia though)
I’ve got a similar experience in a packaged build. It eventually started freezing progressively longer exactly every 3 seconds, nothing in game could fix it until restart.
Profiler showed it taking an incredibly long time in ComputeLightGrid, so I added more profile zones there to track it down and since then it never happened again…
Thanks for everyone’s input, a common thread here but hard to tell if they are all the actual same.
I don’t have temperature specs, but as I mentioned I am running at 29% and lower CPU with lots of RAM overhead, no unusual and extremely low Disk activity. When Building lights the CPU pegs 100% and my fans kick into high gear noisily, so I no there is no thermal. My specific 980GTX video card and all current drivers the culprit? Who knows.
So to be a broken record, no unusual hardware activity, it just putts along normally. Hiding and showing the viewport turns off/on the stutter in the rest of the editor like a switch (like a video/graphics/driver problem). Unchecking “Realtime” turns off/on the stutter in the editor like a switch. I have never un-checked the “Realtime” in any version of UE4 for years - except in 4.19 as a last resort, and of course simulating it returns as Realtime is back on. And a Packaged exe runs perfectly, no problems, only the editor hangs.
I appreciate everyone’s eyes on this so far.
So what is the viewport in 4.19 reacting to that hasn’t been an since 4.16? Once again I implore Epic to suggest a rendering/viewport setting(or?) to hopefully negate this new incurred behavior in 4.19, hence the reason I am posting in this “Epic Feedback” forum.
DIRECT CAUSE OF PROBLEM DISCOVERED - EPIC “PICKUP” PARTICLES
After hours of detective work and deleting BP and everything but the kitchen sink out of the Project - the problem was the kitchen sink, the free **Epic ShooterGamePack Particles: **
“P_AssaultRifle_AMmo” and “P_Health”
Remove these from my custom Pickup BPs, issue disappears instantly. Without removing the particles, the frequency of the “stutter” drops in relation to how many instances in the Map. With only one containing Pickup in the scene it hangs hard about every 10 seconds. This was the problem all along, pretty dramatic and crippling affect on a Project. Good grief, what a waste of two days.
I was able to replicate it by adding 70+70(to get the quicker stutter frequency) instances of them to a blank 4.19 Project with nothing in it but the particles and associated meshes and material. A noticeable hang around every second. (Your hardware may produce a different timing) Please download the 4.19 Project “ParticleTest” and see for your self(or not?), leave it open about five minutes and the rotating particles will start pausing. Unless once again my PC is super special and hates 4.19 individually…
I tried replacing the Ammo/Cross meshes with the default “no mesh” cube in the particles, but same result. It seems the particle system itself is causing the problem, not its referenced mesh.
I suppose I can simply put a static mesh in the pickups, but not as snazzy as a rotating particle. Sucks. Better ideas anyone?
EPIC: Why do these stock particles hangup and bring 4.19.0 to its knees? I will be submitting this as a bug.
I tested the project but got no issues, also I didn’t touch Windows updates or the driver version… it must be something else… I would suggest to you rollback a driver version if it is not the latest one installed, there was a release for NVidia drivers with optimizations for Fortnite (not the last, but the previous one if Im not mistaken).
I do feel the scene has a timed consumption of resources and the FPS drops like 20 FPS each 2-3 sec aprox.
I tried as well and definitely saw the stuttering. I believe I’m getting something similar but no where near as frequent and bothersome as that. gtx970 on driver 391.35 fwiw.
Seems like it is a graphics of some sort, I’ll try rolling back 4 versions since it has happened last three. Plus the fact that you are getting a “timed consumption of resources and the FPS drops like 20 FPS each 2-3 sec” tells me there still might be something universal there, just not as drastic on your hardware as mine.
So far I have replaced the offending Particles with static mesh and rotating them with a looping Timeline, turning off all shadows/indirect lighting/etc. has my simulation apparent overhead as low as it was with Particles(fps is as high as before). That may be my fix till I can get more corroborating evidence with the particles evil or lack of it.
Bottom line, Particles no prob 4.18, Particles big prob 4.19 - which means there is something going on Epic changed regardless of it affecting my machine(and likely others with similar) only as far as anyone has reported yet.
Thanks all, I appreciate everyone’s attention and efforts on this.
I have reported the bug FWIW, we’ll see what happens and how long it takes to find out what the real deal is. Reproduce-able bug, driver, something else, or my machine is a delicate rare flower that just doesn’t like 4.19. :rolleyes:
FYI the video I made and sent to Epic, if you want to see what I am seeing FWIW.
After seeing your video, I entered the project again and waited, waited, and the hiccups started to appear. The gap from the FPS at the hiccups increased and I found another thing interesting: while the editor is open (not running or simulating) if you click outside the editor in a way for it to lose the window focus (ie: you can click on Windows’ Toolbar in the bottom) and then click in the editor again, you will see that the FPS presents a large difference from what it was before. To see the regular FPS back, the only way is to run or simulate. Im rolling back the driver just as an experiment.
PS: I have rolled back 5 versions back and the still there, so one can really reproduce it. As soon you get the number, let us know, so we can vote on it for fix priority
