Does the new tyre physics have more realistic grip reaction to heat? The current ones make driving on overheated tyres feel like driving on ice track. It's the only big setback physics wise i've came across in LFS.
Seems like i have to upgrade my PC. I doubt my old R9 380 and FX8320 are able to run the new LFS in VR.
I made a step forward in tyre physics last week. Although there is still a lot to do, I thought it would be good to try a test of the 1000Hz updates this week (nothing to do with tyre physics but may help with separating physics and graphics onto separate threads, along with other advantages). I was able to get a first version running in a day and worked another day searching through references to 'turns' and fixing various issues where the code had assumed that each turn was 0.01s. Now it's coded in a flexible way so I can change the update rate and recompile, to get comparisons between the 100Hz and 1000Hz versions. Actually there's a bit more searching to do but I was able to run some tests.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
I kept thinking though. Remembered there may be a good "sledgehammer to crack a nut" type solution. This would be, for the snapshots, store a FULL copy of all the car variables (using direct copies of the entire car and wheel structures). These snapshots can be *written* by the physics system and *read* by the graphics system, but are created without too much brain power, just copy everything. Well, not *everything* for example you wouldn't copy the mesh from one frame to the next. So even this sledgehammer style "copy a snapshot of car" function would need some care and there is always the complication of things like, player spectates car, so car is deleted. But graphics system is still in the process of rendering the car -> crash or mysterious errors.
Some design considerations might cause quite a change. For example, the current physics frames are at 100 Hz. So to render at 60 Hz or any other frame rate, the graphical frames should be an interpolation between two physics frames. This would solve a well known problem that is particularly bad in VR. But there is an alternative solution - do physics frames at 1000 Hz instead of 100 Hz. Then store only the snapshots for the relevant physics frames and render only the nearest physics frame, not interpolated.
For example, with physics at 1000 Hz, rendering at 60 Hz graphically, we could use physics frames with gaps (in ms):
16, 17, 17, 16, 17, 17 (that represents 6 graphical frames in 0.1s).
I don't know if this slight difference between frame times would be humanly perceptible, though I'm sure it would be a lot smoother than any current version of LFS. For example, current LFS rendered at 60 Hz has gaps (in ms):
10, 20, 20, 10, 20, 20 (6 graphical frames in 0.1s).
Anyway, as I said, it's an interesting subject.
But I don't have to think about that now, it's not tyre physics.
Some design considerations might cause quite a change. For example, the current physics frames are at 100 Hz. So to render at 60 Hz or any other frame rate, the graphical frames should be an interpolation between two physics frames. This would solve a well known problem that is particularly bad in VR. But there is an alternative solution - do physics frames at 1000 Hz instead of 100 Hz. Then store only the snapshots for the relevant physics frames and render only the nearest physics frame, not interpolated.
For example, with physics at 1000 Hz, rendering at 60 Hz graphically, we could use physics frames with gaps (in ms):
16, 17, 17, 16, 17, 17 (that represents 6 graphical frames in 0.1s).
I don't know if this slight difference between frame times would be humanly perceptible, though I'm sure it would be a lot smoother than any current version of LFS. For example, current LFS rendered at 60 Hz has gaps (in ms):
10, 20, 20, 10, 20, 20 (6 graphical frames in 0.1s).
Anyway, as I said, it's an interesting subject.
But I don't have to think about that now, it's not tyre physics.
Last edited by Scawen, .
Reason : typo
Yes, you can use this command in LFS :
/vr=X :off / on / rift / openvr - avoid or enter vr mode
and you can affect this command to a button in option screen
/vr=X :off / on / rift / openvr - avoid or enter vr mode
and you can affect this command to a button in option screen
hotkey to switch between VR-3D and 2D?
Is there a way to quickly switch between the 3D-mode of a VR-headset and normal 2D-screen?
A way that does not require to click through the options menu.
I thought there was a button-combo for that but we did not find it.
We were testing mods, so there was lots of clicking through the menu, changing tracks, joining servers etc.
The person with the headset was driving and second person was setting up the races etc.
Using the menus in VR works okay but with a mouse and screen it is bit faster. The problem is that the menu is still rendered in "VR-style" 3D on the screen, so it is sometimes a bit tricky for the non-driver to use the menu if the driver does not hold their head still.
A way that does not require to click through the options menu.
I thought there was a button-combo for that but we did not find it.
We were testing mods, so there was lots of clicking through the menu, changing tracks, joining servers etc.
The person with the headset was driving and second person was setting up the races etc.
Using the menus in VR works okay but with a mouse and screen it is bit faster. The problem is that the menu is still rendered in "VR-style" 3D on the screen, so it is sometimes a bit tricky for the non-driver to use the menu if the driver does not hold their head still.
Detect - a visual spotter from Gum Garage ( © KingOfIce app )
Gum Garage is proud to present and offer "Detect" to the LFS community.
It is the first public release of a GumGarage Tools
"Detect" is a powerfull app conceived and coded by KingOfIce from GUM team.
enterely full insim, it is a very light cpu use and it works fine in VR.
This is a very immersive alerts system. you'll not see your car and others in a helico view ...
you will be alert for near opponents with arrows or triangles system like a spotter.
more the other car is near change the color of the alert indicator !
white : the opponent is approaching
yellow : the opponent is near
red : the opponent is very near ! take care about racing room !
yes, at GumGarage, we are looking for racing room seriously
you can custom your degree of alerts in meters
you can move the display in any place of your screen
you can select beetween 4 display modes of alerts
- a tiny and discreet arrows/triangles
- a massive rectangle
- a dynamique alert mode to follow opponents
- a blip radar like to follow and give distance of the opponents
you can switch off frontview alerts
you can switch off the grey rectangle (used to custom position, and figure your car)
simple to install :
1.Launch LFS
2.type "/insim=29999" anywhere
3.Launch "Detect.exe"
Enjoy clean racing !!
config :
- Win11 : ok
- Win10 : ok
- Win8 : maybe
- Win7 : don't know
the accuracy of the alerts depends on the precise knowledge of the dimensions of the cars.
all official cars were measured by King but the mods had to be estimated. further development of more precise measures is foreseen
"Detect" is the property of KingOfIce.
link for Detect : https://www.lfs.net/forum/post/2004269#post2004269
--
[FR]
Gum Garage est fier de présenter et d’offrir "Détect" à la communauté LFS
Il s’agit de la première version publique d'un outil GumGarage
"Detect" est une application puissante conçue et codée par KingOfIce de l’équipe GUM.
totalement InSim , il est très léger en ressources et fonctionne très bien en VR.
C’est un système d’alertes très immersif. vous ne verrez pas votre voiture et les autres dans une vue hélico ... ; vous serez alerté de la proximité des concurrents avec des flèches ou un système de triangles comme un spotter.
la couleur de l’indicateur d’alerte change avec la distance des autres voitures !
blanc : l’adversaire s’approche
jaune : l’adversaire est proche
rouge : l’adversaire est très proche ! attention au racing room !
oui, au GumGarage, nous sommes tres soucieux du racing room
vous pouvez personnaliser votre degré d’alerte
vous pouvez déplacer l’affichage à n’importe quel endroit de votre écran
vous pouvez sélectionner entre 4 modes d’affichage des alertes
- des flèches/triangles minuscules et discrets
- un rectangle massif
- un mode d’alerte dynamique pour suivre les adversaires
- un radar de blip comme pour suivre et apprecier la distance des adversaires
vous pouvez désactiver les alertes devant vous
vous pouvez désactiver le rectangle gris (utilisé pour la position personnalisée, et symbolisant votre voiture)
simple à installer :
1. Lancer LFS
2. tapez "/insim=29999" n’importe où
3. Lancer"Detect.exe"
Profitez de courses propres !
Config :
- Win10 : ok
- Win8 : peut être
- Win7 : on ne sait pas
l’exactitude des alertes dépend de la connaissance précise des dimensions des voitures.
toutes les voitures officielles ont été mesurées par King mais les mods ont dû être estimés. Le développement de mesures plus précises est prévu.
"Détect" est la propriété de KingOfIce.
edit / Detect is now release as part of Detect & Monitor
more infos here : https://www.lfs.net/forum/post/2004269#post2004269
Last edited by Tomfuel, .
It is set to Alt + F12 by default.
You can set "recenter VR" to a controller button.
- In Options - Controls, select the ALT+ tab
- ALT+F12 should have the text command "/vr reset"
- If not, add it to one of those keys
- Now you can assign that key to a button
You can set "recenter VR" to a controller button.
- In Options - Controls, select the ALT+ tab
- ALT+F12 should have the text command "/vr reset"
- If not, add it to one of those keys
- Now you can assign that key to a button
Yeah most Super GT cars (before going down the special 4-cylinder route) used higher capacity engines from the same manufacturer. Skylines ran VG-based V6 turbos, Supra ran the UZ V8 instead of JZ inline-6 (UZ is lighter than JZ).
Same thing all over Motorsport, GT1 R35 ran VK V8 instead of VR V6, old M3 GTR using P-series V8 instead of S-series inline-6.
As long as it's balanced it should be fine.
Same thing all over Motorsport, GT1 R35 ran VK V8 instead of VR V6, old M3 GTR using P-series V8 instead of S-series inline-6.
As long as it's balanced it should be fine.
I agree that lower power cars can be managed with mouse or even keyboard.
But I clicked through the hotlap charts and most WR and fast times are marked "w" for wheel. With only a few mouse drivers sprinkled inbetween.
In my opinion the big advantage of wheel is not in hotlapping. Hotlapping is basically learning that one excact line and unlimited retries until you get that one perfect run. It helps little in actual racing. In a race one perfect lap means nothing, instead you need many laps that do not have to be 100% at the limit but rather each lap has to be good enough.
You can not always drive the same line because other cars are in the way, you still have to make the turn despite missing the braking point, you have to recover from small and big mistakes. (instead of restarting), you have to fight for positions.
That is where wheel is in my experience much better than mouse. Sometimes mouse drivers do fast times in qualy but then in the race they do not always do as well and have higher DNF rates.
13" screen is tiny. For racing a big screen helps because you can see the apex of turns much better and also see cars beside you. There is a reason why any serious racing sim has support for multi-screen and/or VR. Headphones also help to hear where other cars are.
Thanks for the feedback.
I don't expect everyone to read my long post, but it is quite amusing that my post said, in short, "I want to stop working on mods for now" but quite a few people have taken it as a request for mod-related suggestions. The exact opposite of what I said!
Sorry but these suggestions won't happen now! I'm trying to stop working on mods now, so I'm just fixing a few important things, and leaving a lot of things that *could* be done, on a list for the future.
I really would like to hear from anyone who has seen this bug, I'd like to have an example replay with this problem so I can find out what causes this bug.
It's a good suggestion but that won't be done now. As mentioned before, I want to finish the updated tyre physics so we can release the new graphics version.
I don't think we'll ever support translations for mod descriptions. It would really be too difficult to manage such a system.
Fixed setups might be interesting. But as for all the suggestions, it'll be a whole lot easier to imlpemet new ideas when I only have to implement them into one version instead of two, so that's why I'm trying to stop working on mods now.
No the viewer isn't visible in VR. It would be cool to see the 3D car there but such a system doesn't exist and as with all these things, very hard to have to implement it into two separate versions of LFS. The garage car in VR is like an image, it is drawn flat onto a texture so it works in VR but that is not the case for the viewer.
You can see the virtual keyboard when searching for mods if you press the virtual keyboard button on your controller. If using mouse you'd better press backspace before clicking the search field.
This is probably impractical and certainly will not be done now. At least it's really easy to get to the web page by clicking a link in-game.
OK everyone, I only really want to hear about bugs or issues now. No suggestions please. There is a separate suggestions thread.
I don't expect everyone to read my long post, but it is quite amusing that my post said, in short, "I want to stop working on mods for now" but quite a few people have taken it as a request for mod-related suggestions. The exact opposite of what I said!
Sorry but these suggestions won't happen now! I'm trying to stop working on mods now, so I'm just fixing a few important things, and leaving a lot of things that *could* be done, on a list for the future.
I really would like to hear from anyone who has seen this bug, I'd like to have an example replay with this problem so I can find out what causes this bug.
It's a good suggestion but that won't be done now. As mentioned before, I want to finish the updated tyre physics so we can release the new graphics version.
I don't think we'll ever support translations for mod descriptions. It would really be too difficult to manage such a system.
Fixed setups might be interesting. But as for all the suggestions, it'll be a whole lot easier to imlpemet new ideas when I only have to implement them into one version instead of two, so that's why I'm trying to stop working on mods now.
No the viewer isn't visible in VR. It would be cool to see the 3D car there but such a system doesn't exist and as with all these things, very hard to have to implement it into two separate versions of LFS. The garage car in VR is like an image, it is drawn flat onto a texture so it works in VR but that is not the case for the viewer.
You can see the virtual keyboard when searching for mods if you press the virtual keyboard button on your controller. If using mouse you'd better press backspace before clicking the search field.
This is probably impractical and certainly will not be done now. At least it's really easy to get to the web page by clicking a link in-game.
OK everyone, I only really want to hear about bugs or issues now. No suggestions please. There is a separate suggestions thread.
Hi i can't find the viewer on the 0.7B patch :s maybe add virtual keyboard for searching mod in vr?
Virtual Desktop is a piece of software which works on the Quest 2 which allows you to use VR wirelessly instead of using a cable. I managed to get LFS VR working using Steam VR and Virtual desktop.
https://www.vrdesktop.net/
https://www.vrdesktop.net/
Can you open LFS in normal desktop, then run LFS in 3D then?
To run LFS in 3D, while in program, you need to SHIFT O, then choose 3D option at top of screen.
And what kind of VR kit are you using?
To run LFS in 3D, while in program, you need to SHIFT O, then choose 3D option at top of screen.
And what kind of VR kit are you using?
LFS in VR with Virtual Desktop?
Hello all,
I am very interested in playing LFS in VR and I have all the hardware for it, however I can not seem to find a way to get LFS to work in Virtual Desktop. I can not use Link/AirLink as they have failed for me and do not work properly. Is there any way to use Virtual Desktop?
Cheers,
calders
I am very interested in playing LFS in VR and I have all the hardware for it, however I can not seem to find a way to get LFS to work in Virtual Desktop. I can not use Link/AirLink as they have failed for me and do not work properly. Is there any way to use Virtual Desktop?
Cheers,
calders
very nice responses guys.
indeed I am planning to show how good the interface is and how easy it is to work everything out. as for VR mirrors yoyoML , yes LFS is YEARS ahead of the competition. farcar I have to admit that sounds aren't atrocious , but certainly it's an area that could use an improvement.
indeed I am planning to show how good the interface is and how easy it is to work everything out. as for VR mirrors yoyoML , yes LFS is YEARS ahead of the competition. farcar I have to admit that sounds aren't atrocious , but certainly it's an area that could use an improvement.
IIRC, LFS has the only VR mirror implementation where, if you move your head around a bit, the mirror reflection changes based on your current head position.
Not sure if the mirror reflection is rendered with stereo separation though.
Not sure if the mirror reflection is rendered with stereo separation though.
Simulate VR headset render
Hello [Scawen ?),
If someone wants to test the possibility of running LFS with a VR headset, is it possible to simulate all the graphical computation load that it would generate?
I see in View > 3D the choice "3D viewer" which seems interestning to test but it does not seem to be possible to define the computed resolution (eg: simulate the graphic calculation of an image 4000x1000 if we want to acquire a VR headset 2 x 2000x1000).
How to test this?
If someone wants to test the possibility of running LFS with a VR headset, is it possible to simulate all the graphical computation load that it would generate?
I see in View > 3D the choice "3D viewer" which seems interestning to test but it does not seem to be possible to define the computed resolution (eg: simulate the graphic calculation of an image 4000x1000 if we want to acquire a VR headset 2 x 2000x1000).
How to test this?
It would be nice if VR Click could be used to rotate the view in garage like the left mouse button can, now.
Is there any consideration to quell review bombing in the public review forum? It seems as though everything's getting hit by 1-star ratings pretty quickly.
-----
Unrelated to the update in particular, but I noticed today that I've run out of options to map functions to my wheel + button box. Since all of my wheel's buttons can now be mapped (thanks to 0.6W I believe), I have every CTRL- and Shift-F# setting doing custom input duty (mostly for things like replay and camera control, live FFB adjustment, and turn signals). Just putting it out there that I'd be in favour of extended control settings to allow direct controller binding of many of LFS's other functions, such as those with reserved keys.
An even more minor desire is to have finer granularity of FFB adjustment, as `/press less` and `/press more` make adjustments in steps of 5 which is a lot when I hover around a setting of 20 to get decent dynamic range in force effects.
Keep up the great work -- LFS development continues to impress!
Is there any consideration to quell review bombing in the public review forum? It seems as though everything's getting hit by 1-star ratings pretty quickly.
-----
Unrelated to the update in particular, but I noticed today that I've run out of options to map functions to my wheel + button box. Since all of my wheel's buttons can now be mapped (thanks to 0.6W I believe), I have every CTRL- and Shift-F# setting doing custom input duty (mostly for things like replay and camera control, live FFB adjustment, and turn signals). Just putting it out there that I'd be in favour of extended control settings to allow direct controller binding of many of LFS's other functions, such as those with reserved keys.
An even more minor desire is to have finer granularity of FFB adjustment, as `/press less` and `/press more` make adjustments in steps of 5 which is a lot when I hover around a setting of 20 to get decent dynamic range in force effects.
Keep up the great work -- LFS development continues to impress!
OK, I've added that, thanks.
Zooming in doesn't look good on that as:
- the vehicle is actually rendered onto a texture there so it works in VR without coding up a full stereoscopic view for that screen
- if you zoom in then the vehicle is cut off at the edges of the texture
- anyway it wouldn't look that good behind the buttons
I guess it's easy enough to press S to toggle the viewer mode?
How do I play in VR please? Got Reverb G2 as well.
LFS 0.7a + Oculus Rift DK2
Hoy hey
I recently updated my LFS 0.7v to ‘a’ and my Oculus Rift DK2 stopped working.
Although it also didn’t work natively with ‘v’ version, I replaced some DLL file with the one supporting Oculus runtime v 0.8 https://www.lfs.net/file_lfs.php?name=LFSRiftVR_dll_6M.zip.
Now, when native DLL is replaced wirh one from archive above, the LFS throws error about unrecognised vr dll.
Is there any chance to get LFS 0.7a working with Oculus runtime 0.8?
I recently updated my LFS 0.7v to ‘a’ and my Oculus Rift DK2 stopped working.
Although it also didn’t work natively with ‘v’ version, I replaced some DLL file with the one supporting Oculus runtime v 0.8 https://www.lfs.net/file_lfs.php?name=LFSRiftVR_dll_6M.zip.
Now, when native DLL is replaced wirh one from archive above, the LFS throws error about unrecognised vr dll.
Is there any chance to get LFS 0.7a working with Oculus runtime 0.8?
I tried to reproduce it again and I failed. The VR headset axis were visibly assigned to look axis yaw and pitch in control menu which is normally hidden and view was indeed linked to headset position.
But I can't reproduce it so let's forget it.
But I can't reproduce it so let's forget it.
I don't really know what you mean by VR look axes. When I use VR there is no use of controller axes to rotate the view.
If I return to 2D view, the VR headset is fully disconnected and the game is back to full 2D mode.
If I return to 2D view, the VR headset is fully disconnected and the game is back to full 2D mode.
I have found another small issue.
3D is on. Launch LFS.
switch to 2D views.
Look axis are still asigned to VR axis and it can be a problem.
For exemple if you go straight to a replay now you see that the view is bad and only way to change it is to exit replay menu then go to option controls and unassign look axes. I know how to do it but some people will struggle on first time.
Suggested correction when switching 3D view to 2D view. Unassign VR look axis.
Other workaround less clean would be to allow remove axis within replay menu. but it is less nice imho.
Not huge priority but it would be nice. i might not be the only one who watch replay in 2D and play in 3D.
3D is on. Launch LFS.
switch to 2D views.
Look axis are still asigned to VR axis and it can be a problem.
For exemple if you go straight to a replay now you see that the view is bad and only way to change it is to exit replay menu then go to option controls and unassign look axes. I know how to do it but some people will struggle on first time.
Suggested correction when switching 3D view to 2D view. Unassign VR look axis.
Other workaround less clean would be to allow remove axis within replay menu. but it is less nice imho.
Not huge priority but it would be nice. i might not be the only one who watch replay in 2D and play in 3D.
Enjoying this for the most part. Bunch of small things though:
Default caster is pretty rough on FFB (pretty much instantly clipping when turning at all) but a personal setup fixes that (2-2.5 is good for me and my wheel).
The side mirrors' mounting arms clip into the body of the bus slightly.
The... buttons? dials? in the inner "center" button cluster which have the red/white "umbrella" pattern ("GEN" and "Undo Accident") look odd, with the red being on top of the rest or perhaps the white having backwards normals or something.
The "outer" button labels don't flip properly, only really obvious with the EPC label.
Minor clipping on the wipers where the lower/inner arms cross over the blades.
And the smallest issue of all: the head unit is smaller than real ones by maybe 30-40% -- there's no way I could fit a cassette in the loader. But this is only noticeable in VR I'm sure where depth perception and perception of scale exist.
But the driving itself is fine, and all of these things are varying degrees of minor.
Default caster is pretty rough on FFB (pretty much instantly clipping when turning at all) but a personal setup fixes that (2-2.5 is good for me and my wheel).
The side mirrors' mounting arms clip into the body of the bus slightly.
The... buttons? dials? in the inner "center" button cluster which have the red/white "umbrella" pattern ("GEN" and "Undo Accident") look odd, with the red being on top of the rest or perhaps the white having backwards normals or something.
The "outer" button labels don't flip properly, only really obvious with the EPC label.
Minor clipping on the wipers where the lower/inner arms cross over the blades.
And the smallest issue of all: the head unit is smaller than real ones by maybe 30-40% -- there's no way I could fit a cassette in the loader. But this is only noticeable in VR I'm sure where depth perception and perception of scale exist.
But the driving itself is fine, and all of these things are varying degrees of minor.
FGED GREDG RDFGDR GSFDG