The Tray Tool works just fine. It works by the exact same means as the Oculus Debug Tool, which is part of the core Oculus installation. Both of these tools are just simple graphical interfaces that submit one-time text-string commands to the Oculus runtime when you change a setting.
That’s the important part to understand – both of these tools just submit commands when you change values. It’s the exact same thing as if you opened up the command-line input for the Oculus runtime and typed the commands manually and pressed enter. Also, they do not continuously send these commands – they are sent once when you change a setting, and that’s it.
The real issue is with people using these tools and not knowing what the settings do or how they work. The biggest advantage of either of them for MSFS is (1) being able to use the FOV crop which gives a significant performance boost without any visual impact and (2) being able to lock ASW to a specific value to keep it from dithering between different interpolation rates, or disabling ASW altogether.
You can skip using either of these tools completely if you want. They are basically just ways to get “under-the-hood” of the default way the Oculus runtime works so you can force certain things to behave in a slightly more efficient way. You can get a little bit better performance and smoothness by using them, but in order to see those improvements, the in-game settings and others need to be reasonable too. If the sim is already choking the system to barely being able to hold a choppy framerate, and you lock ASW to 45Hz for example, you will not see any benefit at all.
One of the best features of both of these tools that few people seem to know about is the numerous performance overlays that can be displayed inside the headset. These are transparent overlay plots that directly show you your app frame rate, your performance headroom, your motion latency, whether or not ASW is active and generating frames, the current render resolution, the pixel density scaling values… All of those things I just listed are available in the various HUDs which are selectable from either the Tray Tool or the Debug Tool.
For tuning your app performance, the Performance Overlay HUD is absolutely essential. It lets you see on a plot with actual numbers the effect that your changes make to the app frame rate and also the available computing resources for VR.
On the Performance Headroom plot, if your headroom is greater than 0%, and assuming the VR app has been built correctly, then you should be able to hold a frame rate equal to the full refresh rate of your headset. In other words, if your headset’s native refresh rate is 80Hz, and the performance headroom plot is consistently above 0%, your VR framerate should be a stable 80fps.
If the performance headroom plot shows values consistently between -100% and 0%, then you should be able to hold half the refresh rate of your headset. Example: if the native refresh of your headset is 80Hz, then with performance headroom between -100% and 0%, you should be able to hold a stable and smooth 40Hz. *NOTE that this is critical for ASW to work well. ASW does a fantastic job in properly coded VR apps that don’t have frequent low-performance spikes. But if the app holds performance headroom of >-100% most of the time, with frequent spikes dropping WAY lower (which MSFS often does…), then ASW and other motion smoothing algorithms can’t do their job effectively and it still ends up a juddery mess.
Lastly, if the performance headroom plot is below -100%, then you are in “this is running really poorly” territory, where the best you’re going to be able to do is try to hold something like 1/3 or 1/4 framerate relative to your headset’s native refresh rate. This is what many (most?) MSFS users are having to do, and is a lot of the reason so many people are not pleased with the result. Yes, you can make this kind-of smooth, assuming you aren’t looking at fast-moving terrain, aren’t moving your head quickly, etc. etc. - but understand that this is a VR band-aid. When things are running this poorly, your motion-to-photon latency goes way up, meaning head and controller movements feel detached from the VR world.
That’s the gist of it. MSFS needs a lot more optimization to really deliver a 2021-level of VR performance. The problem is not VR itself – there are many, many VR games that are amazing and run incredibly well. VR flight sims tend not to fall into that bucket, though, because they are not VR game developers. They are flightsim developers, who are trying to shoehorn VR implementation into their apps.
