It’s been about 3 months since I dabbled with Unreal4. I fell in love with the blue prints system and the cheap subscription scheme but ultimately had to drop it because of the way it worked with the Oculus. I found getting anything below 75fps a real struggle, anything with textures or lights and it would be going to around 35. Of course you could tinker with multiple settings like hmd, mirror, etc but most often then not the only way to make it run at 75fps would be to lower the hmd to something like 50, resulting in blurred pixelated graphics.
After a few months I tried Unity and straight away it worked like a dream. It just worked! No messing around with settings. Clear and fluid. Yet, I miss the visual scripting (that is well supported with tutorials everywhere) and payment scheme.
Has any effort been made in the last few months to improve Unreal’s compatibility with Oculus for casual users such as myself?
The main problem I think with UE4 versus Unity is that Unity is very minimalistic as far as graphical fidelity. This leads to higher frame-rates which leads to better performance. Unreal prioritizes graphic fidelity, which decreases performance. There is a WIP on the trello where Epic is trying to release a VR template that they use when creating official demos; that will be a great help.
There is a VR template that (I forget his name) created, this might help; although, I am not quite sure how far he got with the settings.
Yeah I did dabble with that VR template but it was a bit too complicated for me (as someone who has hardly ever used Unreal or does any sort of programming). It built an entire level filled with stuff and I wasn’t sure of what I could delete and not. What really needs to happen, hopefully Epic do go ahead and do this, is to create a template where you just answer a few questions in a menu (or adjust options) and then it builds an empty level with adjusted settings based on your preferences. Hopefully that’s possible!
I wonder if there will be any optimizations done on the VR end as well. We are currently developing a demo, performance isn’t that important at this point, however we can’t move on to full production until this is solved or otherwise consider another engine. I’m a user of unreal engine since 2010, and I want to continue using it but if performance issues can’t be resolved I will have to switch.
A few things you will want to look at is static lighting and static meshes. Dynamic lighting will kill you on fps, so make sure that it is static for everything you can. Also, remove reflection spheres if you are using them.
The better question to start with is, what hardware are you running this on? CPU and GPU.
There is a whole lot dependant on the way you design your game, Epic worked their buts off when they worked on Oculus Showdown demo, where they needed to hit 90Hz and look good, in fact they needed to look better than anything seen in realtime VR to date. That said, I understand the core of you question, why doesn’t it just work better out of the box? Well I think it works pretty well given the visual result, but it could always be better, I can assure you that there will be a whole bunch of work done in this area in the future. For one, I’m experimenting (and I’m sure I’m not alone) with a special rendering path for VR and if it turns out worth while it may even get into the engine in some point in the future. But what I can say for sure is that something similar will get implemented and it may end up increasing VR performance by a significant amount, so please stick with UE4 because the momentum of the engine is beyond anything we’ve ever seen.
Now, my reassurance means nothing for your immediate problems. So here are some tips/tricks that I use in VR Pong, relevant to GPU and CPU.
Limit dynamic lights to the absolute minimum.
Lights can still cast dynamic shadows if you mark them as stationary, do so if the lights themself won’t move.
Use Spot lights instead of point lights if posibble.
Limit light radius/angle to no more than needed.
Use “Ray Traced Distance Field shadows” for nice looking “cheap” dynamic shadows in the distance.
Per directional light, tweak Dynamic Shadow Distance MovableLight/DistanceField Shadow Distance, granted these settings will only apply for higher fidelity settings where dynamic shadows are enabled.
Turn collision off on everything that does not require it.
Turn physics off where possible.
If you are using physics, adjust Position/Velocity solver Iteration Count (two distinct settings) to the lowest acceptable value.
If you are doing simple motion with physics on a larger amount of objects, think about turning physics off and applying movement for yourself (on Tick).
If you need more lights, that’s fine, because UE4 is primary a deferred render, just make sure you turn the shadows off on the majority of them.
You can use SceneCapture2D camera efficiently by making the target texture as small as possible and if you can make it a power of 2 (generally) something like 128x128, 256x128, turn off update on every frame and move the camera manually (for a very small amount, I just add and toggle sign +0.1/-0.1, that should be +1/-1 millimetre to camera location vector) to update it only when you need to.
Use opaque materials if you can, stay away from translucent ones if not needed, you can use Masked blend mode with some noise to very roughly approximate some translucent material properties.
Turn off motion blur, it’s a no go, especially on the near by objects.
Adjust Screen Percentage lower, resolution is a major player, light calculations/shading is done per pixel not per fragment (deferred render).
Turn Timewarp on.
Use TemporalAA (Settings -> Project Settings -> Rendering) to balance against lower Screen Percentage.
Set minimum desired frame rate to 75 - DK2 (Settings -> General Settings -> Rendering).
I have smoothed frame rate checked and set to min: 75, max 95. Based on Oculus DK2, CV, it might stay at 90Hz where their current DK is.
Leave VSync On or alone Oculus should handle it, timewarp’s precision relies on it. (you need to know when to warp, if no vsync, you don’t know where the scan-out is currently).
Set FOV to 110 or something close.
Turn Dof and Eye adaptation off on your global post processing volume or revalidate them, these happen much more naturally in VR without post processing.
Use GPU particles when their number is relatively large, VR currently inherently requires a dedicated GPU, count on that explosive memory, parallelism and bandwidth.
Make sure you have the latest GPU drivers, engine version and HMD (probably Oculus) firmware.
Always profile your game’s performance, determine where the bottlenecks are, open up dev. console when in game and type Stat Game for a quick overview. You can setup your console toggle key in Settings -> Project Settings -> Input -> Console Keys (at the bottom).
That should sum up the basic stuff. Generally use only what you really need.
Here is what my settings look like for the VR graphics:
Executed (with Execute Console Command - don’t forget to plug in a proper player controller, all in blueprint) at the very beggining of the game
hmd timewarp on
hmd mirror off
hmd sp 100
Executed in this order when graphics settings are loaded (only the selected quality setting of course), the order is critical. Set default at Normal or Low normal.
Edit: As I state below in Non-VR settings. Screen percentage, might also be a good idea for a separate option or menu. For example some advanced users as haggler2 pointed out, that owns a gtx 980 himself, might want to set screen percentage to some higher value like 130.
Off the top of my head there should be a really cool way to test this. If the Timewarp is on then even if you open up a dev. console and type in “ShowFlag.Rendering 0” to disable rendering, you should be able to move your head around the scene but the last frame rendered should be stuck in front and possibly behind you. If you turn Timewarp off, last frame should just get stuck on your face, ignoring any rotation or translation.
This is my setup, the top big function gets called on “Event Begin Play” from level blueprint. In my case that happens from the function “LoadSettings” where settings are loaded from SaveGameInstance (Saved Settings reference) but it’s all the same, they get loaded at the start of the game and then this function is executed to apply them. This same function also gets called from the Graphics menu, where you select one of the above quality settings. And again in my case after that I just save selected index (int) in my SaveGameInstance to VR or NonVR graphics variable, so that the next time you start a game you have your settings set. I have my player controller in a variable but I just swapped it here with a function so that it’s clearer (Set Graphics function).
You can just use a Format Text node and stick it in a function that takes graphics settings as parameters. Example Format Text node (with complimentary example typo):
Great post, but this is the only advice I didn’t fully agree with. It’s true that Epic said Temporal AA was “fixed” as is “less blurry” now, but still looks pretty terrible at screen percentage lower than 130 imo. I think it looks great at anything over that. But at a lower SP I think I would rather be able to make things out through the aliasing than the terrible blur that kills all immersion. Don’t get me wrong, aliasing is terrible and a big immersion killer itself and devs should do whatever they can to elimiate it… But if I had to choose between a higher SP with TXAA off, or an lower sp below 130 with it on I would choose the former.
In addition you do not want to ever turn vsync off as it is required for timewarp 100% properly as the poster above stated. (Cyberreality also stated this)
I think the Paris DK2 demo had some pretty good settings when I think about it, recommend anyone here to check it out. You can see the settings used in the .ini files for the various quality levels. Maybe you could bump up the sg.AntiAliasingQuality to 1 or 2 on the medium settings file if running SP 130 on this demo.
Edit:
Just noticed this, I would also not adjust any FOV settings as Oculus has this fine tuned.
Also remember that “profilegpu” is your friend! It can show you some major bottlenecks. For example, I was wondering why my fully-baked no-dynamic-lights scene was so laggy. Running that command (in a standalone game) showed me 2 things that were eating up FPS. One was LPV. What? I wasn’t using LPV in my scene… but from months ago, I did enable it to experiment. Apparently having LPV enabled at all in my editor consumed nearly 100fps of performance for my scene! So I disabled that. The other heavy bit was HZBOcclusion (Hierarchical Z-Buffer). That is an optional setting that defaults to ON. Turning that off gave me a further 80fps! Suddenly, I was trucking, and could start enabling effects that I normally wouldn’t use in VR, such as SSR.
your posts seem to contradict each other. I’ve tried to confirm or deny the timewarp/VSync in 4.6.1 and 4.7, results being the same. I did this in my game and in the Couch Knights demo, with the same results.
So VSync flag (hmd vsync flag has no effect as well) seems to have no effect in VR at least in Unreal Engine, but I would suspect that this is the work of guys at Oculus to provide us with the best experience.
Ok so while Oculus Extended Desktop defaults to adaptive VSync (tear under 75 fps but stop at 75 fps) and Direct HMD defaults to VSync (37.5 fps and 75 fps). Or at least this is how it appears on my system and I’ve tried everything, playing from editor and shipping builds, changing VSync settings in my AMD control center and changing VSync on “Event Begin Play” in level blueprint. VSync flag had no effect on timewarp, but that’s because it had no effect at all, so I had no way of really confirming anything.
Ouu and here’s a video off one of my tests. You can see the timewarp in action here.
Ou yes indeed, I can see that now and it’s only recognized when hmd is plugged-in and on but it’s all the same, no effect. Does it work on your side? I’ve tested it in both games again with no luck.
I have noticed this happening when the framerate has dipped below 75 fps for too long it will automatically jump down to 37.5fps in direct mode. Not sure if this was intentional or will be resolved in next SDK. Regarding the timewarp, I think it still partially works with vsync off but if you were to do a “tap test” or holding your head still while shaking hmd quickly the world would wobble more with it off. I could be wrong on that though. (I think something to do the timing I’m guessing?). I recommend keeping it on as Oculus recommends and adjusting other things to hit the 75fps target in direct mode.
Edit: Does anyone know what screen percentage setting Epic was running the showdown demo at? I know they mentioned it was being run on a single 980.
&stc=1&d=1425050948
@
