Interesting - thanks! It must mean that in the full wide (E8) view, you also get some kind of cutoff effect near the top of your nose, where the inner part of the view is cut off by the line separating the left and right eye views. I guess the full E8 view must look as if there is a curved piece of cardboard sticking out of your face from the top part of your nose that is between your eyes, restricting how far you can look right with your left eye and how far left with your right eye? Because just at that point, that view goes no further than the E9 view.

Ok,

I did some more tests (with the E8Patch!).

Last time I used the default distance between eyes and lenses.
This time I moved the Rift as close to the eyes as possible (can be adjusted on the side of the Rift with a coin). In this position my eyes almost touch the lenses.
--> The FOV is much higher then, but not really playable (at least for me) because it´s uncomfortable and the lenses become easily dirty.

Anyway see the attachment for the results.
The red dots describe the area, which I can see when i move my eyes around.
The green dots describe the area, which I can see when I look straight forward. Well honestly it´s not really seeing, it´s more like "oh ok , there is something now at the edge". But it´s noticeable.

How come when looking forward, there can be seen more?
I just can explain it in this way: For example when looking to the left, the pupil is more near the lens edge, which hides the view.

Quote from Scawen :

So that I know roughly what a good render size looks like, can you post a Rift screen shot from another game that seems to fill the entire area that you can see, but doesn't draw too many wasted pixels?

I´ve added a picture where the Rifts view and that of the Oculus Tuscany Demo are combined.
When looking at that picture I agree with DickDastardly, that the view shouldn´t be restricted too much.
I have an IPD of 64mm which is exactly the distance of the Rifts lenses. That means my view goes straight through the lenses.

Let´s say someone has a smaller IPD, then it would mean that he could see further to the left and the right...

As I just wrote, the rendered view shouldn´t be reduced too much, because the black borders might get noticeable by some individuals.
But I have a different idea...

What about if the peripheral vision (outside red area) is simply rendered with a very very low resolution, and inside the red area with normal resolution?

Quote from Scawen :

Interesting - thanks! It must mean that in the full wide (E8) view, you also get some kind of cutoff effect near the top of your nose, where the inner part of the view is cut off by the line separating the left and right eye views. I guess the full E8 view must look as if there is a curved piece of cardboard sticking out of your face from the top part of your nose that is between your eyes, restricting how far you can look right with your left eye and how far left with your right eye? Because just at that point, that view goes no further than the E9 view.

The inner border of each eye's view is interesting in that your brain filters it out by merging the views from each eye. You can see this yourself even without a Rift by looking at your nose with both eyes open - you'll barely be able to see it. However, if you shut one eye then you'll now see the side of your nose much more clearly.
Cheers,
DD

P.S. On the "Not yet done" list, the first item "Replay cameras (TV view) must be put on a virtual monitor" is unnecessary -this view doesn't really cause any problems in the Rift and actually looks pretty cool in VR (once you realise that headtracking is disabled and therefore stop moving your head). The only really crucial items remaining IMO are "Move eye position depending on the orientation (simple neck model)" and "Render mirrors in 3d" which is less important but would still be cool, particularly to help shame AAA developers with budgets thousands of times higher than that of LFS into also rendering mirrors correctly .

Quote from just2fast :

What about if the peripheral vision (outside red area) is simply rendered with a very very low resolution, and inside the red area with normal resolution?

Ok but why? If some can see it, then why throw away information?

Quote from Dygear :

Ok but why? If some can see it, then why throw away information?

Because you can´t see it clearly.
Do a test. Look forward and then tell me if you can see details on the left/right/top/down edges of you view.

In the Rift this peripheral area is between the red and green dots (see pictures of my recent post) which is only noticeable when looking straight forward.
When moving the eyes to left/right/top/down, then suddenly the view is limited to the red border.

Anyway the pixelaton is just a theory, but I can imagine it works. The question will be if it´s technically possible and will bring performance benefits.

