Brun

Your GPU has 11GB of VRAM. Texture resolution is not the cause of your problems.

My guess: Poor performance in VR is often caused by the number of draw calls, because rendering two viewpoints increases them substantially. Draw calls are bad in DX11 because they're performed by the CPU, which is why VR is frequently bottle-necked by the processor leaving the GPU operating below capacity. It's possible that ED have identified that the draw calls demanded by the terrain engine are limiting VR performance and they've managed to reduce these.

Never experienced this before. Even when the F-14 axis assignments stop working everything's ok for the Hornet ones.

Have you considered defecting?

The concept of a PC purpose built for DCS doesn't make any sense, because the result is simply a high-spec gaming PC. What hardware is there that would specifically benefit DCS?

I'm guessing here cos I'm at work, but... Since our DCS Hornet doesn't have the physical in-flight idle lock, it's easy to move the throttle to an 'unrealistic' position before touchdown. It might therefore be the case that when weight-on-wheels occurs, DCS doesn't register the fact that the throttle is already in the 'ground idle' position. Might be something worth testing.

That sounds very wrong. Are you maintaining on-speed AoA as you hit the deck, and not flaring? A video or track would no doubt help.

Air to Ground radar?

It was these cheap and cheerful numbers... https://www.amazon.co.uk/gp/product/B00E1IKGC4/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1 Actually seem good for the price, really smooth movement. Definitely better than the encoders. Seeing that image has also reminded me that I still need to make the HDG/CRS panel available to download/print. Apologies to anyone who's been waiting for ages, I'll make an effort to get it sorted this weekend.

Good luck with that in VR :)

I thought one of Lex's videos had the final turn starting at 10 degrees past perpendicular to the ship, in other words directly opposite the round down. Scale of the TACAN display has no effect on this by the way.

The channel knobs are rotary encoders not pots, so they connect as buttons rather than axes. There's plenty of info on hardware required on my thread here. I started off using a BBI-64 and encoders for everything, but wasn't happy with the knobs so eventually replaced them with pots connected to a BU0836A which I had spare. Having two separate USB devices isn't ideal, but it did free up a few inputs on the BBI-64 which meant I can use that for other stuff such as my landing gear lever.

Nice :) The print looks really good quality. If anything the lettering seems to be better than what I got from Shapeways. Do you know what hardware your friend used? Good luck with the rest of the build!

Only way to see more of the HUD is to move closer to it.

Still preferable to ejecting before you get off the runway.

It still says 30 deg bank angle for the break. Have you tried banking 30 degrees at 350 knots and pulling 3.5g? I can picture it now, and you're not gonna stay at 800' for very long :) Final turn looks much better now though.

The rendered image needs to be a higher resolution than the displays because of the effect of distorting it to correspond with the headset's lenses. Roughly, the number of overall pixels rendered needs to be double the headset's resolution. Presumably that's where the percentages come from. I keep finding reasons to post a link to the same pdf, but it's all explained here. Page 14 onwards.

That would be right if due north were 300 degrees.

A few things don't look quite right to me... The break is not a 30 degree (presumably you mean bank angle?) turn. It's whatever is necessary to pull 3.5g and maintain 800'. Gear and flaps should be deployed as soon as airspeed is below 250kts. The position in the illustration makes it look much later. I thought 800' was maintained throughout the break, and altitude reduced to 600' on the downwind? Might be wrong about that though. As suggested above, the final turn should begin when approximately opposite the round down, which is perpendicular to the runway therefore ~9degs past the BRC. Lastly, things at the bottom of the image are very compressed which makes the transition to final appear very abrupt. Appreciate it's difficult to illustrate this to scale (and also account for forward movement of the boat), but it could be much smoother. See attached image.

I'm being realistic, not negative. Everyone with a Pascal or later Nvidia card - the overwhelming majority of VR users if this topic is any indication - already owns technology which is designed specifically for VR performance but isn't being used*. No single pass stereo No lens matched shading No VR SLI I just don't see any evidence that developers will jump at the opportunity to implement foveated rendering, especially seeing as it's likely to be even more complex than the above. I still think eye tracking has potential, but expect it will be used for interaction and effects (i.e depth-blur) rather than rendering performance. *Nvidia Funhouse doesn't count, sorry.

My point is that the periphery of the *display* could currently be rendered at lower resolution, regardless of where the eye is looking. Current VR headsets have (to varying extent) a sweet spot in the centre, beyond which the optics make the image increasingly blurred. It's the reason why in DCS you have to actually move your head to read instruments and displays rather than simply being able to glance at them. There's no need to render the whole image with the same quality as the centre. There's another reason why the edges should be rendered at lower res. The distortion which is applied to the rendered image means the edges are actually over-sampled in comparison to the centre of the image. See page 14 onwards in this pdf for an explanation. If there are already good reasons for variable rendering resolution - which would be applicable to existing hardware - but (as far as I'm aware) it's not being used, why do people expect eye-tracking based rendering to be significant?

If foveated rendering is so beneficial, why aren't we already getting variable pixel density between the centre and edges of the image?

Forgot this topic existed. Done this recently... 3D modelling and rather a lot of Photoshop :)

I'm sceptical of significant performance gains from foveated rendering. Even though it might lighten the rendering load, the reason for of poor performance in VR (in DX11 at least) is having to 'create' the scene twice rather than render the pixels. I don't see how foveated rendering will do anything to alleviate that. Might be that DX12 and Vulcan benefit more, but that's not much use for DCS.

I know that feeling!