The online racing simulator
Samsung Odyssey+ (Plus) VR OFFSET BUG - FIXED
I bought Samsung Odessey Plus yesterday. I used Odyssey 1gen before and all was good. But in Odyssey+ something wrong with IPD. Only in LFS. I tried 5-6 SteamVR games + few WMR games and they are all ok.
When I run LFS - my eyes feeling like "lazy" eyes. I Can't focus. Looks like the LFS read IPD incorrect and building image to second eye with more padding then need.
I still have Odyssey 1st gen, and when I switch to it - all is ok.
I spent 6+ hours in trying to fix it with SteamVR and WMR preferences. No effect.
Hope Scawen can help you with that my friend.
Hi, you can see the IPD that LFS has read from the drivers.

Please have a look in Options... View.

IPD should be on the right side, below render target.
I've compared IPD in Windows Mixed Reality debug window and IPD that LFS shows. They have the same values. When I'm changing IPD on headset - LFS shows right values.
But in Odyssey+ I'm feeling how left and right eyes have incorrect IPD. And it's not only horizontal problem . Vertical position between left and right eyes are incorrect too. Looks like right eye have a little bit +right and a little bit +top values.
p.s. I've tested Odyssey+ on two different PC's, with clean last version of LFS. I've tried to use different NVIDIA drivers, different versions of STEAM VR. And I've tried to switch between Odyssey 1gen, and Odyssey+. Every time I used Odyssey 1st gen = all is good, and Odyssey+ had this issue.
It is strange to hear that horizontal and vertical positions are both affected.

It makes me think of one more test. That is to have a look at both eye views simultaneously on the LFS window on your monitor. Normally only one eye view is displayed.

In View Options you should see an option "Monitor view" and you can select "double". Then you should see the whole render target on your monitor and you can see if that has the offset you described. That is the render target that is presented to the driver software.
Ok, I was setup my Odyssey+ headset to - Yaw:0, Pitch:0, Roll:0 in LFS.
Then I took screenshot, and then drew horizontal lines between eyes to compare.
p.s. Atm I can't do same things with Odyssey 1st gen, cuz my friend took it and will back it in a few days. Will do it asap.

See result:
-
(Scawen) DELETED by Scawen
OK, I'm not really sure about it, but can you try the attached DLL?

Quote from README.txt :Installation:

1) Exit LFS
2) Rename the original LFS\dll\LFSOpenVR.dll
3) Copy the test version from this zip file into LFS\dll

Now you can start LFS in the normal way.

There is a very small difference in this version in an attempt to fix a reported bug
when using a Samsung Odyssey+ Headset.

The reported bug is that the right eye looks slightly offset to the right and top.

Values from GetProjectionRaw are used for the left eye but in this test version the
equivalent values for the right eye are created by reflecting the left eye values
instead of calling GetProjectionRaw for the right eye.

Attached files
LFSOpenVR_TEST_20190221.zip - 44.4 KB - 302 views
I've replaced this dll. Looks like now it's a little bit better. But still have incorrect offset.

It's simple to check - when I'm changing IPD on my headset, I see WMR overlay with IPD. This overlay not visible in LFS window on PC monitor. This overlay have no problem with offset. Then I made this steps:
1) I'm closing Right eye.
2) I'm opening slowly right eye and in this moment I'm closing Left eye.
WMR Overlay with IPD settings staying in one position. But LFS image getting offset when I'm trying to do this.
I've got image that I see in headset (with WMR overlay).
First image - SteamVR room. All is ok in this.
Second image - LFS with old dll.
Third image - LFS with new dll.

Check it:



Hi, I still can't think of any reason.

I decided to rebuild the DLL using the latest version of OpenVR. Please have a go with this one.

Quote from README.txt :This version has been built using the latest OpenVR release 1.2.10
(The current public LFS version of the dll was built with 1.0.0)

It is hoped this may fix a reported bug when using a Samsung Odyssey+ Headset.

