I just pulled and built with the latest changes from the Oculus Unreal fork - https://github.com/Oculus-VR/UnrealEngine on the 4.17 branch - there was an update 8 days ago. All seems back to normal to me, same as 4.16.2. I have changed all my supersampling stuff to set vr.oculus.PixelDensity.adaptive off and hmd vr.oculus.PixelDensity between 0.5 and 2.
@jimsnomis Well that’s good news. I hope this will be fixed in 4.18. You’re right that there’s still some stutter even with RenderThread set to 0. It’s less perceptible but still there.
Hey guys, just posted on AnswerHub relating to my issue (linked). I’m having a specific problem with Alembic’s Geometry Cache (Experimental), and performance in Oculus. The stutter is happening specifically when using varying vertex count mesh (a fluid simulation), and doesn’t actually happen with non-varying vertex count animation. So I’m wondering - because I turn off RenderThread through console command, is there something to do with a mesh updating every frame that causes this stutter and messes with the RenderThread?
Eep.
Well hot ■■■■. Just tested same assets in 4.15 and I don’t see any stutter whatsoever, supporting some of the theorizing going on in this thread that this is specific to 4.17.
Is this still a problem in 4.18?
Hi, I also have got bad performance issues in 4.17.2 as compared to in my case 4.15.
None of the suggested fixes in this topic have worked for me.
I think it is so weird that such an issue can come up through an update and is so hard to fix or is not being fixed more quickly. It is a critical problem, isn’t it? Are other developers not affected and is this a problem for just the few of us?
Anyways, if anyone has found new solution options or information on whether the issue has been identified by epic and is being worked on I’d love to hear about them 
I’ve been developing a project with vive for the last few months - all our vives are in use this week so I’ve plugged in an Oculus and have spent the entire day trying to get it to run - performance is sub 45fps, and latency even worse. I’ve never had any issue developing with vive so really at a loss why we are seeing this kind of thing with Oculus, on 4.18 and with the latest software.
One element that comes to mind is that until 4.16 UE4 was using the old Oculus Library (LibOVR, split into multiple components for HMD, Input, Audio, etc.) while starting with 4.17 it is using the new integrated Oculus Plugin (OVRPlugin). I wonder if there is a correlation between this change and the performance issues.
Can you tell if you are CPU bound or GPU bound?
stat unit shows poor performance across the board; It feels like a fault as even a test scene ( box and plane fully static) runs like a slide show.
I’ve been having similar issues since upgrading to 4.17.
It doesn’t seem to happen in play in editor, only in packaged build. When I try to run in packaged build it seemed like the framerate was terrible when being displayed on monitor, and I was just getting black screen on Oculus. Closer inspection revealed that general framerate wasn’t suffering, it’s the Oculus tracking that’s jittering. Animated actors in the backround were actually running smoothly, but the camera rotation was updating every half a second or so. It’'s as if the window is out of focus (it’s not).
Setting vr.oculus.bUpdateOnRenderThread to false fixed the jittering on the headset tracking, however there was still no display through the oculus, and also the motion controllers still suffered the same tracking jitter.
For me, it was an Oculus splash screen issue. We removed all blueprint references to enabling the HMD splash screen, and handled fading manually, as it just wasn’t fading back out for some reason. This fixed the stuttering and tracking issues, so no longer needed to use to console commands to fix them.
I can also confirm these problems, sneaking in post 4.16 (it seems). However, I believe it’s unclear whether they’re caused by Oculus updates, new GPU drivers, Win 10 creator update or maybe even UE related. All I can say is that the Oculus Rift had a heavy, mysterious performance impact a few months ago and there’s no official word on the reasons (or even acknowledging the existence of the problems).
This is similar to what we have been experiencing. Everything was much more stable until 4.16, then started to become unstable (with multiple crashes and occasional BSOD’s) with 4.17. This seemed to coincide with the switch to the new integrated Oculus Plugin, but could also be linked to a Windows upgrade, changes in the Oculus stack (server, client, home, etc.) or in the NVidia drivers. It is hard to diagnose because there seem to be few concurrent factors and not just one.
On one of our development machines (a high-end Asus laptop) we started to get a consistent crash after each VR Preview with a notification like “Application OculusVR.exe has been blocked from accessing Graphics hardware.” and a crash of the NVidia driver (nvlddmkm.sys).
From time to time Oculus seems also to loose its settings and asks to be set-up again.
UPDATE: I narrowed down some of my GPU crashes on the ASUS development laptop to the presence of the SkypeHost.exe process running in the background. Once this process has been terminated (after which I uninstalled Skype/Messaging through the PowerConsole) I don’t get any longer crashes/BSOD. Will keep monitoring and report back.
So, this thread is three pages long now. Starting in Summer 2017 (!), there still NO official word from Epic about the reported issues. How’s that even possible? Shouldn’t anyone at Epic read this and go “Uhmm… there seems to be a problem if so many peeps are complaining for months.” - Ignoring the subject doesn’t help us devs nor our clients who moan about the performance, stuttering etc. We can’t even give them an ETA for a fix. In fact, the problems weren’t even acknowledged.
How are we supposed to use UE4 for serious projects, if critical questions and reports are ignored for so many months?
I have noted good stability improvements with 4.18.2/4.18.3, NVidia drivers 388.59 and CPU overclocking turned OFF. 4.17.x still crashes like crazy.
If you have critical questions for serious projects, answerhub is your way to go
4.18.2 didn’t do anything for us, but it’s not about crashes anyway, but about significant post 4.16 performance drops, stuttering, tracking issues etc.
We have three Oculus Rift in use on multiple high-end rigs. So it’s most likely NOT hardware related. It may, however, be related to Windows updates, NVidia etc. - The point about sudden stuttering and performance loss started in Q3/Q4 2017 and there are multiple threads on the Oculus and Unreal forums regarding that subject. Yet, neither forum came with a reply from officials. Zero response. Just like on this thread.
Yea, I guess you’re right and I will do that. I was just surprised that there are so many people reporting issues very similiar to what we experience, yet there’s so few (i.e. none) official response on the boards. We’re running our business on this… and it’s very hard if you have to deal with issues that are totally out of your control or don’t even get acknowledged. Anyway… thanks for your tip!
After doing some more tests with multipls rifts, various sensors and PCs, I’m now very sure that the problem is NOT UE related. You can reproduce the jitter and stuttering on older engine builds (pre 4.16). So, it must’ve sneaked in with a Windows, Oculus or maybe NVidia update… or maybe caused by more than one source.
The stuttering gets worse the more complex a scene is. ASW set to on also increases the negative effect. On a sidenote: I can’t turn off ASW permanently. If I set it to off via the debug tool, it resets to “AUTO” every time I start OVR servce. If I use the Oculus Tray Tool (OTT) with auto-start on Windows launch, the OTT starts first, then the OVR service, resetting the ASW to auto again. Only chance to disable ASW for good is to launch the Debug Tool, AFTER I’ve started OVR service, disable it and THEN launch our VR app.
The whole Oculus experience is just a pain in the ■■■… They even removed the windows registry keys that once allowed you to permanently disable ASW.