I’m developing an Oculus VR project in 4.12.3
Win10
gtx980
I’ve disabled plugins for Vive and others. Only Oculus related plugins are enabled.
I’ve turned off Frame Smoothing.
When I play in editor (in VR) I get a solid 90fps no drops.
When I build and play the build, I get considerably worse performance. sometimes down to 45fps.
help?
Hi 3dlight,
I’m not sure there is enough information to go on here without a lot of guess work on my part.
When in PIE/Standalone game in the editor it will sometimes adjust the scalability to keep performance up. When you package the game these need to be set otherwise it will use max settings which could be part of the problem.
At this point using profiling to see what is causing the slowdowns is the best course of action and then trying to clear things from there. The documentation for performance and profiling can be found here:
If you’re able to see this in a template project can you list the repro steps here and I’ll take a look.
-Tim
“Does this happen in a new blank project with a default level or one of the template projects?”
I’m guessing this will work fine, as you would have noticed it.
“When in Editor try using Standalone game and see if you get the same slowdown that you don’t see in PIE”
This isn’t working, when I play standalone, it doesn’t play in stereo. emulatestereo, hmd, commands aren’t working.
“Have you tried profiling your performance issues in your packaged project to see if you can narrow down what is causing the hit?”
profilegpu isn’t working in a packaged build. I can enter the command, but the results never show up. I can only seem to profilegpu when using VR Preview in the editor.
is VR Preview in the editor the same as PIE? If so, it’s not labeled as such. Does it scale down dynamically? I have several scaleability settings in my ini that should be used.
why can’t I profilegpu in the dev build? That seems very wrong.
It has been suggested to me that using Streaming Levels may be the cause of the mysterious slowdown. We have a Persistent and 4 streaming sub-levels. The 2nd level loaded is having a strange reduction in framerate that doesn’t happen in editor.
“When in Editor try using Standalone game and see if you get the same slowdown that you don’t see in PIE”
Unfortunately, all VR options are disabled in Standalone, so I can’t get a real reading on performance in standalone.
From another forum:
“The editor owns the HMD process and launches the standalone instance with “-nohmd”.”
Problem is, Standalone doesn’t seem to work with the HMD enabled, or stereo. None of the vr options are avail in standalone, so I never see the performance issue.
I’m going to try to get a simple project that can illustrate the issue.
That would probably be best. If you have something that is able to be looked into like this I could do some better digging than just suggestions. Thanks!
While I haven’t been able to reproduce yet in a simplified form, I did run the Session FrontEnd and profiled the build that way. Seems there is a large percentage of my fps lost to SlateDrawWindowsCommand. I am using widgets for title cards, but they are not visible during the profiled frames, and would hopefully not be affected like this.
in profiling, I’m getting 20ms total: where 12ms are for the renderThread and 7ms are used by the SlateDrawWindowsCommand. That’s 34% of my entire frame for something that isn’t visible. Any thoughts?
These threads may be helpful for you:
Thanks, but I’m not seeing answers there. It seems there is some connection between vsync and slate performance? I’m absolutely using vsync, since it is a VR project. What is the issue with that?
In the other thread, it suggests that they are overloading the GPU which is resulting in a bad slateDraw profile. But if I’m not overloading the GPU in the Editor, and playback in PIE is fine, then how is it that I’m overloading the GPU in the build?
Tim and any others that might be following this. I’ve found my solution. Tim mentioned that PIE automatically adjusts scalability settings to keep performance up. This was unknown to me, and is critical to understand. Something Tim didn’t mention is that you can turn this behavior OFF!
Settings>Engine Scalability Settings>Monitor Editor Performance?
Finding this made a huge difference so that I could see much closer framerates to what my build was showing. I’ve carefully tuned what I wanted my scalability settings to be, and wanted to modify the contents of my scene to allow for them. However there wasn’t any way for me to mirror the performance of my editor to the performance of my build until this was turned off. Now my profiling from PIE is much more accurate, and I found the offenders. Too much translucency, and my foliage scalability needed adjusting.
So for anyone not seeing similar performance between build and PIE. Turning off Monitor Editor Performance is a big step in the right direction. Wish I knew about it 2 weeks ago!
Thanks for your help and the pointers Tim!
Andrew
Ah, Good point about the monitor editor performance. That was something I didn’t consider really (obviously!), but I’ll keep a note of it in case this issue comes up in the future.
still having performance problems. Went through the session frontend to see what was killing performance in the build. I’m having very serious CPU Stalls. The game level runs at 6.8milliseconds and scalability performance monitoring is OFF. Only in the build after this level is streamed in does this performance hit happen in the build:
Any idea why this is happening?
Here’s a profile capture ue4stats file link textfrom where the level before to the loaded new level that runs poorly. That poor level however runs beautifully if built as the starting level, or run at any point in editor.