The reported bug is that the right eye looks slightly offset to the right and top.


Installation:

1) Exit LFS
2) Rename the original LFS\dll\LFSOpenVR.dll
3) Copy the test version from this zip file into LFS\dll

Now you can start LFS in the normal way.

Attached files
LFSOpenVR_TEST_20190222.zip - 44.4 KB - 314 views
Got error with this new dll.
"The procedure entry point VR_InitInternal2 could not be located in DLL ...\LFSOpenVR.dll"
I've replaced openvr_api.dll with new one which I got from SteamVR folder.
There is no error with latest LFSOpenVR.dll now, but offset still bugged :-(
Sorry I forgot to provide the openvr_api.dll

I've attached one here from the latest SDK. It has the date 30 January 2019, probably the same one you have.

Other than that I'm not sure what to do at the moment.
Attached files
openvr_api_20190130.zip - 252.2 KB - 290 views
Yes, it's same version I got from SteamVR folder.
Unfortunately no effect :-(
If you will have some free time I can give you TeamViewer or RDP access to special 24/7 online PC with clean installed Windows, LFS, and connected Odyssey+. You can install any software(debug maybe). May be you will understand whats wrong in realtime.

p.s. I'm afraid that somebody will not pay enough attention when he/she will be using Odyssey+ in LFS with this bug. When you play LFS with this offset, after 5-10 minutes your eyes adapt to it. When I used it for the first time, I noticed that something was wrong, but after 5-10 minutes of trying different settings, I felt that everything is ok. But when I took off the headset after 30 minutes of LFS I couldn't focus in real life. My eyes hurt a lot. Somebody can get serious injury.
Thanks for your help, darkdrive.

I think I should try adding some logging in LFSOpenVR.dll so it will output a text file reporting some of the values it sends to LFS and see if there are any clues in there.

I hope to do that later today.
OK, this one is the same as before but with some initialisation info logged to a text file "ovr_deb.log".
When it's convenient for you, please enter VR mode using this DLL then exit and post the text file here.
It's just a small file with no private info as you can see.

Quote from README.txt :Installation:

1) Exit LFS
2) Rename the original LFS\dll\LFSOpenVR.dll
3) Copy the test version from this zip file into LFS\dll
4) You will also need the OpenVR dll "openvr_api.dll" dated 30 Jan 2019

Now you can start LFS in the normal way.

Attached files
LFSOpenVR_TEST_20190223.zip - 64.3 KB - 310 views
Done:

LFS OVR DEBUG
LFSVR_Open
ProductName: Samsung Windows Mixed Reality 8
Manufacturer: WindowsMR
LFSVR_QueryHMD
RT size: 2846 x 1784
IPD: 0.063
eye L: ltan 1.239 rtan 1.045 utan 1.437 dtan 1.427
eye R: ltan 1.048 rtan 1.228 utan 1.418 dtan 1.433
LFSVR_AcceptSharedTexture
LFSVR_AcceptSharedTexture
size: 2846 x 1784
LFSVR_CreateTextures
size: 2846 x 1784

Thanks.

It seems strange to me that the driver reports different UpTan and DownTan for the two eyes. Those values come directly from the OpenVR function IVRSystem::GetProjectionRaw.

The only reason I can think for them to be different is if the two screens are not mounted level, but that doesn't sound right.

Also I would expect LeftTan of one eye to equal RightTan of the other eye. Here we have similar values but not an exact match.

These values are off by several pixels and I have no idea why that is, but it doesn't seem right to me. It seems like a bug in the driver (although maybe it really is deliberate if the device has an asymmetrical construction regarding lenses and screens).

According to the documentation here: https://github.com/ValveSoftware/openvr/wiki/IVRSystem::GetProjectionRaw

Quote: "Most games should use GetProjectionMatrix instead of this method".

