UE4.9.1 does not recognise Rift with, and has game breaking performance with

Hoping someone can shed some light on this -

Updating from 4.9.0 to 4.9.1 stops UE from even recognizing that a HMD is attached, with “VR Preview” greyed out. I figure this is maybe because Epic wants to push people to use runtime, so I updated from to

VR preview works, but with framerates down to 50fps from a solid 75 in worst cases, and from a solid 75 to 71-74 in the best case.

I’m not sure if the culprit is the runtime update or 4.9.1 update, but I’m just wondering if Epic knows of this issue and if anyone else is experiencing it.

Also, I’d like to know if the incompatibility between and UE4.9.1 was intentional? With UE4.9.0 and, performance was hitting a perfect 75 at all times.


One of the changes to 4.9.1 was the integration of the new 7.0 runtime. So yes, that was definitely going to happen.

But your also right, the performance did take a fairly severe hit. Three projects of varying complexity just won’t hit a solid 75 in certain areas anymore, ran more than fine previously. I feel like things are going to be really, rocky for the independent developers leading up to the 1.0 runtime at best.

Thanks pixelvspixel, I’m glad I’m not the only one.

So I just went back through and double checked, it is definitely the combination of runtime and UE4 version that is causing the perf hit. My GF driver is up to date on 355.84. I understand the risks of being on the cutting edge of hardware and software development, but I’m disappointed as 0.7 was supposed to be a shiny new update, what with the purging of extended mode and the addition of direct driver mode. This is a serious step back in optimization, and seems to have undone the gains that provided, which were a huge improvement.

Is there any official word on this, from guys at Epic or from Oculus?


I’m experiencing the same problem. The same project that on 4.9 and 0.7 had a solid 75 frame rate now with 4.9.1 has judder. I have to use hmd pd of about 0.8 to get it to the same fps as before.

Can I ask if you are experiencing this slowdown on a fresh reboot?

There is a known bug in 0.7 runtime that causes severe performance issues on the second run of any VR application.

Sizable increase in frame time, not sure if 0.7 runtime or 4.9.1, just posting to raise awareness. Hope this performance hit doesn’t go on for long as I’d like to stay on the edge of updates!

Seems to be bad on a fresh boot on my hardware as well @!

Yes, after several reboots the performance issue is still present. Thank you for asking.

Hey ,

Is there a source for this news?

My 4.9.1 with 0.7 project runs consistently poorly; I tried diagnosing the issue by installing several different runtimes which require a computer restart each time, so this bug is not the issue.

Safe to assume the bulk of us in here are on nvidia drivers?

I’m using the Nvidia driver on Windows 10.

I’m using AMD catalyst 15.8 beta and having the exact same problem.

It seems that the recent Nvidia drivers update improved my situation and the frame rate went up.

you mean the new 355.98 drivers? or are there any newer drivers yet?

Yes, I mean the 355.98. I found about the latest update yesterday.

355.98 didn’t resolve the issue for me.

I’m getting 75fps most of the time, with PD @ 0.9.

However, when I look in certain directions, I suddenly get 37fps. Its like the v-sync is automatically *halving *the framerate, rather than just letting it go to where it ought to be. The framerate is either 75, or its 37.5 (with a microscopic variation), but never anything else…


Just to clarify - the performance difference between the low and high complexity areas in mono rendering is 120fps to 115/110fps. OVR is clearly doing something boring here…

What kind of GPU do you have? I was having some issues like this with my Nvidia 770 GTX but I was able to get everything running again at 75 on my DK2 with the following drivers and settings.

NVIDIA Drivers: 350.12
Oculus Version:
Current Screen Percentage: First in the UE console type showlog(make sure there are no spaces) to active your log. Then type r.ScreenPercentage to see what the current Screen Percentage is set to. It should be set to 130 by default and that is what you should see in the log. If it is not set it to 130 by typing HMD SP 130 into the console and then check to see if you are running at 75 FPS or not. If that does not help then try HMD SP 120 and see if you can get back up to 75 FPS after that. If that still does not work try HMD SP 30 and see what your FPS is. If setting HMD SP to 30 still does not get your project up to 75 FPS then there could be something outside of UE4 that is causing the issues. Please let me know if you get it working and if not we can try and figure out something else.

