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.
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...
That is the new texture resaving system which makes them load as fast as possible next time.
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?
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.
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.
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.
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.
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.
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".
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.
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.
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.
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!