Probably dense question: is it supposed to say things like "Resaved texture <name> - No mipmaps" in the corner (where chat et al et al goes)? I'm not using a Rift.

Quote from pasibrzuch :

What's wrong in that pic? I can't see any glitches there.

Nothing actually wrong but it looks a bit odd. In the old version, names over cars 3D text was aligned with your screen. Now, aligned with vertical, it looks a bit unexpected in that image.

I'm thinking now it might be better to use "car vertical axis" instead of "world vertical". But this would mean the names would lean with the cars, even if you are watching from TV cameras...

Quote from duke_toaster :

Probably dense question: is it supposed to say things like "Resaved texture <name> - No mipmaps" in the corner (where chat et al et al goes)? I'm not using a Rift.

That is the new texture resaving system which makes them load as fast as possible next time.

Quote from Scawen :

I guess you have already turned up User LOD and Mirror LOD to maximum? (Graphics Options)

Then there is dynamic LOD reduction which you can turn down to the minimum. (Misc Options)

That should sort out the draw distances for cars. There is still some slight scenery popup due to issues with the path position based "optimiser" system which maintains a list of supposedly visible objects. You could verify this is the case by comparing it with what you see on an Open config (X or Y) because there is no optimiser used on those tracks. But lower frame rate. I am in the middle of a new optimiser system which works out which objects are visible in a more accurate way.

Thanks, didn't realise there was a dynamic LOD reduction I'll give it a go.

Quote from Scawen :

Nothing actually wrong but it looks a bit odd. In the old version, names over cars 3D text was aligned with your screen. Now, aligned with vertical, it looks a bit unexpected in that image.

I'm thinking now it might be better to use "car vertical axis" instead of "world vertical". But this would mean the names would lean with the cars, even if you are watching from TV cameras...

Thinking aloud: Would it be possible to have them with the car vertical axis on car based views, and with the world in TV camera and Shift+U?

Quote :

That is the new texture resaving system which makes them load as fast as possible next time.

That figures - I was just confused about if it was supposed to announce that it's resaving the textures or not. That it is supposed to announce that it is is not a problem.

Quote from Scawen :

I won't write my whole list of things to do. But my general plan is to simply finish to an acceptable standard, that is just like now but with a few issues fixed and the H&S warning added.

This is to get a decent DK2 full version on our site so new people can use DK2 without installing a test patch, and to get LFS into the DK2 section on Oculus Share.

Other improvements will come later. I have a whole list of them that I'm not doing for version G.


- Direct mode is on the list for further consideration when the SDK matures. The Oculus SDK is full of bugs and issues at the moment. I won't use myself and LFS as guinea pigs any more than I have to already.

- Supersampling is worth considering. The thing to do is to render to a buffer of 4 times greater area than we currently do. LFS uses multisampling AA to the render target. The current pre-distortion render target is the DK2 recommended size of 2364x1461. I'm not quite brave enough yet to render to a 4278x2922 render texture, distort that to a 3840x2160 render texture and finally supersample onto the 1920x1080 backbuffer.

- Brightness, you can't increase the max brightness, because it's already doing all it can with short time pixel illumination. However you may be able to boost up the lower levels (with some saturation) in a simple edit of data\shaders\Rift.psh

- Mouseless navigation and a virtual keyboard are on my list, but not for this weekend's planned first full version.

Fair enough. Thanks for the answers Scawen.

Quote from duke_toaster :

Thinking aloud: Would it be possible to have them with the car vertical axis on car based views, and with the world in TV camera and Shift+U?

Could be... good thoughts...

Thinking further I think I could use, for that "vertical" reference, the up axis of whatever is your frame of reference before applying the additional rotation from the rift. So it would be as you say when you are in a driving view. In SHIFT+U mode it's as if you are in a sort of carriage (with position and orientation) that you control with the mouse, and with a Rift you can look in any direction relative to that carriage. In helicopter mode that 'up' axis would be forward relative to a car you are following. I think this makes sense, solves all in one go. Will try it.

Quote from duke_toaster :

That figures - I was just confused about if it was supposed to announce that it's resaving the textures or not. That it is supposed to announce that it is is not a problem.

At least for the test patch I thought it would be helpful and informative. Might remove it for the official patch as people who do want to know could just have a look for fresh files in their dds folder.

Thanks for the great DK2 Support!

Quote from Scawen :

Thinking further I think I could use, for that "vertical" reference, the up axis of whatever is your frame of reference before applying the additional rotation from the rift...

This is what I was thinking too!
Just imagine this additional frame in real live is your upper body. And the vertical reference is your backbone of the upper body which can simply interpreted as a vector.

Yeah, seems pretty obvious now!

Ok so I haven't updated since F3, and now I'm on F7. I have an issue. I mean, the car seems more shaky? Maybe too responsive to the road surface? All these years I've been driving, the car bounched less and I don't remember ever changing any settings in the view option. Were there any made by default? If yes, what were they before? I'm not saying I can't get used to it, because in some door to door racing I haven't noticed it, but when I have noone around I see the difference just because there's not much to look at untill the next corner.

You can find your shake settings here

Thanks for the shake settings Dave
For some reasons mine were all set to 0.000 and headtilt to 1.50

Stupid shake settings...

Someone knows if the coming G patch would be compatible with version F?

Looks like it will be compatible,as there are no physics,content or any other changes that might break compatibility.