Pretty sure it would take more GPU power to render those bits at low resolution, as as far as I know it would have to be done separately, then blended with the normal resolution part.

LFS renders the whole 'world' @open layouts compared to first person shooters where the screen is rendered only around the players position. There is no performance benefit with pixelating the stuff outside the eye focus point. Who is having performance issues to begin with? If you cannot run LFS decently on HD resolution then you need to question your 2005 hardware.

Quote from cargame.nl :

If you cannot run LFS decently on HD resolution then you need to question your 2005 hardware.

The thing is that if a bit less of the view could have been rendered, this would save a surprisingly large amount on the render target texture. The multiplier in E8 is about 1.7 but in E9 it was 1.29 so E8 renders (1.7 / 1.29) ^ 2 = around 1.7 times the number of pixels. The E8 render target is much more than HD, in fact it is 1.7 times 1920 wide. And as I was considering adding an extra step before that at double the res again, i.e. for each eye a 3264 x 3264 square, it starts to become significant. For the E9 version it would only have to be 2476 x 2476 (approx). It seems strange because we are talking about such a small area around the edge of the images, but that part has been compressed a lot, so although it is peripheral vision, it it quite expensive to render and requires quite a bit of memory. So it is valid to discuss reducing the rendering of unseen areas.

Some infos regarding the E9 Patch.
With the eyes as close as possible to the lenses the rendered view is not enough, so that there are black borders seen at the edges.
With the default distance (eye-lenses) I can´t really say if it´s some black from the black display area or the plastic lense holder.

I would suggest to reduce the viewport just a little bit compared to the E8 patch.
Maybe using the vertical boundaries exactly from that of the tuscany demo and the horizontal one between the E8 and E9 boundaries.

Ohh and back to the FOV angle discussion
In the E9 Patch a vertical FOV setting of something around 98° seems to be fine. 110-112° is now too much.

A resolution of 1920x1200 with downsampling now has a noticable effect for the better!

Quote from DickDastardly :

P.S. On the "Not yet done" list, the first item "Replay cameras (TV view) must be put on a virtual monitor" is unnecessary -this view doesn't really cause any problems in the Rift and actually looks pretty cool in VR (once you realise that headtracking is disabled and therefore stop moving your head). The only really crucial items remaining IMO are "Move eye position depending on the orientation (simple neck model)" and "Render mirrors in 3d" which is less important but would still be cool, particularly to help shame AAA developers with budgets thousands of times higher than that of LFS into also rendering mirrors correctly .

Thanks for the feedback on the virtual monitor for replays thing. In my test version where I can press CTRL and swing around using the mouse, it looked a bit odd to see the HUD moving while the world stayed put. Seen in the Rift it would be the HUD staying put while the world moves where you look, which sounds quite bad! But it's reassuring that you say it's not too much of a problem, and I'll put that further down the priority list. Well I'll rub out the star beside it on my notes.

Quote from just2fast :

Some infos regarding the E9 Patch.
With the eyes as close as possible to the lenses the rendered view is not enough, so that there are black borders seen at the edges.
With the default distance (eye-lenses) I can´t really say if it´s some black from the black display area or the plastic lense holder.

I would suggest to reduce the viewport just a little bit compared to the E8 patch.
Maybe using the vertical boundaries exactly from that of the tuscany demo and the horizontal one between the E8 and E9 boundaries.

Ohh and back to the FOV angle discussion
In the E9 Patch a vertical FOV setting of something around 98° seems to be fine. 110-112° is now too much.

A resolution of 1920x1200 with downsampling now has a noticable effect for the better!

The other high priority is to get to grips with the FOV calculation. I haven't looked into it properly but there are notes about it in the Rift SDK document. There is an EyeToScreenDistance that is reported by the SDK and is discussed as part of the FOV calculation. So it should be possible to calculate the correct FOV. With lower priority it may be possible to automatically reduce the render size a little for people who use the Rift with the screen a bit further from their eyes and can't see the edges. So a slight reduction in your case but not in Dick's case. Low priority as you are not running out of memory and probably have no frame rate problem either. Your FOV estimates in E8 and E9 will help check that my calculations (based on the Rift documents) are coming out correctly.

