Thanks for the feedback on the tree fix. Even though they aren't included in the new LFS, it was worth a quick fix.

As you say, the overhead names have not changed. Please could you test with PP and see if there is any problem with the names in that case. So I'll know if I need to have a look into the names drawn in rotated eye views.

EDIT: Had a quick look in the code and I'm pretty sure they are suffering from a similar thing to the tree issue you noticed. I can reproduce it in a special view mode here. For example they might look a bit odd if you tilt your head left and right. It's something to do with them turning to face the user and it's only getting that value as if the eyes were not rotated. It assumes both eye views have the same direction. So I don't really need another test result at this point. Thanks for the report.

Last edited by Scawen, yesterday, 21:53.

Quote from AndyG :

I'm not convinced it's the case here. In 2D mode if I turn VSYNC on (which is 60fps for my screen), it runs perfectly smoothly. Similarly, 300fps with VSYNC off is smooth.

I still think it may be the same issue. It just depends what you call severe. The 100Hz physics displayed at 90Hz issue can be quite bad when you look sideways. A definite problem.

You can see the same effect with 60Hz VSync on a monitor, it just doesn't look as bad as it does in VR. To try it, select a low FOV then drive along beside something big and nearby, e.g. pit garages, looking sideways. You can see the edges seem to be jittering along.

Trouble is it's a major graphics and physics engine redesign to avoid this, there's no quick solution and for sure it's not something I can do in the current public version, I would only do it in the new development version. It's too big a job to code up twice in the two separate diverged code bases.

In that case it should show for "Default driver view :" [in car] selected
and below that it should say "Settings for custom view : (UFR)"

So you can adjust the settings for custom view but that doesn't mean it is the default view.

OK, here's a version in which you can select the "Resolution adjustment" aka PPD / Supersampling.
And you can also select 4x / 8x antialiasing.
https://www.lfs.net/forum/thread/93185

OK, it should be fixed in this test patch.
You can also select the "Resolution adjustment" aka PPD / Supersampling.
https://www.lfs.net/forum/thread/93185

OK, here's a version in which you can select the "Resolution adjustment" aka PPD / Supersampling.
And you can also select 4x / 8x antialiasing.
https://www.lfs.net/forum/thread/93185

OK, please give it a go:
https://www.lfs.net/forum/thread/93185

WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEMS

PLEASE TEST BEFORE YOU POST


Hello Racers,

Here is a new test patch: 0.6U2

It is mainly for VR image quality:
- Resolution adjustment (aka supersampling / PPD)
- Select 4x or 8x multisample antialiasing

Updates and fixes are listed below.

0.6U2 is compatible with 0.6U

- You CAN connect online with 0.6U
- You CAN play replays from 0.6U

Please back up or rename your LFS.exe from version U so you can revert to it if necessary.


Changes from 0.6U to 0.6U2:

VR:

New "Antialiasing" option to select 4x or 8x multisampling
New "Resolution adjustment" slider (also known as supersampling)
Bug affecting some trees in Pimax headsets due to view rotation

Views:

View filter time maximum value increased to 1 second

Misc:

CAR.lfs scripts are reliably run when user car is spawned or reset


INSTALLATION:

A FULL version of LFS 0.6U must already be installed

To install the PATCH using the SELF EXTRACTING ARCHIVE:

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.6U2


DOWNLOADS:

IF YOU ALREADY HAVE 0.6U:
PATCH 0.6U TO 0.6U2 (SELF EXTRACTING ARCHIVE)
www.lfs.net/file_lfs.php?name=LFS_PATCH_6U_TO_6U2.exe (1.0 MB)

Last edited by Scawen, yesterday, 21:24.

I think I've sorted this now, but I'm not sure if maybe it works too much now.

When the user's car is created (at start or leaving pits) or reset (including race restarts) or if you take over the car, then the script is run just after the multiplayer packets have been processed.

The car is fully set up by then and assigned to the user, so the script commands work as expected.

I just wondered if it's too much, doing it when the car is reset, or maybe that is what you want.

I'm planning to release another VR test patch today so you could give it a go then.

Quote from bishtop :

It seems to be detected as a second controller so would that not cause an issue with only one controller being possible to use at a time

For example if i have a gamepad connected along with my wheel i have to select which one for lfs to use which then stops the other controller being possible to use

That's not the case, you just don't select one particular device and then you can use them all at once.

Quote from AndyG :

Just out of interest, why does the "full screen anti-aliasing" (is this MSAA?) LFS graphics option disappear in VR mode? It's there for the mirrors, but not for the main display - I wondered if it was just a bug maybe?

It's full-scene, not full screen (as it works in a window too). But yes, it is multisampling. I think maybe the term is not used much these days, possibly because people might think it refers to supersampling AA, though you can see it described here in the Microsoft documentation for DX9.
https://docs.microsoft.com/en-us/windows/desktop/direct3d9/full-scene-antialiasing

I removed the option and used a fixed value of 4x in VR. It is so important in VR, it should never be switched off. Also it should not be set too high. Too many people just go through and put every setting to the max (and 16x can severely reduce frame rate in some cases) but in the case of VR, performance was the most important thing, so it seemed best to just leave it on the setting that produces the best performance. I think maybe when developing for the Vive there was also a flickering problem when MSAA was disabled, because it didn't have the extra screen copy, so that was another reason to remove the option.

Today I did some research and did a test with a live slider to adjust the super sampling.

It creates a newly sized render target as the slider moves, so I can adjust it in real time. I can see a reduction in shimmering and an increase in sharpness. I think it should be in the next public release but I don't know at this point when that will be.

I did a test with a live slider to adjust this value, creating a render target as the slider moves, so I can adjust it in real time. I see what you mean about the reduction of shimmering and an increase in sharpness.

