well, how about 210 FOV for a USD 3,200 ?
https://www.starvr.com

“Developer mode” (when we aren’t working on visuals-related stuff) is basically:

• Go to an area with no scenery installed (I use UIUB in Siberia)
• Choose an old aircraft model with no 3-D attached
• Turn rendering options down to minimum

That gets you the fastest load times possible.

Oh, for sure. When a decent VR headset with, let’s say, 5k resolution and FOV of 160 or greater comes around with a price tag under 300 bucks, I’m in 😀

Framebuffer capture is irrelevant for multi-monitor purposes, it’s used in order to grab screenshots and do video capture of the rendered scene. Additionally, a second GPU will actually not do any work for X-Plane, we strictly talk to one GPU. There is some theoretical advantage to multi GPU support, like you said, each GPU could drive a single monitor or one eye in a VR headset. However, multi GPU support comes with a lot of overhead and a lot of potential problems, so I don’t think we’ll add support for it in the near future. Plus, unlike CPUs, GPUs actually still get better each year and we are mostly CPU bound, so improving CPU performance is definitely the major focus right now.

With regards to occlusion queries, I don’t see how RTX would provide any benefit here. Occlusion queries are already done in hardware and the results are read back asynchronously. And they work on all hardware, without relying on vendor specific extensions. No, the reason they aren’t used isn’t performance concerns but rather that there aren’t too many use cases for them in X-Plane, unlike, say a shooter with a tight level where most geometry can be easily clipped based on occluders.

the outcome is – it seems with the shift to VULKAN — more GPU utilization will make performance be more GPU bound — yet every freeing for the CPU will benefit the core x-plane core system that i suppose is CPU bound.

all in all – we are eager to see the future

Depending on the resolution (you will hit the wall pretty hard at some point), I’d use 3/5 or 2/6 or 4/6 instead of the standard 2/4 which would be 8x AA (if I remember correctly). I am not saying I am fully understanding it, but what I do know is that this lever was the only one that gets you a completely shimmer free (think poles, powerlines) sim. 720p with higher AA easily beats 1080p in terms of image quality/stability (given your display has a good upscaler, for example Sony TVs excel at this).

The only other way to achieve this would be X-Plane allowing super resolutions, just like NVIDIA DSR. The problem with DSR is, it doesn’t work for a base 720p resolution (without elaborate hacks anyway). And at 1080p you won’t be able to raise AA much before you run out of fillrate.

I have no idea what causes 11.30s glitch when messing with these variables, but if you could “fix” it, or even made a higher setting than 8x available through the slider, that would be super cool.

with thanks for the clarificaiton.

i was kind of educating myself based on your answer:
———-
for the “Framebuffer capture”, am sure this also paves way to better harness multi-monitor setup – does it ?
i was kind of thinking – though this is not relevant – suppose a scenario of two GPUs; would they share one single frame buffer – or is it each GPU will have its own frame buffer?
———
for the “Occlusion queries” i have watched::
https://www.youtube.com/watch?v=LMpw7foANNA
Now based on your info “we don’t use them heavily” is that because of a performance hit that you do not use them heavily, or just a matter that they are not needed in most of scenarios through out the sim.

This sparked an idea – at least how i theorize it for my self – that in future you can tap RTX ray-tracer setting it to a depth of 1 – to achieve same result but at hardware acceleration bonus.

I think the question though is whether or not the DSF load process itself will be done in a way that does not produce stutters. My understanding (based on a blog post from 2017) is that X-Plane does this load now, but the OGL drivers are doing something that interferes with the existing XP process. The interference causes the CPU cores to spike to 100% during the load, causing the stutter. I’m inferring from the comments by Ben that the Vulkan code will give XP full control over this load process, which will then allow them to debug any stutters (and of course fix them!)