Questions :

1) How does the Rift SDK get the value of EyeToScreenDistance? Do you have to enter it manually or does it measure it in some way? I see (from one thread) the default distance is 0.041 [EDIT : apparently this value doesn't change when you use the physical adjusters and is hard coded for each type of Rift so that doesn't sound too good at the moment]

2) Did anyone try predictive tracking? There was hardly a mention of it before so it seems like it works ok at zero. But maybe 10 ms or so could be an improvement?

Quote from Scawen :

Thanks for the feedback on the virtual monitor for replays thing. In my test version where I can press CTRL and swing around using the mouse, it looked a bit odd to see the HUD moving while the world stayed put. Seen in the Rift it would be the HUD staying put while the world moves where you look, which sounds quite bad! But it's reassuring that you say it's not too much of a problem, and I'll put that further down the priority list. Well I'll rub out the star beside it on my notes.

Ah I see the problem you mean now - I assumed you were under the impression that the lack of headtracking in the TV view would cause nausea in VR which it doesn't for me as I keep my head stationary when in the TV view (and normally also toggle the HUD off when watching replays), but if I leave the HUD on and move my head there is indeed an issue as you describe whereby the HUD seems to move in the opposite direction to that in which I move my head. Perhaps this could be solved by reverting to the old HUD behaviour in that one view (i.e. have its position locked to your head/screen rather than the world)?

Quote from Scawen :

The other high priority is to get to grips with the FOV calculation. I haven't looked into it properly but there are notes about it in the Rift SDK document. There is an EyeToScreenDistance that is reported by the SDK and is discussed as part of the FOV calculation. So it should be possible to calculate the correct FOV. With lower priority it may be possible to automatically reduce the render size a little for people who use the Rift with the screen a bit further from their eyes and can't see the edges. So a slight reduction in your case but not in Dick's case. Low priority as you are not running out of memory and probably have no frame rate problem either. Your FOV estimates in E8 and E9 will help check that my calculations (based on the Rift documents) are coming out correctly.

Questions :

1) How does the Rift SDK get the value of EyeToScreenDistance? Do you have to enter it manually or does it measure it in some way? I see (from one thread) the default distance is 0.041 [EDIT : apparently this value doesn't change when you use the physical adjusters and is hard coded for each type of Rift so that doesn't sound too good at the moment]

In the current devkit there is no way for the Rift to automatically get this value as the distance can be manually adjusted and there are no sensors which report its setting (although iirc Oculus did mention an aspiration to read data on this and your IPD in a future more configurable consumer version). As a result I don't think it will be possible for LFS to automatically set the appropriate FOV (although a reasonable default setting can be chosen and this will then have to be tweaked by the user).

Incidentally I've just measured the distance from the screen to the part of the lens nearest the eye and mine's set at nearer 50mm than the 41mm default value you quoted. The 41mm setting must be with the screen set as close to the lens as it will go, which means that at this default setting users can see even more of the screen than I do (making any reduction to the viewable area even more undesirable). Note also that if used as an eye-to-screen distance these measurements assume your eyeball is actually touching the lens.

Quote from Scawen :

2) Did anyone try predictive tracking? There was hardly a mention of it before so it seems like it works ok at zero. But maybe 10 ms or so could be an improvement?

I've experimented with values of 0, 10 and 20ms but tbh didn't see much difference. I generally leave it set at 20ms.
Cheers,
DD

Quote from Scawen :

1) How does the Rift SDK get the value of EyeToScreenDistance? Do you have to enter it manually or does it measure it in some way? I see (from one thread) the default distance is 0.041 [EDIT : apparently this value doesn't change when you use the physical adjusters and is hard coded for each type of Rift so that doesn't sound too good at the moment]

No idea, what this value should be. The only values that can be set atm in the ConfigUtility are the eye cups (A,B,C), IPD and Player Height.

