Choose your operating system:
Windows
macOS
Linux
While profiling tools can provide data about how your project is performing in VR, there are some points to consider when interpreting those values.
Delays can appear in odd places in the GPU and CPU profilers, most often as occlusion or scene graph traversal time. If those numbers are abnormally high, it's possible that it's a false positive.
Often when profiling, you'll notice that you pop between 90 Hz and 45 Hz. The difference is accounted for because the Compositor acts much like a vsync. If you miss framerate, it delays you until the next frame entirely. So, you tend to go down in brackets of 90 / n, where n is a whole number. Because the fps reporting is an average, it won't always report as a whole number, unless the drop is sustained. If you're bouncing back and forth between making framerate and not, you may see some fraction of a jump.
If you'd like to remove this for testing, sometimes it's useful to run the game emulating stereo rendering, instead of running in the device itself. To do so:
-
Launch the game with
-game -emulatestereo -res=2160x1200on the commandline -
Ensure vsync is off with
r.vsync 0in the console -
Update the screen percentage to emulate the oversampling we have to do for VR with
r.screenpercentage 137in the console
This will emulate the GPU and CPU performance characteristics without the annoyances of the variable framerate.
It's worth explicitly noting that if you're hitting 90 frames a second most of the time, and then make a change and notice a drastic drop, you're probably falling prey to the Compositor "vsync" issue noted above. As soon as you tip over the cliff, you'll see drastic changes in numbers.