Quote from Tomfuel :

what about your Graphic card ? what is your config please

I've only pushed it this far with my 3080ti. Racing at Blackwood. And the Aero is running with a 3090ti. But that said, I get really good visuals rendering with much more sensible SS on a 1080ti + Reverb G1, still at 90fps.

With the 30x GPUs I've maxed everything in LFS config and added 2xSGSS with insane super-sampling to intentionally push it a bit hard, with rigs for G2 and Aero.

I'm fortunate to have good access to hardware to try quite a few combos of GPU and headset.


To clarify on OpenXR/OpenVR: native support for OpenXT in the future version seems a likely direction if that's where everything goes, no doubt - but what I was getting at is that the OpenXR Toolkit allows one to by-pass SteamVR and apply additional effects with existing OpenVR titles.

It's basically AC (Open VR) >> OpenXR Toolkit >> OpenXR for WMR, on my G2. Getting rid of SteamVR was a good performance increase in its own right, plus allows the other toolkit capabilities to be layered on top.

So perhaps one for the future release, but the Dev of the toolkit "mbucchia" recently commented on a Discord channel (not about LFS but in general) regarding developers that wanted to allow him to enable support for Dynamic Foveated Rendering in the toolkit:

"If they could tag their left/right eye render targets with a debug name (WKPDID_D3DDebugObjectName) then we would be able to tell what eye a render pass is targeted for (when we intercept OMSetRenderTargets()). From their end, it means whenever they allocate the textures they use to render to, they have to make one extra call to SetPrivateData() and use a distinctive name, like "LeftEye" or "RightEye"."

Not sure if LFS does this already but if so, maybe worth talking to him about adding it, with no extra work required by LFS devs - or if not, perhaps a way in future to easily add the support and all those capabilities.

Aside the performance, it would be neat to have a title where - with an eye-tracking headset - one can easily have the focus crosshair overlaid on the monitor view to see where the driver is looking; again good capability to showcase from a driver training perspective.

Quote from Scawen :

In my opinion LFS is to blame, rather than any hardware issues. Or a sort of combination of the Oculus software being a bit odd and LFS not fully adapted to it. Though that can probably be overcome by a very fast computer, you could still argue it's LFS's fault in some way.

For example the call where LFS submits the finished render target to the Oculus software, blocks for quite a while each frame. That means by default LFS would not be able to do anything at all while it simply waits for Oculus to return. That is the method that Oculus uses to force the program to stay at the correct frame rate. For the record, this is different from the SteamVR method, where the blocking is done on a separate function where the game asks for the head position for the next frame.

To try to avoid this wait, LFS uses a thread to submit the image. It allows LFS to continue with other tasks until Oculus says it's OK to proceed. LFS then waits at another point. I am not really sure about the interaction between this thread and the other part of the program. Also there is complication due to the fact that LFS renders in Direct3D 9 and submits a shared texture to Direct3D 11 as used by Oculus or SteamVR.

In my opinion it would be much better to use a separate thread for the render and the physics. I believe the VR driver software for Oculus and SteamVR are designed to be used in this way. So the graphical thread would continually create images and submit them to the VR system, while the physics thread does its own thing.

I think you just made your own case for a proper OpenXR implementation though, especially as you could drop Oculus and OpenVR support and focus on one API.

It also single handedly solved all of those openvr alignment issues and tons of other crap (world scale, drifting,..) and workarounds with a myriad of HMDs (Index, G2, VP2, ..).

PS: with OpenXR Toolkit there's now even a blueprint (MIT License, free to use and even encouraged by the author) for Foveated rendering etc for OpenXR, developed by the the current head of openxr at MS.