I think it should be in the next public release (or test patch) but I don't know at this point when that will be.

Last edited by Scawen, Mon, 18 Mar 2019 21:23.

Yeah it is strange. I've continued looking for documentation.

I only found this comment on reddit, which agrees with our interpretation. If you search for "supersampleScale" you can see it.
https://www.reddit.com/r/Vive/comments/6c56n4/new_openvr_advanced_settings_v24/

And I've found out apparently how I can read that setting from the SteamVR settings using a "GetFloat" function. Not sure if maybe it's better to just put a similar slider inside LFS and use that one instead.

What LFS does to get those numbers is simply this:


And that's it.

I've just messed around with these numbers and managed to find where they get this 2141x2669.

From the LFS output above (per eye) from GetRecommendedRenderTargetSize:
rec_w = 1748
rec_h = 2179

I decided to try the square root of 150% - that is 1.224745

Now, multiply the plain figures from GetRecommendedRenderTargetSize:
rec_w: 1748 * sqrt(1.5) = 2140.85
rec_h: 2179 * sqrt(1.5) = 2668.72

Maybe the VR program (LFS) is supposed to read this supersampling number, take the square root of it then multiply the width and height of the recommended render target size. Strange that I can't find documentation.

Did you see what size the render target is in LFS? It's on the right in view options. Or maybe you could post the ovr_deb.log you should find in your LFS folder?

Thanks.

I definitely can understand the use of true supersampling instead of multisampling. Rendering, for example, a double width and double height render target then blending every 4 pixels down to a single pixel could give some good results. The only problem in that case is the huge render target before the downsampling.

It's something I could try in LFS. But is it the best approach to do such 'brute force' supersampling within the LFS code, or is there some clever supersampling inside the OpenVR system that we can take advantage of? I can't seem to find any documentation.

Hi Magic, thanks for the feedback and the suggestion about the filtered view which some people like, although it's a bit different from yours.

About antialiasing, multisampling is switched on in VR mode, but there's no option.

About supersampling, I can see these values "allowSupersampleFiltering" and "supersampleScale" in openvr.h but I can't find any documentation on how to use them.

If it's about using an extra large render target texture (even more massive than the already extremely massive one) I've never understood the reason to use an oversize render target. Using the recommended values from the drivers, the render target pixel size at the centre matches the screen pixel size. Unfortunately, because of the way VR lenses work, as you move out from the centre the render target pixels become more and more frequent per output pixel (in other words, anywhere out from the centre, it would be ideal to have a *lower* resolution render target, not higher). Why I say 'unfortunately': There is a higher pixel density in the peripheral vision where you need it least which is a performance hit. The best results from texture mapping in general are when the texture map pixels are about the same size as the output pixels, so I can't understand the need to deliberately increase the source pixel density which should just make the output image worse.

Thanks, I think I have some idea what it is now. Probably a more subtle effect than I was imagining from your first post on this issue. Now I see that the trees are at least in the right place but it's the individual branches and leaf objects that will have an unexpected rotation. And it would only affect the trees, not those other things I mentioned. It's related to a sort of trick with those trees. In fact we aren't using them in the new graphics system because they didn't work with the new shadows.

I'll try to think of a way to see this for myself without a Pimax.

The video doesn't work for me at the moment but I'll probably have a look tomorrow.

Do you mean IPD? The distance between the pupils?

That comes from the driver software. You can see the result of it on the right in Options - View.

With some headsets you can change the IPD live and you should see that LFS notices the change and displays that with a message.

I can't understand why that happens. If I use a modified DLL to send in the Pimax values and render the special rotated views, the trees just move around with the other objects as expected.

The trees do go through a different render system, because they are moving objects, but they are all rendered to the same render target and LFS is supposed to be in control of that. Some other objects go through that system: the driver body, the wind turbines, the marshals, the skid marks, tyres on cars, the visible frame on the MRT and the suspension parts on single seaters and LX cars, the racing line (when you press 4). Quite a lot in fact.

As I can't reproduce the problem, I need to ask you some questions:

1) I'd be interested to know if there is a problem with any of the other special objects listed above.

2) Can you post a screenshot of the problem? Please switch on the "double" option for "Monitor view" so you see both eye views on the LFS window. Then you can press CTRL+S at any time and you should find a screenshot in your data\shots folder.

I've only seen a similar thing before with some 3D glasses which were trying to hook into the D3D code to produce a 3D image from programs that weren't designed to produce 3D images. But they didn't really know what to do with anything that didn't go through the main pipeline, so all those objects I listed were not positioned correctly. But that shouldn't be happening here as LFS does the 3D views itself.

It's not really possible in the current version but I do hope to sort out this issue in the future.

The proper solution seems somehow connected with a multithreaded system where the graphics and physics run on separate threads, making use of at least two CPU cores.

That's something I want to get onto but there is no way I can implement that in the current public version.

I don't know for sure the reason for the 90 degree limit for the main monitor. It may be that the maths for the side monitors could go crazy with excessive FOV, so it needed some kind of limit. I can't tell what issues might come up unless I look into it, which I won't do at the moment.

I don't remember ever hearing the limit was a problem. I think the multiple monitor view was designed for realistic FOV and I don't imagine anyone sits so close to their monitor that 90 degrees could be realistic. Your eyes would need to be closer to the screen than half its width. So I guess I was thinking that the limit would allow more than anyone could ever need.

I've used a two monitor setup for years and I use right hand drive cars, so the side monitor is on the left and it works well.

Attached image shows my settings.

Last edited by Scawen, Thu, 14 Mar 2019 14:23.

Thanks for the report. Fixed in 0.6U

This is fixed in 0.6U