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.
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.
THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEMS
PLEASE TEST BEFORE YOU POST
Here is a new test patch: 0.6U6
It is mainly for VR image quality:
- Resolution adjustment (aka supersampling / PPD)
- Select 4x or 8x multisample antialiasing
- Fixes for Pimax headsets
There are also minor graphical improvements and fixes
Updates and fixes are listed below.
0.6U6 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.6U5 to 0.6U6:
Gearshift debounce setting now applies to all controller buttons
Reduced maximum value of gearshift debounce to 100 ms (default 20)
FIX: Memory leak related to threads (most often for skin download)
More translations updated - thank you translators!
Changes from 0.6U to 0.6U5:
Car shadows now use anisotropic filtering to reduce shimmering
View filter time maximum value increased to 1 second
FIX: Filtered view went wrong with low filter time + replay speedup
New "Antialiasing" option to select 4x or 8x multisampling
New "Resolution adjustment" slider (also known as supersampling)
FIX: Head tracking / mirrors wrong if car leaned with horizon lock
FIX: Free view FOV was wrong after entering VR in free view
FIX: Names above cars looked wrong in Pimax headsets
FIX: Some trees looked wrong in Pimax headsets
Easier to set up LAN race: local IP address is shown on host screen
You can enter the local network computer name instead of IP address
CAR.lfs scripts are reliably run when user car is spawned or reset
FIX: Issues with driver names ending with caret character
FIX: Driver names ending with a lead byte could corrupt text
FIX: Replays from old Westhill before 2015 now marked as obsolete
FIX: Rare manual shift at high speed to 1st/rev during auto shift
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.6U6
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.
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.
hmd_info.RTRecommendedW = rec_w * 2; // OpenVR recommended size is for one eye hmd_info.RTRecommendedH = rec_h;
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.
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.
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.
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.