The online racing simulator
Searching in All forums
(705 results)
Scawen
Developer
Thanks! Great to know that it does the rotated views correctly.

About the IPD, please could you try with the attached DLL when convenient?

I don't know why the Pimax drivers aren't sending an 'event' when the IPD changes. So I'm trying a different way in this DLL. It checks the head to eye matrix every frame and generates its own event if the IPD changes.


I see you edited your post, where you had mentioned something about the IPD popup overlay. I guess you found the solution. I don't think LFS could affect that type of overlay in any way.


Thanks for the tests! Smile
Scawen
Developer
OK, here is a test patch which I hope will work correctly with Pimax in native mode (with PP disabled).

Please give it a go and let me know how it goes.

I'd also like to know if your IPD adjustments are taking effect in LFS.
You should see a message at the top left when you adjust the IPD.

I'd also like to see the contents of a log file (LFS\ovr_deb.log) if it works or doesn't work.


Installation

A FULL version of LFS 0.6T must already be installed

To install the PATCH:

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.6T2


Changes from 0.6T to 0.6T2

VR:

Updated to the latest version of OpenVR (1.2.10)
Pimax headsets can now be used in native mode (rotated eye views)
FIX: An OpenVR error caused Samsung Odyssey+ eye levels to be wrong
Some info is logged to a text file ovr_deb.log in OpenVR mode

Interface:

Faster saving of screenshots when you press CTRL+S
New key CTRL+P to copy the LFS window to clipboard excluding border
FIX: Some narrow unicode characters corrupted by an incorrect width
FIX: Host options could state "no bans" before clicking "edit bans"
FIX: Character dialog could be messed up when selecting languages

Misc:

FIX: Crash 0xc0000005 at offset 0x00159069 loading corrupted object
FIX: Attributes no longer copied when opening file by command line


Download:

EDIT: updated the download link to a version 'V2' using the same LFS.exe
but with an updated LFSOpenVR.dll to fix the Pimax IPD reporting issue.
https://www.lfs.net/file_lfs.php?name=LFS_PATCH_6T_TO_6T2_V2.exe
Last edited by Scawen, .
Scawen
Developer
I should be able to release a new test this afternoon with a test version of support for native (non-PP) mode.
Scawen
Developer
Thanks for the test and logs.

Quote from Gavin Kay :Needed to restart SteamVR for it to work, didn't know that before!

After doing this I think its about perfect for me, how about you emiljensen2?

OK, please can we make this very clear? Are you saying it's OK now, if:

- Use Parallel Projection
- Use the updated LFS DLL
- Restart SteamVR after switching on Parallel Projection?

I found a Pimax forum thread talking about how it works, with diagrams. It looks like to use the Pimax in native mode (not PP) I would need to call another function: IVRSystem::GetEyeToHeadTransform
https://forum.pimaxvr.com/t/some-thoughts-on-the-ipd-discrepancy/14754

I think the native mode would be a more efficient render with a cleaner resulting image and more chance of achieving the correct frame rate because a smaller render target can be used. But definitely needs an LFS update (not just the DLL) as it is only coded for parallel projections at the moment as that's how all headsets were before.

A couple of questions for you:

1) Is the Parallel Projection option something you set in the Pimax drivers, or in SteamVR?
2) What is happening with other games? I'm guessing PP must be enabled for most of them at this stage.
Scawen
Developer
Hi Gavin and emiljensen2, please could you try this test?


EDIT: Please see the new test in a later post:
https://www.lfs.net/forum/post/1946022#post1946022



It will not correct anything, but I would like to see the results in two different modes to help me understand what's going on.

1) Install the test dll attached to this post. It's actually the same one as posted in the Odyssey thread on 24 February.
2) Enable Parallel Projection, enter VR mode, exit LFS and rename the log file LFS\ovr_deb.log
3) Disable Parallel Projection, enter VR mode, exit LFS and rename the log file LFS\ovr_deb.log

Then attach the two log files (or paste their contents) into a post here so I can have a closer look.

Thanks.
Last edited by Scawen, .
Scawen
Developer
Seems we've come to the end of this conversation. Negative people are surfacing.

