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.

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, ..).

Last edited by bberger, Mon, 8 Aug 2022 17:24.

PS: the Reverb and Reverb G2 are supposed to be canted 0.2°, not 2° as mentioned earlier.

SteamVR 1.16.5
HP Reverb G2 (second unit)
SteamVR OpenXR Runtime: Windows Mixed Reality

"renderCameraMode": "parallel" (default)

"renderCameraMode": "raw" (after SteamVR restart of course)

riftvr.log (ReVive, camera render mode "raw" in SteamVR):

Keep in mind, this is my second Reverb G2 unit as I sold off the first one (where the logs from the previous posts come from) and got another one from another batch just a few days ago, so you can't directly compare the values above with these. The effect is the same though.

I don't see a difference between both modes though - shouldn't there be one however..?

I have my steamVR configs added as attachment so I don't spam the thread too much. Keep in mind I changed the camera mode in both the default.vrsettings and the steamvr.vrsettings files to make sure I'll end up in raw or parallel mode respectively. I had to rename the file though.

Another thing to mention (maybe):
Ingame the IPD reports as 62.7, WMR reports it as 63.172 and the OpenVR and Rift logs show 0.063

There is a known (and confirmed by MS) IPD rounding bug in the WMR runtime though. Just thought I'd mention it.

Last edited by bberger, Mon, 1 Feb 2021 20:34.

I just thought about the same. Looks like SteamVR defaults to parallel projection for EVERYTHING and needs to be disabled on a per-executable basis.

I'll look into this tonight and post the logs here.

PS: does LFS account for the HAM / run in parallel projection mode?

https://risa2000.github.io/vrdocs/docs/hmd_fov_calculation.html

Thank you Scawen! Might explain why some apps/sims/programs have world scale that's oft while there are others that seem fine (vertical vs horizontal FOV as basis).

With that info in mind I can finally dig deeper into this and maybe get clarification from MS/HP guys if those reported values indeed are correct.

I'll report back here if/when there's progress on this.

Pretty sure it should be around 90.x, at least that's also what ROV HMDtester and the Czech tool that name I forgot get out of the G2. Both cut off rendering at roughly 90.x deg vertical.

Do you account for canted displays (do you even have to account for it?)? The Reverb G2 is canted at 2° I think, but afaik only on the horizontal plane.

F8 doesn't cut it as I'd have to click the reset button which isn't very easy to do while in a race..

I always wondered what the difference between reset and use relative is?

Is there a hotkey to reset/recenter the VR view?

I think there actually are WAY more issues with WMR/WMR for SteamVR and OpenVR than I can comprehend:
https://forums.flightsimulator.com/t/psa-reverb-g2-small-sweet-spots-observations-and-solutions/343611/32

https://forums.flightsimulator.com/t/feature-request-cockpit-size-and-world-scale-in-vr/338584

I'm experiencing all of that. Every single thing.

I'll post the log file tomorrow.

I also have another question: the Reverb G2 gets an automatic FOV setting of 93deg which is just wrong and the world scale is off.

It should be 90deg (maybe 91 as the HMD should report 90.8xdeg). LFS is not the only sim where things are off though.

I'm curious where those magic 93deg come from. Maybe that's a hint to another WMR/OpenVR bug? FOV is perfectly set ob my other HMDs (Pimax 8kx, Rift CV1 and Quest 2).

I have opened an issue here as I didn't want to derail this thread):
https://www.lfs.net/forum/thread/94919-Reverb-G2---wrong-%28impossible%29-vertical-%28automatic%29-FOV-of-93deg

Just came from more A/B/C testing between Rift CV1, Pimax 8kx and the G2 and world scale definitely feels off in the Reverb G2 on the "Automatic" FOV setting. 90 deg feel fine and natural, 93 feels like toy cars and wrong proportions/scale.

Last edited by bberger, Thu, 7 Jan 2021 11:38. Reason : Removed comment about IPD, was my bad. Rest still applies.

I'm having world scale issues in the G2 across multiple sims and I don't know where to start as I don't have any contacts at HP or MS, so maybe you (Scawen) can shed some light onto this. I can help debug it, but I need assistance doing so.

---

I measured the FOV the G2 in ROV 1.2beta again today and it maxes out at 90 vertical and 100 horizontal. The 90/100 deg values are confirmed by this chart: https://risa2000.github.io/hmdgdb/

I looked up the "automatic" FOV setting from Live for Speed - and it gets reported as 93deg vertical (that is derived from what WMR/OpenVR reports I assume?) - which is impossible as it stops rendering past 90deg. If I manually override it and set it to 90deg vertical and world scale seems fine and on par with my other HMDs.

So right now I don't know where to start.

Last edited by bberger, Sat, 9 Jan 2021 01:33.

Was this patch ever released? I think I'm having the same problem on a Reverb G2.

On both 6U and 6U12-TEST I can see my vision jumping up and down if I rapidly close the left and right eye.

It seems way better with the linked patch.

I just wanted to say thank you for picking up working on LFS again. I've been around here since god knows how long and LFS is still the first thing I fire up when testing new equipment.

It's also my absolute VR benchmark, nobody does head movement and mirrors better than LFS - and all of that while being very light on graphics.

So - thank you!

<3 <3 <3 <3 <3 <3 way nicer than my DIY approach

lol..

I just went into this forums because I wanted some help coding something like this - but using the Logitech SDK..

but sadly I am unable to find any hints how to access this Profiler-feature? Maybe you could paste me some useful hints?

regards,
bb

Maybe ScaViEr started to join the iR community and just forgot that LFS ever happened.. it's just sad that they don't state ANYTHING to their community..

I think many people would at least be happier if they'd tell us "hey, we just quit on LFS, sry folks" rather than no information whatsoever at all..

Quote from Blade3562 :

I ran across an LFS Dashboard app for my phone but how the heck do I use it? lol
EDIT: Got it just wasn't connected to the right wifi network!

could you post your source?

Quote from Isehwurscht :

Not working.

An attempt was made to load a program with an incorrect format.
(Exception from HRESULT: 0x8007000B)

I just tested that exact same build (7/64bit) and it surprisingly works fine for me..

BUT: I had the same error with the original build.

So this leaves 2 possible options available for you to check:
a) are you sure you've started the correct build and not accidently mistaken it with the original one?
b) is the .NET 2.0 framework installed on your pc?

Frankly I was disappointed as the original build didn't work for me under Win7/x64, but I was as surprised and happy as a monkey finding a banana that the 64bit-build worked out of the box

Quote from Electrik Kar :

I'm pretty sure the textures work properly with the latest version of LFS. I think it was 'Z' which changed the texture directory structure slightly but Unseen and I updated our pack to accommodate this.

Thanks, that's what I ment I know that they work, just wasn't sure if there was anything taken into the Z-Patch and about how much difference it really makes

sorry for gravedigging but does anyone know if there actually had been some outcome of this?

Does anyone know if any of his texture updates made it into patch Z as Kyoto, Aston, Westhill and Blackwood 2.0 were initially made for Patch Y?

X-Mas along with an S3 license, Rockingham and a Track Editor