EDIT: New test patch with improved support for Oculus 1.3 and CV1.

0.6N2: https://www.lfs.net/forum/thread/89352


Original post from the early test:

I've tried to implement support for the Oculus 1.3 software. I can't test it myself because the Oculus software just crashes on my computer.

Anyone who has successfully installed the 1.3 software, please could you try this attached DLL?

1) Make sure you have the latest Live for Speed (version 0.6N)
2) Open the attached ZIP file
3) Open your LFS\dll folder where you will find LFSRiftVR.dll - rename it for backup
4) Save this test LFSRiftVR.dll into that folder
5) Run LFS and try to enter VR mode (Options... View... 3D)

In case of DK2 & 1.3 runtime game immediatelly freezes the moment I press "ok" at 3D mode options.
Just noticed LFS on this pc is in M version, gonna update post after I install newer version.
[edit]
Same thing happening at version N - crash after pressing ok in 3D mode options [DK2, 1.3 runtime].

Thanks for the test. That is odd because two people reported it working OK at Oculus forums.
https://forums.oculus.com/developer/discussion/15110/live-for-speed-now-using-sdk-0-8#latest

- Does your DK2 work OK with other 1.3 programs?
- Was there any recovery from the freeze?

As for my DK2 everything from store works fine, 3rd party programs support is enabled in oculus settings but I didn't try anything outside of store yet.
Only way to do anything with LFS after crash is to manually kill process, no sings of any recovery from freeze after 5 minutes.
If it might be of any help I'm using R9 280x with 16.3.2 drivers.

OK, thanks. Just to be sure, is it a freeze (LFS seems to lock up and becomes unresponsive) and not an actual crash?

If it is what I call a crash then Windows should say it has stopped working and offer you some more information.

Yes, it was LFS freeze but I menaged to find out culprit - turns out OVRService is little bit buggy when it comes to DK2 and it just randomly crashed/froze with high cpu usage and no response.
So turns out problem was on my end and I overcome it by restarting OVRService. I'll play LFS for a bit now to see if everything works fine and in case of any crashes and so on you can expect my post here.
Thanks for nice work on this stuff

Thanks for the report!

Works fine with DK2, Thanks.

Oculus Shop opened in the background after switching to VR Mode but game works fine. After exit you are automatically in Oculus Home. I am sure this was already discussed somewhere, but why is LFS not available (or will be?) in Oculus Shop?

Thanks for the test.

There is quite a bit to do, to make it work fully with the store. For example it needs code to 'obey' the store's commands such as telling LFS to exit immediately or stop rendering while the user switches to the store and back. Some things like that anyway, I'm not sure on all the details. I worked on VR support including the "no mouse and no keyboard" system for the last few weeks as the first step to make it compliant with the store. I find that really useful in VR as you can't see the keyboard. But there is more, for example I think it needs to work straight out of the box with the XBox controller, so that when a user starts LFS from the store for the first time, they can already control it without keyboard or mouse.

So that's on the technical side. It did take a long time for Oculus to get back to me about LFS. After submitting it for consideration in December, I didn't hear back from them until March.

Anyway, they seem to be cooperating more now. I'm interested in continuing to aim for Store inclusion as it would be good exposure for LFS.

Dk2 user reporting: It runs like a dream! No oculus store open. just headset on...(store opens automaticly)
Also using dk2 one needs to set IPD manually in the file: NetServer.cfg

Thanks!

I have one issue though...When looking at the side and driving straight...the fps is reported to be at 75fps in the dk2...but it does clearly not update the graphics at 75fps...while the headset surly is. (im on a gtx 970 btw)

It does actually but the problem is that the physics updates at 100 Hz.
So between some graphics updates you have 1 physics step and between others you have 2.

So I think, each second, you see 25 of these:
1, 1, 2

Your eyes / brain can see this irregularity which happens in a 25 Hz cycle. You can also see this on an ordinary monitor if you enable vertical sync and look sideways.

Quote from Scawen :

It does actually but the problem is that the physics updates at 100 Hz.
So between some graphics updates you have 1 physics step and between others you have 2.

So I think, each second, you see 25 of these:
1, 1, 2

Your eyes / brain can see this irregularity which happens in a 25 Hz cycle. You can also see this on an ordinary monitor if you enable vertical sync and look sideways.

Is it possible to do some interpolation when rendering LFS graphics?

It will eventually break everything though, because the whole game loop would be different, and also input lag can become more of an issue. But if that 100Hz/XHz beat really hurts someone's eyes, it might become a better experience.

But it is the approach that Bullet physics engine (and I am sure, others aswell) applies for example. Basically it looks like this:

1. Get user input
   
2. calculate atleast 100/minimal_fps physical frames (the idea is to render enough frames to get to the point of rendering the next graphical frame, but usually they use something like 5..10 fixed)
   
3. Find 2 closest_to_current_time physical frames and interpolate relatively between them
   
4. Render graphics and sound
   
5. Go to 1
   

Obviously it is not the perfect approach. Ideally we would want our hardware to support setting velocities for each body rendered (idk if there is such technology already, I never digged into modern graphics).

Of course it can be interpolated, if you start with 2, 1, 1 sequence, and interpolate everything to 1.33, 1.33, 1.33.

But somebody (Scawen) has to write it, and it will eat some serious CPU and memory (and memory bandwidth), you basically need to double source data (next frame + previous frame accessible at the same time) plus another memory for target data, plus interpolation calculation..