Most people, thank you for the comments, it's good to see a lot of you are very interested in this update.
Scawen
Developer
Quote from three_jump :As it came up a few times now. When you talk about CPU loads (or hardware requirements in general) and optimisation / performance considerations, do you have a specific plattform in mind?
Of course having lean and fast code is always a plus, but with the new lighting system (and tire physics) I would guess some people might to upgrade their PC.

No, I don't have any specific requirements in mind. It's really hard to say, without having loads of computers to test on. That's where the community will come in and we'll have to see how it goes when it goes into public testing. Anyone who struggles with the current LFS version will definitely need to upgrade as the shadow maps are quite heavy and the textures with shine level in the alpha channel take more memory. Also the higher mesh details are becoming a serious graphics card memory consideration. You can't reduce that by selecting half texture resolution.

I think LFS would be completely dead as a business if we only targeted the latest graphics cards. We earn an income from many customers in countries where the latest super gaming rig is just too much to afford, so I really hope that LFS will be able to run well with a lot of cars on track on computers with a few years old performance levels.

On the other hand Eric is using the new features and trying to get the graphics up to a certain level so the graphics card and CPU requirements are increasing.

Quote from 5tag :Okay this looks awesome and all but *for now* can you please limit it to static daytime? Give us the updated tracks to play with first. Dynamic lighting and nighttime opens a whole other can of worms that would push this patch many months further away.

You seem to think Eric already has all the tracks finished and we are just waiting for me now. But that is not the case.

Quote from Bass-Driver :@Scawen:
Did you do something to make it harder to crack this game?
especially after this big update.

Not yet but that is another project on my list.

Lighting, tyre physics and the master server protocol are my priorities.
Scawen
Developer
I'm interested in moon cycle and even the planets, as I do have a general interest in astronomy, so one day I'd like to see the night sky looking right. But that doesn't mean it's 'in the plans'. Of course the moon and planets are a way lower priority than getting the tyres sorted out. So I don't imagine seeing the moon very soon.

At the moment I'm trying to work this into a usable system allowing real time, offset time and static time. Once the system is 'usable' (without going in the editor and manually switching things on or off) then I think I'll be having a look at how the sky could change from day to sunset and night, and making the headlights illuminate the other cars, as these are the most noticeable issues when driving.

The sky transition is one of the toughest things but I will be trying to consider a simple version that can be improved in future.

There are other technical things like separating the ambient artificial lights which are on all the time (pit garages) and lights which are on only at night (floodlights). And making these vary with the sun light and sky light in a physically plausible way, better than the rough version in the animated GIF. Of course artificial lights don't actually vary so that's more of an iris simulation. Also different colour lights and headlight power should be supported.

There are many invisible technical things to do like using the octree to reduce the CPU load of deciding which objects are lit by the headlights of multiple cars, generating the environment map in a more optimal way as the sky changes and many other things that take place behind the scenes when trying to create a convincing world from millions of vertices and triangles.
Scawen
Developer
At the moment I have it so shadow maps are turned off after sunset and headlights are then enabled. The result, at this point, is higher frame rate in the night because the shadow maps are so expensive. But if moonlight is enabled it would be a different story.

Now I'm talking about details before the core system is complete but I think it might be a reasonable option, if moon light is coded, to disable moon light shadows on slower computers. So people don't have to hope for moonless nights.
Scawen
Developer
To be clear, the purpose of the lighting experiment is to allow any time of night or day to be selected. It is to create an acceptable result as time passes from day into night. In no way am I trying to create the best night lighting you can see in a game.

The latest technology has nothing to do with what I am trying to do here. I am trying to do sufficient lighting to allow basic functionality that allows us to share lighting between tracks and for time to pass so that realistic sun positions and 24 hour races could be possible.

