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.
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.
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
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
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
FIX: Crash 0xc0000005 at offset 0x00159069 loading corrupted object
FIX: Attributes no longer copied when opening file by command line
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.
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.
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.
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.
Not yet but that is another project on my list.
Lighting, tyre physics and the master server protocol are my priorities.
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.
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.
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.
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
Nice cars and drifting! 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.
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.
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.
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...
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?
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.
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).
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.
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.
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.