... hmm.. that said, the question is how much of data has to be copied around, actually it's not like whole world, just things ticking at 100Hz physics engine, so obviously the cars. Cones and stuff may be left not interpolated in worst case..

Anyway, the main limitation is the dev power I think. Scawen is already for few months talking about returning to tires physics, just after that "one more small thing" to fix...

Yes, the best way to do that is have graphics and physics on two different threads, so more CPU power is available for each of them (assuming the CPU has more than 1 core). The physics system must then store interpolatable snapshots of completed physics steps, for the graphics thread to render whenever it is ready.

It's a good system but requires a large overhaul of the program, on the graphics and physics sides. That is fine but, as I keep saying, it's far too difficult to do while I still have two separate versions of LFS, the development version and the public version. This is one of the reasons why the tyre physics is my top priority (after getting past this important month or two for VR). When it is done, we go back to having a single version of LFS. Also it will allow new types of vehicle and so on.

Quote from Scawen :

... Also it will allow new types of vehicle and so on.

do you have examples ?

anyway, glad to see VR is going well, and the development brought to LFS in this way seems to be a good investment overall

Quote from Scawen :

Yes, the best way to do that is have graphics and physics on two different threads, so more CPU power is available for each of them (assuming the CPU has more than 1 core).

That might bring even further input lag, but if it gets configurable, it is allright. I beleive that LFS old-school approach is really the best from input lag prevention perspective (with the sacrifice of being dependent on single threaded CPU performance). Both interpolation and threading should be switchable in order to be able to get maximum performance on each gaming rig.

And indeed it is really difficult. Once threads kick in, you might need to redesign the whole resource management system and also you get some thread switching overhead and who knows what else. There are a lot of challenges and the resulting gain might not look as valuable when you're there. Having said that I hope people would keep themselves patient looking into the future

Any performance/functionality reasons for moving to the 1.3 runtime over the 0.8beta runtime with LFS? Any disadvantages, assuming the test DLL works?

Can the 0.8Beta and 1.3 be installed concurrently? Can the 1.3 software be installed, and the older LFS DLL be used?

I should be able to test 1.3 on a DK2 later this week when the new GPU comes in. Oculus is now insisting that the old GPU that ran at a stable 75FPS in LFS is no longer sufficient when I upgrade the GPU drivers...

The test DLL for LFS does work. The Rift software does not work on my computer (at least with DK2) so I can't tell you if there is a performance increase, or if Asynchronous Timewarp makes any difference. Probably not as LFS makes the frame rate easily and the best thing about AT is compensation when programs miss frames.

0.8 and 1.3 are totally incompatible. If you install 1.3 then you will not be able to run any 0.8 software. If you stick with 0.8 then you can't run any 1.3 software. They cannot both be installed simultaneously, as far as I know.

Disadvantages include the 842 MB download. If anything goes wrong during the installation, it can go wrong with no explanation and you'll have to randomly attempt things and then do the 842 MB download again. There is no actual downloadable file, it's all through the Oculus installer, and if anything goes wrong, you start again. This happened to me. I don't know if it was installing the new NVidia drivers after the failed attempt, but it worked the second time. Only problem now (for me) is the OVRServer crashes every time I plug in the Rift (DK2). So it's completely useless and I can't use my Rift any more.

Other disadvantages are that every time you run a program, even an external program like LFS (aka programs from Unknown Sources) then it starts Oculus Home anyway and it's running in the background with a large memory footprint (apparently 661 MB). Then when you exit whichever program you are running, you are back in Oculus Home and this behaviour cannot be disabled.
https://forums.oculus.com/developer/discussion/32519

If you only use LFS, on a DK2, then I can't see any reason to upgrade yet, unless you would like to try the free demos and so on, but I think you need an Xbox controller or it won't let you run anything from Oculus Home.

About the GPU, someone here is saying that below spec GPUs actually can be used:
https://forums.oculus.com/developer/discussion/32670

Thanks for the information.

In trying to install the Oculus runtime yesterday on a new PC, I installed Oculus Home, skipped the device setup stages when I realised it didn't seem to apply to the DK2, and then managed to get hold of 0.8b again and just installed that over the top.

I assume I've got a broken Oculus 1.3 installation, and will be running 0.8b now.

I'll test our DK2 with a fresh install of 1.3 when the GPU arrives this week, but may end up reverting back to 0.8b from what you've said. At least for now, until things are a little more seamless.

If the Oculus Home app isn't essential for the service to run, it would be nice to be able to add a command-line argument to LFS, so that it could search for and kill the process for me in the background while the game itself loads.

If they're not going to change the current behaviour, it would make a nice optional "developer" flag...

Oculus Runtime Switcher (0.5/0.6/0.7/0.8/1.3) with GUI

https://www.reddit.com/r/oculus/comments/4ckm38/oculus_runtime_switcher_0506070813_with_gui/

I put this on the Oculus forum, but figured it would be good to post it here too:

Dropped in the DLL and the Oculus connected as expected. Windows 7 SP1 x64, Oculus 1.3, CV1

However, the perspective warping (?) is not working correctly. As you look side to side, or up and down, the portions that reach the edge of the view are squished strangely. Lucky's Tale didn't do this, so I'm not sure what's up. It's most immediately noticeable when you're on the settings screen, it distorts in this strange way.

Also, this strange distortion only happens in the Oculus, the mirrored view looks fine, and perspective 'works' as you expect it to.

Thanks for the report.

New test patch with improved support for Oculus 1.3 and CV1.

0.6N2: https://www.lfs.net/forum/thread/89352