Quote from Scawen :

The other high priority is to get to grips with the FOV calculation.

I have one more for the hight priority list pleeaaaaaaaseeeee :bowdown:
Can you couple the mouse pointer with the rifts view. So that the mouse pointer is like attached to the nose, but on HUD level? And the possibility to assign a wheel button as left mouse button? That would be really great.
In this way there would be no need to lift the Rift always up and search for the mouse. Instead the whole navigation through the menus can be done with the Rift!

For example I am sitting in a racing seat which stays 1m away from my desk.
A wirelwss keyboard is next to me, but the mouse is on the desk. So it´s a bit annoying when switching some settings in lfs. Always lift the Rift up, leave the chair, make settings, go back to the seat, put rift on again...

This implementation might be also a good basis for future improvements. For example in this way the whole buttons (lights, horn...) in the virtual cockpit can be pressed!

Quote from Scawen :

OK, just interested to see if this version does restrict what you can see.

I sounds like everyone else is experiencing some black bars with E9, but I personally can't see them here (I'm using the B lenses on the closest setting). The distance adjustment FYI is a fairly clunky physical screw on the sides, so I seriously doubt that they have anything to automatically detect it.

Quote from Scawen :

The only other change is that the scale button goes up to 1.0 instead of 0.8 maximum.

Thanks so much for putting that it... unfortunately, I have to own up and say it was a completely dumb suggestion (sorry about that!). Once I had it maxed out, the screen obviously got harder to read again (and didn't magically make it higher resolution). Then increasing the size of the HUD, makes it appear closer again! (With the surrounding empty space and nothing to relate it to, I guess size and distance are effectively the same thing!).

Anyways, still enjoying playing LFS again a lot! A quick recommendation for the rift owners... try Lesson 26 in the training (MRT - autocross). I think I'm going to look around for more autocross courses, as that is just crazy fun with the rift and being able to look around is fantastic!

Quote from Strien :

I sounds like everyone else is experiencing some black bars with E9, but I personally can't see them here (I'm using the B lenses on the closest setting).

The B cups give you a lower FOV than the A cups. And the C cups are even more worse than the B cups. Thats why I only use the A cups and wearing contact lenses

Quote from just2fast :

Can you couple the mouse pointer with the rifts view....
....For example I am sitting in a racing seat which stays 1m away from my desk.
A wirelwss keyboard is next to me, but the mouse is on the desk. So it´s a bit annoying when switching some settings in lfs. Always lift the Rift up, leave the chair, make settings, go back to the seat, put rift on again...

Scawen, here you can see what I mean. This guy has the same issues (in this case with iRacing):
http://www.youtube.com/watch?f ... e&v=x-hX70oWZSI#t=663

And this is how other games solve it. For example the VR jam Winner "ciess". Simple but very entertaining game:

http://www.youtube.com/watch?f ... e&v=aIYfUkQtFh0#t=275

Hi,

I bought LFS specifically for the Oculus Rift integration, and was able to run it once in demo mode (very cool, by the way!). I immediately purchased a license, but now I'm having several problems:

(1) As soon as I purchased unlocked with my license, I am no longer able to use the RIFT. If I select '3D' in the view options and click the field to select the Oculsu Rift, the menu pops up for about 1 millisecond and immediately disappears. This happens for both the E8 and E9 patch.

(2) I thought a reinstall might fix the problem, since the menu glitch did not happen before the unlock, but it's still there. Even worse, I can't use my license any more! If I enter my username and password it just says 'unknown version'. Do I have to buy a new license even if the original was only used for 5 minutes?

(3) There is now a loud, continuous beeping both in game and in the menu when I select "single player". It makes it impossible to use any sound at all, just have to turn the headphones off. Is this because my license won't work anymore?

Quote from slakmehl :

Hi,

I bought LFS specifically for the Oculus Rift integration, and was able to run it once in demo mode (very cool, by the way!). I immediately purchased a license, but now I'm having several problems:

(1) As soon as I purchased unlocked with my license, I am no longer able to use the RIFT. If I select '3D' in the view options and click the field to select the Oculsu Rift, the menu pops up for about 1 millisecond and immediately disappears. This happens for both the E8 and E9 patch.

(2) I thought a reinstall might fix the problem, since the menu glitch did not happen before the unlock, but it's still there. Even worse, I can't use my license any more! If I enter my username and password it just says 'unknown version'. Do I have to buy a new license even if the original was only used for 5 minutes?

(3) There is now a loud, continuous beeping both in game and in the menu when I select "single player". It makes it impossible to use any sound at all, just have to turn the headphones off. Is this because my license won't work anymore?

Update on this:

On (1), I still have the same problem with the menu not displaying, but the Alt+F11 shortcut does still work for enabling/disabling the Oculus Rift.

On (2), I bought an S2 upgrade to see if that would work, and ran into the same problem. It appears to be that you cannot unlock from a patched version, as when I ran the regular .exe the unlock worked!

On (3), the beeping did eventually go away, although unfortunately I have no idea what triggered it.

Now that I've got it working - wow, worth every penny. I am not a sim racing fan at all, but the Rift integration sells it hard. Kudos.

One suggestion: it would be *great* to make it possible to map the Rift 're-centering' to arbitrary wheel buttons. I don't have a prayer of locating my keyboard and the ALT and F12 keys with the Rift on, and that and escape are really the only buttons needed to stay in the Rift indefinitely.

Quote from slakmehl :

One suggestion: it would be *great* to make it possible to map the Rift 're-centering' to arbitrary wheel buttons. I don't have a prayer of locating my keyboard and the ALT and F12 keys with the Rift on, and that and escape are really the only buttons needed to stay in the Rift indefinitely.

It´s possible. I did it too and it´s very useful. See this thread from the Oculus forum:

Quote from scawen :

Hi RiftXdev, thanks for the feedback. It's really easy to bind any ALT+ key to a wheel button. In the Controls Options screen there is an ALT+ tab so you can assign any of those keys (or any text command you enter) to a wheel button.

Quote from slakmehl :

On (1), I still have the same problem with the menu not displaying, but the Alt+F11 shortcut does still work for enabling/disabling the Oculus Rift.

Thanks for sticking with it and I'm pleased you got the test patch to work in the end. The disappearing menu sounds strange - I have not seen that. When you select the Oculus Rift option and the menu pops up for a very short time, are any error messages added to the chat log at the top left of the screen? You can press H to show the recent message history. And what screen does it go to after the menu disappears? Are you left in 2D mode?

Quote from slakmehl :

On (2), I bought an S2 upgrade to see if that would work, and ran into the same problem. It appears to be that you cannot unlock from a patched version, as when I ran the regular .exe the unlock worked!

Thanks, I see that I forgot something on the master server when I put the E9 patch up in a bit of a hurry. Unlocking does work with E9 now (and already did with the other test patches).

Quote from slakmehl :

One suggestion: it would be *great* to make it possible to map the Rift 're-centering' to arbitrary wheel buttons. I don't have a prayer of locating my keyboard and the ALT and F12 keys with the Rift on, and that and escape are really the only buttons needed to stay in the Rift indefinitely.

As just2fast said, this is easy when you know how, in the controls screen under the ALT+ tab. It's one of those things that isn't really obvious and I'm not sure how to make it easier to find. At least I could try to make it clearer in the test patch release notes.

Quote from Scawen :

When you select the Oculus Rift option and the menu pops up for a very short time, are any error messages added to the chat log at the top left of the screen? You can press H to show the recent message history. And what screen does it go to after the menu disappears? Are you left in 2D mode?.

Unfortunately, since using the keyboard shortcut everything seems to work, so I can't replicate. I can confirm that it did go into 3D SBS mode when 3D was selected, it just wasn't possible to bring up the menu that allowed selection of the Rift. I'm 90% sure there were no error messages, but not completely confident.