Thanks for replying Sam, I’ll get on that troubleshooting right now and get back to you within an hour or so –

My GPU is a GTX680 4GB,

One thing though, your driver is not the onerecommended by Oculus for the runtime 0.7:

Does this mean that the direct driver mode is not actually necessary? My technical knowledge of this kind of thing is admittedly lacking, I assumed that the two (runtime and nVidia driver) needed to go hand-in-hand.

Edit - r.ScreenPercentage does not change anything in stereo, the command there is HMD SP, right? Should I be using that instead?

Edit 2 - showlog window states that HMD SP is an unknown command when I type it on it’s own. Setting HMD SP to a number makes it work though, so I’ve deduced that the default HMD SP is 100, and setting it to 130 drops the framerate from a choppy 75 to a solid 50, as if it’s being synch’d. Bringing it down to 80 brings back the performance to how it was on 0.6 and 4.8 / 4.9.

I’m going to install 350.12 now to see if that increases performance.

Edit 3 - I made a mistake with Edit 2. After installing 350.12 and testing, and then re-installing 355.98, I can now reach a HMD SP of 110 with a solid 75 fps. I had forgotten to turn off a test feature I was working on that isn’t optimized yet.

So in summary

  • Lowering HMD SP does make the game renderable. If 130 is the default value then setting this to 110 achieves the same performance as I had with 4.9.0
  • A particularly CPU heavy feature that ran fine on 4.9.0 w/0.6 seems to hit performance harder in 4.9.1 w/0.7 (no matter the screen percentage value)
  • 350.12 and 355.98 have comparable performance (though when there are frame drops in 350.12, there is a strange tearing artifact on the Rift’s right eye. Frame drops appear simply as jitter on 355.98 with no tearing. This visual artifact is only present in the Rift display and not on the monitor displaying the Rift’s feed)

Hey Mechanicalsnowman,

Thanks for testing this and getting back to me with the results. Let me clarify a few things as it looks like I did in fact give you some incorrect information.

Does this mean that the direct driver mode is not actually necessary? My technical knowledge of this kind of thing is admittedly lacking, I assumed that the two (runtime and nVidia driver) needed to go hand-in-hand.

I have no idea about direct driver mode but I can look into this and see what more info I can get about this.

One thing though, your driver is not the one recommended by Oculus for the runtime 0.7:

I tried the 355.83 drivers and I could not get my HMD to attach to UE4 in VR. I was able to get everything working using the 350.12 drivers so I just rolled back. I have not tried the latest ones again because I was in the middle of working on something so I just needed things to work and that is why I used the older version because I knew that one worked. When I get some more time to dig deeper into this I will have a look and see if I can figure out what is going on.

r.ScreenPercentage does not change anything in stereo, the command there is HMD SP, right? Should I be using that instead?

This is correct however what r.ScreenPercentage does is tell you the current screen percentage and that is what I wanted to know. However now that I am re-reading my post I was completely wrong in saying use r.ScreenPercentage to set your Screen Percentage and you should in fact be using HMD SP (Number you want to use) command. Sorry about that it completely did not register that I was using the wrong command when I was writing the response as I was thinking HMD SP in my head but was actually writing r.ScreenPercentage. Also adjusting the HMD SP should be the last thing that you do when trying to get your game to run at desired frame rate.

Thanks again for testing this out and positing such detailed results. If I figure anything else out I will make sure to let you know and if you figure anything else out please respond back to this thread so that I can track it.


Sam Deiter

Here is the reference for the 0.7 performance issues I mentioned previously:

The second link is especially a good read. But in a nutshell there is a serious bug in the 0.7 runtime that causes extremely high CPU usage from a generic “SYSTEM” process, essentially sucking down an entire core.