I tried quite hard to avoid having to work on night lighting, but couldn't think of a way to limit shared lighting configurations to the times of day we could support, considering that sunrise and sunset times vary so much depending on the track's latitude and the time of year. The new lighting system uses realtime generated shadows so it seems a pity not to allow the sun to move in the sky as time passes, so the tracks always look a little different. This led me reluctantly down the path of the night lighting experiment. I like the results so far, and it doesn't bother me that other games have more advanced lighting systems. I would be disappointed if ours doesn't run at a better frame rate.

By the way, the headlights don't use a texture. They use a shader that calculates the effects of two cones of light with a point source at the headlights and they do diffuse lighting on the surfaces they hit.
Fix for users of OpenVR - specially Samsung Odyssey+
Scawen
Developer
Here is a new version of LFSOpenVR.dll

This version provides a fix for a bug in an OpenVR function. The bug could produce distorted views in headsets in which the lenses are offset up or down from the centre of the screens. When using a Samsung Odyssey+ headset the right eye view appeared higher than the left eye view, causing discomfort. The same problem (but less noticeable) may be there with Vive headsets too.

This version has been built using the latest OpenVR release 1.2.10

For more information you can read the bug report thread: https://www.lfs.net/forum/thread/93043


EDIT: There is now a later version of this fix in Test Patch 0.6T2
Last edited by Scawen, .
Scawen
Developer
Nice cars and drifting! Smile We are interested in providing a much larger flat area at some point. Of course it is a lower priority than getting to a release with the new lighting and new physics.


Here is a new version of LFSOpenVR.dll which is cleaned up and does no logging.

This one works differently and should be future proof even if the bug in OpenVR is fixed (I raised an issue on GitHub but it shouldn't affect us).

It now calls GetProjectionMatrix instead of GetProjectionRaw, then works out the raw values from the matrix, reversing some steps of the ComposeProjection function in the GetProjectionRaw documentation.

https://www.lfs.net/file_lfs.php?name=LFSOpenVR_20190225.zip
Scawen
Developer
Thanks for the log.

My initial calculations show the matrix is consistent with the Tan values, according to the calculation in the GetProjectionRaw documentation, so I don't know what's up there. I'll have another look in LFS tomorrow to see if the interpretation of those values is correct.

No rush with the older Odyssey if your friend is having fun with it. Smile

For now I just thought of one more test you can try if you want to. As I read in some old posts about people who found that UpTan and DownTan seemed to be reversed. So I've just done that here without any real basis for this decision, but it would be an interesting (and strange) result if it did seem to cure the problem.

No need to post the logs from this one.

Old post: https://github.com/ValveSoftware/openvr/issues/110
Last edited by Scawen, .
Scawen
Developer
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/
Scawen
Developer
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.
Scawen
Developer
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?
February Progress Report
Scawen
Developer
Hello Racers,

We aren't ready to do a full progress report this month. Instead, I'll tell you a bit about some experimental work I have been doing.

DISCLAIMER: This work is unfinished and there are many issues left to solve. At this point it is not certain that it will be released. This must be taken in the spirit of a progress report, showing experimental work that sometimes takes place behind the scenes.

The story behind the experiments:

- Because of the way the new lighting works, it should be possible to share lighting configurations between tracks and have realistic sun directions. There is no longer a need to have a limited number of lighting setups per track.

- In a test version of Live for Speed I can set date and time and the sun direction is calculated from that info, along with the latitude of the track.

- The problem then becomes how to limit the time settings to the times of day we can support. One possible answer is to allow all times of day and night, which in turn would allow the lighting to change through time. That led to this experiment with headlights.

You can click here to see a 6 second animated GIF of a 24 hour period in the summer at Aston. Please bear in mind it's just a work in progress. The sky doesn't change and is simply darkened after sunset. The changing sky and sunlight is very roughly done in this quick test and is something that needs to be worked on if this experimental work is to be released. Other work includes making the cars receive light from headlights, improving the floodlights, etc.

I hope you like these early shots of work in progress.
Scawen
Developer
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.

Scawen
Developer
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.
Scawen
Developer
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.
Scawen
Developer
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.

Scawen
Developer
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.

Scawen
Developer
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.
Scawen
Developer
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.
Scawen
Developer
Thanks, banned willianarmax.
FGED GREDG RDFGDR GSFDG