So maybe that is the case and that function that "most games should use" doesn't have the bug, but GetProjectionRaw has the bug?
Might be worth posting a GH issue to clarify if it is wrong or to get a fix? Valve seem to be relatively responsive to the issues on that repo (and GH in general).
Well, can we use GetProjectionMatrix instead of GetProjectionRaw?
Scawen, can you post issue on OpenVR GitHub?
I don't think I can use GetProjectionMatrix.

One thing I wanted to check - do the screens move, with the lenses, when you move the IPD slider? If not, and the lenses move relative to the screens, then there could be a case where the Tan values change when the IPD moves.

LFS does not do that, it gets the Tan values only once at initialisation time, which I do think is the correct thing as I believe they are constant values for the device.

Maybe I'll post an issue but I don't think it's an OpenVR problem, I think it would be a bug in the drivers for this particular headset. So, Samsung or Microsoft I guess.
I've tried to set different IDP's before LFS start. Looks like tan always have same values.
Here is log:

LFS OVR DEBUG
LFSVR_Open
ProductName: Samsung Windows Mixed Reality 8
Manufacturer: WindowsMR
LFSVR_QueryHMD
RT size: 2846 x 1784
IPD: 0.069
eye L: ltan 1.239 rtan 1.045 utan 1.437 dtan 1.427
eye R: ltan 1.048 rtan 1.228 utan 1.418 dtan 1.433
LFSVR_AcceptSharedTexture
LFSVR_AcceptSharedTexture
size: 2846 x 1784
LFSVR_CreateTextures
size: 2846 x 1784


LFS OVR DEBUG
LFSVR_Open
ProductName: Samsung Windows Mixed Reality 8
Manufacturer: WindowsMR
LFSVR_QueryHMD
RT size: 2846 x 1784
IPD: 0.063
eye L: ltan 1.239 rtan 1.045 utan 1.437 dtan 1.427
eye R: ltan 1.048 rtan 1.228 utan 1.418 dtan 1.433
LFSVR_AcceptSharedTexture
LFSVR_AcceptSharedTexture
size: 2846 x 1784
LFSVR_CreateTextures
size: 2846 x 1784


LFS OVR DEBUG
LFSVR_Open
ProductName: Samsung Windows Mixed Reality 8
Manufacturer: WindowsMR
LFSVR_QueryHMD
RT size: 2846 x 1784
IPD: 0.072
eye L: ltan 1.239 rtan 1.045 utan 1.437 dtan 1.427
eye R: ltan 1.048 rtan 1.228 utan 1.418 dtan 1.433
LFSVR_AcceptSharedTexture
LFSVR_AcceptSharedTexture
size: 2846 x 1784
LFSVR_CreateTextures
size: 2846 x 1784

Screens don't move with lenses when I adjust IPD slider.
Thanks for your help.

Another test is attached. It does more logging.

1) When it gets the Tan values (GetProjectionRaw) it now also calls GetProjectionMatrix and logs the values to the file, so we can see if that is asymmetric too. If the matrix is symmetric then the asymmetry in the Tan values must be caused by a bug in drivers or OpenVR.

2) Every time the IPD changes, it logs the results of GetProjectionRaw and GetProjectionMatrix so we can see if these values change when IPD changes. I've always thought not, but let's see. Somehow it seems that if the screens don't move when the lenses move, then maybe the tan values should change as the centre of the lens now points to a different part of the screen...


Test requests:

Please could you do a log test as before, but this time after initialisation, move the IPD adjuster a couple of times so we see the extra logging?

Is it easy to plug in the older Odyssey and see what it logs?


Further info:

I found a couple of mentions of this issue, in the past, but no real answers.
https://forums.frontier.co.uk/showthread.php/251991-Vive-The-depth-of-space/page2
https://steamcommunity.com/app/358720/discussions/0/535150948617380074/
Attached files
LFSOpenVR_TEST_20190224.zip - 64.8 KB - 265 views
1

FGED GREDG RDFGDR GSFDG