VR testing and findings
-
Just finished a 10 hour VR testing session
I tested both in “benchamark TE” and a fixed scenario in a dynamic campaign.
Hardware: Reverb G2, RTX4090, 5800X3D and 64GB of RAM, running on NVME SSD.Here are my findings:
First, the most important one -> object detail, going from 7 to 1 saves 10+ms of CPU frametimes in heavy scenarios. In my case it was an improvement from 25+ms to 10-12ms.
I have no idea what this option does, didn’t notice any difference while looking at things on the ground. My guess would be poly count? But why CPU frametimes are affected then?This setting adjusts the rendering distance of other units, SteamVR resolution and BMS’s supersampling also affect that distance.Smartscaling also affects the rendering distance/pop in of other aircrafts, if you want the benefit of that without scaling use set g_fSmartScalingThreshold 5.0 or even bigger value.
Second important thing is reprojection. Either leave it off or “force always-on”. I didn’t test it with quest 2 but with G2, if you leave it on “enabled”, there is a massive video memory leak that fills it completely in less than a minute, afterwards the game stutters every couple of seconds.Select the beta version of “windows mixed reality for steamVR” and the leaks should be fixed.Monitor resolution (not VR) seems to be impacting the GPU frametimes, setting it to 1024x768 doesn’t change anything in VR but improves frametimes by 2-3ms compared to 3840 x 2160.
Setting “set g_bVRParallelRenderThread 0” increases CPU frametimes in heavy scenarios (+10ms), at least in my case. It was better to leave this on in my case.
“set g_bShadowMapping 0”
cut’s CPU frametimes by another 2msas already explained by the devs, there are situations where the shadows increase CPU frametimes by a lot (6-8ms), I experienced some of these situations myself but only on the ground, I left this on 1 as it looks bad without shadows.SteamVR resolution affects BMS resolution but my advice is to leave it at 100% and change “set g_fVRResolution 1.0”. I found 1.4 gives the maximum clarity with 100% (3164x3092) resolution set in steamVR.
Setting “set g_bEnvironmentMapping 0” and “set g_bWaterEnvironmentMapping 0” as advised didn’t impact/improve performance at all. Probably only useful on lower end GPUs.
Other options: Bloom, HDR, tree/grass density and cloud density have minimal impact.
The information below is only for the people that run 6k+ resolutions and still have some CPU spikes on the ground. (expect another 2-3ms down on CPU frametime in heavy campaign scenarios. You won’t see a difference in benchmark TE as everything is cluttered together).
I haven’t tested yet how this affects TGP rendering distance but there is a way to modify the object detail below 1. This will greatly reduce spotting distance for other aircrafts (below 6nm with smart scaling enabled)
The setting is stored in your “yourcallsign.pop” which is in user config folder.
To modify it you need to open it with a hex editor (you can use HxD https://mh-nexus.de/en/hxd/)
If you aren’t sure on how to do it, attached you can find my file with OBJ set to 0.5, just rename it to your callsign https://file.io/wctzHS5nVg6xObject detail is stored in these two cells:
The setting is applied as follows (any modification should be applied with game/ui/launcher closed):
OBJ 0 -> 00 3E (spotting distance 2.5nm with smart scaling enabled, don’t use this but you can try if you want )
OBJ 0.5 -> A0 3E (spotting distance 5nm with smart scaling enabled, 10nm if you use VR zoom)
Edit the value and press “SAVE”If you do it correctly you should see this in the game settings:
don’t press apply or ok in the settings, otherwise it will revert to 1.
-
-
@Dragasath said in VR testing and findings:
Just finished a 10 hour VR testing session
I tested both in “benchamark TE” and a fixed scenario in a dynamic campaign.
Hardware: Reverb G2, RTX4090, 5800X3D and 64GB of RAM, running on NVME SSD.
Here are my findings:
First, the most important one -> object detail, going from 7 to 1 saves 10+ms of CPU frametimes in heavy scenarios. In my case it was an improvement from 25+ms to 10-12ms. I have no idea what this option does, didn’t notice any difference while looking at things on the ground. My guess would be poly count? But why CPU frametimes are affected then?
Second important thing is reprojection. Either leave it off or “force always-on”. I didn’t test it with quest 2 but with G2, if you leave it on “enabled”, there is a massive video memory leak that fills it completely in less than a minute, afterwards the game stutters every couple of seconds.
Monitor resolution (not VR) seems to be impacting the GPU frametimes, setting it to 1024x768 doesn’t change anything in VR but improves frametimes by 2-3ms compared to 3840 x 2160.
Setting “set g_bVRParallelRenderThread 0” increases CPU frametimes in heavy scenarios (+10ms), at least in my case. It was better to leave this on in my case.
SteamVR resolution affects BMS resolution but my advice is to leave it at 100% and change “set g_fVRResolution 1.0”. I found 1.4 gives the maximum clarity with 100% (3164x3092) resolution set in steamVR.
Setting “set g_bEnvironmentMapping 0” and “set g_bWaterEnvironmentMapping 0” as advised didn’t impact/improve performance at all. Probably only useful on lower end GPUs.
Other options: Bloom, HDR, tree/grass density and cloud density have minimal impact.Thanks for the work, what did you use to measure Frametimes, fpsVR? Have been running OpenXR for a long time, will have to reinstall it…
-
@Icer fpsVR and BMS’s internal frame counter. Do note that fpsVR is unable to monitor BMS’s GPU frametimes, it’s always shown as 0.2ms
-
@Dragasath awesome work! I’m definitely going to be trying these. I think I ran into the reproduction memory leak myself and it was running absolutely awfully.
-
@Dragasath Great info. Will save me lots of time when i start the dance with my Reverb VR 1000
-
@Dragasath shadow mapping has an impact too
-
Thanks for advices
Maybe a dev explanation about object detail would be nice -
@Dragasath amazing work, thanks for sharing findings. I’ll have a play with these and see what improvements I can squeeze too
-
“set g_bShadowMapping 0” cut’s CPU frametimes by another 2ms
-
Well i don’t use VR, but after reading your OP @Dragasath I played with the object detail slider. Well the improvement was huge when I set the slider to 1. Almost 40% on the FPS counter! I will try to take photos of various buildings and vehicles with the slider on 1 and 7. But I could not see a significant difference at a first glance.
-
**I realize this for an Oculus and is in the HP headset section but it’s a reply to Dragasath who inspired me to try some of these settings
Getting good results with some similar settings but some different. 40+ FPS in the benchmark TE with a little lag / black edges showing when turning my head - minimal tho. 45FPS in the night ILS landing TE over the water and Gunsan.
90 FPS during the day landing TE
Readable cockpit - biggest issue is my IPD seems to be in-between one of the factory positions, and I have to strap the thing on tight - closer the lenses are to my eyes the less I have a little “doublevision”.RTX 3070
5600X
32GB ram
Quest 2
Wired link USB cable (not air)90Hz refresh in oculus app
In the Oculus debug progarm:
In BMS menu and config file:
Object detail set to 7
Monitor resolution (not VR) set MINIMUM
Leaving “set g_bVRParallelRenderThread 1”
Leaving “set g_bShadowMapping 1”
SteamVR resolution 100% and “set g_fVRResolution 1.4”.
Leaving “set g_bEnvironmentMapping 1” and “set g_bWaterEnvironmentMapping 1”
BTW, what is the phenomena called where you turn your head rapidly and you see the black edge of your rendered area appear in your peripheral?
-
What gives a Blast in Framerate ist disabling the PC Display. While in VR you dont need it unless you have someone want to look over your shoulder
set g_bVRNoPresent 1 // This will not display the companion window in VR (only HMD will show image in 3d).
This will nearly double my Framerate (BMS Framerate Display)
-
@AWmk1 said in VR testing and findings:
**I realize this for an Oculus and is in the HP headset section but it’s a reply to Dragasath who inspired me to try some of these settings
Getting good results with some similar settings but some different. 40+ FPS in the benchmark TE with a little lag / black edges showing when turning my head - minimal tho. 45FPS in the night ILS landing TE over the water and Gunsan.
90 FPS during the day landing TE
Readable cockpit - biggest issue is my IPD seems to be in-between one of the factory positions, and I have to strap the thing on tight - closer the lenses are to my eyes the less I have a little “doublevision”.RTX 3070
5600X
32GB ram
Quest 2
Wired link USB cable (not air)90Hz refresh in oculus app
In the Oculus debug progarm:
In BMS menu and config file:
Object detail set to 7
Monitor resolution (not VR) set MINIMUM
Leaving “set g_bVRParallelRenderThread 1”
Leaving “set g_bShadowMapping 1”
SteamVR resolution 100% and “set g_fVRResolution 1.4”.
Leaving “set g_bEnvironmentMapping 1” and “set g_bWaterEnvironmentMapping 1”
BTW, what is the phenomena called where you turn your head rapidly and you see the black edge of your rendered area appear in your peripheral?
I call it names.
-
@Viper I’ll have to try this! Sounds like a no brainer if it does help with performance!
-
Folks, let me give some context here about all these terms. This will help you understand a bit what each flag does. Some dirty coding info in here follows, sorry about that.
I will show each option with their default released value. You can override any of those in Falcon BMS User.cfg.
Parallel Render
set g_bVRParallelRenderThread 1 // 0 disables, 1 enables parallel render
One of the nastier bugs we had during VR development was understanding jittering/juddering (when you rotate your head and the movement is not smooth). This happens because in BMS we prepare the scene in one thread and render in another, like most modern games. The problem is that VR is a bit peculiar, so this creates a race between the thread that prepares the scene and the one that renders it.
To fix this issue, we serialized both threads for VR. The drawback is that we lost a lot of performance because of this. We were able to fix this issue, but for some headsets (or for virtual desktop) the fix doesn’t seem to work for reasons we still don’t understand.
So, if you have jitter/judder, try reverting to
set g_bVRParallelRenderThread 0
, which will make movement a lot smoother.Environment mapping
Enviroment mapping is what renders reflections. For example, water displaying sky, glasses reflecting objects near it and so on. In Falcon, we have a very simplified environment mapping, where only terrain and sky are drawn (and ownship as well, but I think this is disabled for released version).
If any of these is enabled, environment mapping will happen, so you need to disable both to get its performance back.
set g_bEnvironmentMapping 1 set g_bWaterEnvironmentMapping 1
I’d say this is almost prohibitive in VR. Environment mapping adds 6 additional renderings of the scene (one for each cube face from the origin point of view). The renderings are simplified, not as expensive as a full rendering though, so your experience may be different.
The visual effect is beautiful, specially over the water. But not essential.
Shadow mapping
This is what creates dynamic shadows. For example, when the sun is behind you, cockpit shadows are projected into your pit. This is a very nice effect.
set g_bShadowMapping 1
Shadow mapping adds 2 additional renders of the scene. One focused on target object, the other on nearby objects (area). This causes a big impact on airbases with a lot of objects and I have seen it taking almost 50% of the frame time.
If you are having low FPS, try disabling it… but quality drops a bit, so I don’t recommend removing it. For next version, we are already working on improvements on this.
Companion Window
Aside from the VR, Falcon also renders to a companion window. This is useful to debug, to have other people watching you play… But if you are alone, has no benefit.
The companion window rendering is kinda cheap, but for some reason I cannot understand, sometimes it takes a lot of time. Maybe vsync? I don’t know. Anyway,l you can disable it with:
set g_bVRNoPresent 0 // set to 1 to disable companion.
-
@Seifer said in VR testing and findings:
Folks, let me give some context here about all these terms. This will help you understand a bit what each flag does. Some dirty coding info in here follows, sorry about that.
I will show each option with their default released value. You can override any of those in Falcon BMS User.cfg.
Parallel Render
set g_bVRParallelRenderThread 1 // 0 disables, 1 enables parallel render
One of the nastier bugs we had during VR development was understanding jittering/juddering (when you rotate your head and the movement is not smooth). This happens because in BMS we prepare the scene in one thread and render in another, like most modern games. The problem is that VR is a bit peculiar, so this creates a race between the thread that prepares the scene and the one that renders it.
To fix this issue, we serialized both threads for VR. The drawback is that we lost a lot of performance because of this. We were able to fix this issue, but for some headsets (or for virtual desktop) the fix doesn’t seem to work for reasons we still don’t understand.
So, if you have jitter/judder, try reverting to
set g_bVRParallelRenderThread 0
, which will make movement a lot smoother.Environment mapping
Enviroment mapping is what renders reflections. For example, water displaying sky, glasses reflecting objects near it and so on. In Falcon, we have a very simplified environment mapping, where only terrain and sky are drawn (and ownship as well, but I think this is disabled for released version).
If any of these is enabled, environment mapping will happen, so you need to disable both to get its performance back.
set g_bEnvironmentMapping 1 set g_bWaterEnvironmentMapping 1
I’d say this is almost prohibitive in VR. Environment mapping adds 6 additional renderings of the scene (one for each cube face from the origin point of view). The renderings are simplified, not as expensive as a full rendering though, so your experience may be different.
The visual effect is beautiful, specially over the water. But not essential.
Shadow mapping
This is what creates dynamic shadows. For example, when the sun is behind you, cockpit shadows are projected into your pit. This is a very nice effect.
set g_bShadowMapping 1
Shadow mapping adds 2 additional renders of the scene. One focused on target object, the other on nearby objects (area). This causes a big impact on airbases with a lot of objects and I have seen it taking almost 50% of the frame time.
If you are having low FPS, try disabling it… but quality drops a bit, so I don’t recommend removing it. For next version, we are already working on improvements on this.
Companion Window
Aside from the VR, Falcon also renders to a companion window. This is useful to debug, to have other people watching you play… But if you are alone, has no benefit.
The companion window rendering is kinda cheap, but for some reason I cannot understand, sometimes it takes a lot of time. Maybe vsync? I don’t know. Anyway,l you can disable it with:
set g_bVRNoPresent 0 // set to 1 to disable companion.
Thank you for the clarifications. You probably guess what some of us will come with: video recording. Any opinion? So far, I’ve come to think it is not a good idea. It would promote the work done in VR but (supposing I change my mind about the damages it does to proficiency) with current means and parameters, I can’t have something people would watch for more than a minute.
-
I don’t see any difference other than the fps impact.
-
@Seifer said in VR testing and findings:
Folks, let me give some context here about all these terms. This will help you understand a bit what each flag does. Some dirty coding info in here follows, sorry about that.
I will show each option with their default released value. You can override any of those in Falcon BMS User.cfg.
Parallel Render
set g_bVRParallelRenderThread 1 // 0 disables, 1 enables parallel render
One of the nastier bugs we had during VR development was understanding jittering/juddering (when you rotate your head and the movement is not smooth). This happens because in BMS we prepare the scene in one thread and render in another, like most modern games. The problem is that VR is a bit peculiar, so this creates a race between the thread that prepares the scene and the one that renders it.
To fix this issue, we serialized both threads for VR. The drawback is that we lost a lot of performance because of this. We were able to fix this issue, but for some headsets (or for virtual desktop) the fix doesn’t seem to work for reasons we still don’t understand.
So, if you have jitter/judder, try reverting to
set g_bVRParallelRenderThread 0
, which will make movement a lot smoother.Environment mapping
Enviroment mapping is what renders reflections. For example, water displaying sky, glasses reflecting objects near it and so on. In Falcon, we have a very simplified environment mapping, where only terrain and sky are drawn (and ownship as well, but I think this is disabled for released version).
If any of these is enabled, environment mapping will happen, so you need to disable both to get its performance back.
set g_bEnvironmentMapping 1 set g_bWaterEnvironmentMapping 1
I’d say this is almost prohibitive in VR. Environment mapping adds 6 additional renderings of the scene (one for each cube face from the origin point of view). The renderings are simplified, not as expensive as a full rendering though, so your experience may be different.
The visual effect is beautiful, specially over the water. But not essential.
Shadow mapping
This is what creates dynamic shadows. For example, when the sun is behind you, cockpit shadows are projected into your pit. This is a very nice effect.
set g_bShadowMapping 1
Shadow mapping adds 2 additional renders of the scene. One focused on target object, the other on nearby objects (area). This causes a big impact on airbases with a lot of objects and I have seen it taking almost 50% of the frame time.
If you are having low FPS, try disabling it… but quality drops a bit, so I don’t recommend removing it. For next version, we are already working on improvements on this.
Companion Window
Aside from the VR, Falcon also renders to a companion window. This is useful to debug, to have other people watching you play… But if you are alone, has no benefit.
The companion window rendering is kinda cheap, but for some reason I cannot understand, sometimes it takes a lot of time. Maybe vsync? I don’t know. Anyway,l you can disable it with:
set g_bVRNoPresent 0 // set to 1 to disable companion.
I would recommend to have all those options present (and REM documented) in default Falcon BMS.cfg
-
…You probably guess what some of us will come with: video recording. Any opinion? So far, I’ve come to think it is not a good idea…
AGREED.
Recording VR footage = oxymoron.
Unless its a VR recording which can be replayed in a VR set in 3d
-
@danaos75 said in VR testing and findings:
I don’t see any difference other than the fps impact.
If I am not wrong, it is a matter of distance of LOD transitions, not about max details level.