Today I'll look into the default FOV value. I'm trying to make the Rift support work well when you first try it out.

I'm also interested in your opinions on good default settings for the HUD distance and HUD scale (which will appear as HUD width in the next version). I set the default value of HUD distance to 50cm so that most of the HUD is not behind any part of the 3D world. HUD scale was 0.6 which looked OK at 90 degrees FOV but I'm wondering if 0.6 is a bit too small when your FOV is near 110.

Scawen, now that you make finetuning for the Rift experience, to you see a chance to implement my proposal for navigating in the menu?

Maybe instead of moving the mouse pointer with the rift it might be even better to render a very little crosshair in the middle of the view as soon the HUD is shown. The mouse cursor instead is by default invisible and only shown when somebody moves the mouse. so naigating with the rift or with mouse is both possible and independend.

From my simple programming know how I could can even imagine this is not that much work to do:

Render a tiny crosshair in HUD distance but always parallel to view (Like atttached to Rift). Then when the assigned (wheel) button is pressed, shoot ray into scene from view and calculate where it hits the virtual monitor. On the hitpoint just emulated a mouseclick with the algorithms so far...

What do u think?

Your suggestion is on my notes. I understand that it can be difficult to always have the mouse nearby and that is worse when you can't see it. I agree it doesn't sound too hard to have head point and assignable mouse click to wheel button but I never know what might come up when I try to use an existing system in a new way. It is at lower priority than the neck model, for example, and probably the 3D mirrors.

What do you think about the default value for HUD distance and HUD scale?

I have now been implementing the calculation for the vertical FOV and apparently the answer is 115 degrees with the E8 view (and it would be about 99 degrees for the E9 view). This is using the EyeToScreenDistance of 41mm that is said to be the value returned by the SDK for Dev Kit 1 (regardless of the true eye distance).

Quote from Scawen :

Today I'll look into the default FOV value. I'm trying to make the Rift support work well when you first try it out.

I'm also interested in your opinions on good default settings for the HUD distance and HUD scale (which will appear as HUD width in the next version). I set the default value of HUD distance to 50cm so that most of the HUD is not behind any part of the 3D world. HUD scale was 0.6 which looked OK at 90 degrees FOV but I'm wondering if 0.6 is a bit too small when your FOV is near 110.

Another thing which would be really useful is the ability to distinguish between the menus and the HUD (i.e. the stuff you see whilst racing like the minimap and your position), as good settings for one aren't necessarily good for the other.

Ideally it should be possible to set x,y,z coordinates and size for the menu and for each HUD element independently, the aim being to be able to position each element in such a way that it doesn't clash with parts of your car. In the open-wheelers this is not such a problem but in enclosed cars the minimap etc tend to clash with the ceiling or window struts. (By clashing I mean being drawn overlapping a part of your car but with a stereoscopic depth which suggests the HUD element is further away than the part it occludes, thereby giving the impression that the car must be partially transparent or insubstantial and making the simulated world less convincing).

Cheers,
DD

Quote from Scawen :

Your suggestion is on my notes. I understand that it can be difficult to always have the mouse nearby and that is worse when you can't see it. I agree it doesn't sound too hard to have head point and assignable mouse click to wheel button but I never know what might come up when I try to use an existing system in a new way. It is at lower priority than the neck model, for example, and probably the 3D mirrors.

So there´s still hope for this

Quote from Scawen :

What do you think about the default value for HUD distance and HUD scale?

I prefer the HUD with the current Rifts resolution to be as big as possible. So with the E8Patch I would go for a scale of 0.80 and a distance of 0.50

Quote from Scawen :

I have now been implementing the calculation for the vertical FOV and apparently the answer is 115 degrees with the E8 view (and it would be about 99 degrees for the E9 view). This is using the EyeToScreenDistance of 41mm that is said to be the value returned by the SDK for Dev Kit 1 (regardless of the true eye distance).

Yeah, that sounds better than before...