Scawen, considering Timewarp isn't implemented, what is currently the best way to run LFS? Vsync on or Vsync off with the frame limiter set to 75?

Also, I'm confused by the mipmap settings. What should I set these to to get the highest visual fidelity?

For me the best is with vertical sync on because there is no image tearing. It uses the very good and accurate head position prediction and predicted time to next display refresh provided by the SDK. Without vertical sync I guess you should use unlimited frame rate. Look for the image tearing if you nod your head up and down.

But some people find that vertical sync causes lag. I had a thought about that... if anyone has lag, make sure you don't have some ridiculous override in the drivers like "force triple buffering" or something. We don't want anything causing extra lag.

Mipmap bias is a personal preference. If you move the sliders to the right you will reduce unwanted aliasing effects on patterned textures (e.g. fences / rumble strips, etc) but some people don't like that softening, so they move them to the left to increase "sharpness".

Names over cars

Quote :

Ply Name DA^EŃĺĚL

Quote from Scawen :

For me the best is with vertical sync on because there is no image tearing. It uses the very good and accurate head position prediction and predicted time to next display refresh provided by the SDK. Without vertical sync I guess you should use unlimited frame rate. Look for the image tearing if you nod your head up and down.

But some people find that vertical sync causes lag. I had a thought about that... if anyone has lag, make sure you don't have some ridiculous override in the drivers like "force triple buffering" or something. We don't want anything causing extra lag.

Mipmap bias is a personal preference. If you move the sliders to the right you will reduce unwanted aliasing effects on patterned textures (e.g. fences / rumble strips, etc) but some people don't like that softening, so they move them to the left to increase "sharpness".

Excellent, thanks!

Is Timewarp something you plan on looking into eventually?

It's implemented in the Unity SDK package and the C++ OculusWorldDemo but I honestly don't see much difference when toggling it on and off. On DK1 with the 0.3.2 SDK it was pretty noticeable but I guess that at 75Hz the latency reduction is less dramatic.

Quote from DANIEL-CRO :

Names over cars

Thanks!

Don't worry about delaying me. I'm spending an entire day implementing the really stupid Oculus Rift Health and Safety warning.

It's not like "Display this text in a sensible way and make sure your user acknowledges it".

It's actually, that the warning must be displayed from the moment the headset starts, and LFS may not allow the user to dismiss the warning for 6 seconds (or 15 seconds if they changed user). After this time has elapsed, the user may remove the warning by pressing a key.

As you can imagine, this draconian requirement is designed for a VR demo that just pops up in a wonderful VR world. They haven't thought it through. It's unsuitable for proper software with entry screens and so on. But we have been told that if we try anything different, our software will be rejected by Oculus. So I must make it work in many different screens.

Quote from Scawen :

Oculus Rift Health and Safety warning.

There's been a lot of outcry on their Forums about that crap. Everybody understands the legal bullshit behind it but they've implemented it in the worst possible way.

Quote from Scawen :

I'm spending an entire day implementing the really stupid Oculus Rift Health and Safety warning.

...while you have never spent a second to implement LFS addictiveness warning... :P

But on serious note - it will be translated in other languages too,right? I guess,there will be some work for me too then.

Quote from Scawen :

It's actually, that the warning must be displayed from the moment the headset starts, and LFS may not allow the user to dismiss the warning for 6 seconds (or 15 seconds if they changed user). After this time has elapsed, the user may remove the warning by pressing a key.

Indeed a very annoying and frustrating req from Oculus :ashamed:

But i guess there is no way to get around it, and to keep the positive flow of messages from rift users coming, it's a must to have then :sorry:

Anyway keep it up to implement all the sane and insane reqs, you master it in your super intelligent way

Quote from Eclipsed :

...while you have never spent a second to implement LFS addictiveness warning... :P

LFS addictive ?, nooo it's just the core part of our lives

I wonder how much ground this warning obligation has. Perhaps once I have the chance to try on a Rift and get hit in my UF1 by a furious FZR I might relate to this warning

It would make more sense if Oculus implemented this warning instead of obliging devs to implement their warning. Detecting when a Rift is on someones head and then automatically displaying that warning popup shouldn't be that difficult. A procedure with buttons on the Rift with users confirming they read & saw the warning message could be an option too. It just feels wrong to release it in the wild and expect devs to deal with it.

They do automatically display one if you use "SDK rendered mode".

But as LFS chooses to do its own rendering, we also get control of that message. That is the lesser of two evils because I can make it better than the "SDK rendered" one, though I still have to adhere to their inflexible but vaguely stated rules. They have stated categorically that if we do not stick to their rules we will be rejected by Oculus.

For example, the SDK rendered one contains three errors, as seen in the attached file.

1) The first Headset has a capital letter in the middle of a sentence
2) Another sentence begins with the word "Headset" instead of "The"
3) "Press any key to acknowledge" even while you can't press a key

Also their own one will swing around with your head, rather than remaining in place. So you have to swivel your eyes to read it. This is against their own code of best practice!

By using my own text which can change in real time, I can get round these issues and I can display the warning in a suitable place so the user can continue to navigate the menus. Still, it should be on a piece of paper in the box just like EVERY SINGLE OTHER PRODUCT YOU CAN BUY!

Can you add a little trick to disable it for us ? (like a little option in the .cfg)