Time to stop for the day. I've analysed the tracking matrix and converted into something usable by LFS so the tracking works now.
I don't think it would be fair to say yet. I think the Oculus one is simpler but the Vive one allows more freedom.
I suppose not. I don't really know about all that. I don't think we really talked about things like that in the past. I think that sort of thing becomes important if you get into physically based rendering with High Dynamic Range, which I am interested in but have not studied enough yet.
For now all I really want to do is output the same colours as we normally see on a monitor, instead of the washed out colours I can see in the Vive at the moment. I think it's doing a gamma correction, or perhaps it's *not* doing a gamma correction that monitors normally do. But I'll look into that on Monday.
Quite pleased to have Sunday off now that I can enter VR in the Vive, in LFS and look around as expected.
If you suppose, I can surely say that it isn't implemented.
You guessed right, and I really think PBR and HDR would be a really nice graphical improvement (less than soft shadow mapping and realtime reflections).
I really hope you'll give us more update (and screenshots maybe ? ) about (near ?) future graphical improvements patches after you finished OpenVR implementation (which I'm really interested in, since I may be buying a HTC Vive once consumer version releases).
You said one of the base stations was faulty, that's worth reporting.
That's quite bad then. With two base stations running in a small room, I imagine the noise would be very bothersome.
I'm glad you were able to make it work with LFS so fast.
Let us know how does it compare with DK2. How much better is the resolution? Is screendoor effect still as apparent? How is the FOV? Weight and overal comfort?
I've sold my DK2 two months ago and now I'm trying to decide which one to preorder - Rift CV1 or HTC Vive. So far I'm leaning towards the Rift...
Yes, I'll report the faulty base station (after testing it once more) and comment on the noise of the one that works. Maybe it's only twice the volume of a refrigerator but that depends on which fridge you have! I had to stop using a stupid Whirlpool one that ran nearly the whole time and sometimes sounded like a lorry with a Diesel engine idling in the kitchen. Now I have a nice quiet Bosch. But yes it is too much in a quiet home office like mine.
I'll prepare an email with observations, feedback and a few questions. But first I'll see I can figure out any answers and do some more testing. Main issues are about how to calculate the best possible timing and why SetGamma doesn't seem to do anything.
I don't know what tracking range the consumer Rift will have but it's really noticeable how the Vive is superior on that point. Even with only one base station working, I can get up from my chair and move over to the left and back. At that point I'm standing (as if on a hoverboard) right outside my car looking at it rolling along the road with a headless driver. I know that's pretty pointless but the Rift DK2 camera doesn't allow that freedom. I think the Vive would be fun if you set it up in a living room and you could play table tennis with someone over the internet. The Vive can definitely handle room scale VR better right now. But as Palmer Luckey said, the cable is a problem for standing VR...
I guess the consumer Rift will have better tracking than the DK2 so that point may not be relevant. Also it's not relevant if you only want to use seated simulators. Then you will be more interested in image quality, frame rate and field of view. I'll try to comment on image quality and FOV when I can really see the same LFS in both headsets. On frame rate, both the Rift at 75Hz and the Vive at 90Hz are not really ideal for LFS. Ideal for LFS would be a 100 Hz headset. But that too could be come irrelevant if we move LFS to 1000Hz physics or run the graphics on a separate thread which I would like to do eventually.
This is offtopic but I could imagine when moving a head like a mad man during race, and your racer body could actually be as "living object". Having a freedom to look every angle what realistically could be or even more. I just did imagine how you could go through to side door and see your body in multiplayer replay to be an outside of car, while racing.
Or spinning 360 degrees continuosly makes to be visible a head spins around like a roulette spinner in casino, lol
I made some further improvements today and have sent off an email with some feedback and a few questions.
I managed to sort out the brightness, but this involves a copy of the entire render target onto a texture with an SRGB format, before submitting that to the OpenVR compositor. That extra texture copy is presumably not good for performance. This is also done in the Rift code.
I was able to improve timing and performance by using a very important but not very well documented function in the OpenVR SDK. At least there was some documentation in the header file.
I also reported to Valve a couple of other issues. One, there is a three dimensional cyan debug grid sometimes, or alternatively cyan ring at floor level, or sometimes no debug info.
One other strange thing is as soon as I turn on the Vive, there is no more sound from my PC speakers. The only way to hear sound is to plug in headphones into a headphone jack on the Vive. But maybe there is a hidden option somewhere.
Geraldine and I tried to do a comparison between the Rift and the Vive. We couldn't really see a big difference. Nothing jumped out at us. We were just sitting at the start line at Blackwood looking around. There wasn't a big difference in comfort, resolution or field of view. Both Rift and Vive are a bit heavy and need some more resolution and FOV.
I did plug in the Rift and try to see if it worked in OpenVR but it did not notice the Rift in any way that I could detect. It just returned an error code something like 'headset not found'. The SteamVR software didn't acknowledge the Rift either. So I don't know what's up there. I read on the SteamVR forums that other people had the same problem.
I guess Valve is focusing on getting their own product properly supported first, which is definitely understandable. The idea of a unified VR interface like OpenVR sounds great for developers though, as long as it's equally versatile and somewhat bug free for all the devices.
Yesterday I did most of the finishing of the implementation, such as allowing the user to select Oculus Rift or Open VR, updating the translations and generally cleaning up all the related code which has changed a but to support two different VR systems.
I was busy with other things today but there was one problem remaining - judder and stutter! Just what you don't want in VR. And it was worse in menu screens. In game it was very smooth at times but bad at others. As usual, this was when doing everything the 'correct' way. So I was baffled.
This evening I decided to experiment with a few things to see if I could figure out how to get the timing right (or whatever was going wrong to cause stutter). I read a few threads about judder and stutter on the Steam VR developer forum.
It turns out that the solution is to issue a pContext->Flush() command just after submitting the two eye textures. Now it's perfectly smooth. But I can't tell them that on the thread, because I'm not allowed to post there!
Anyway it's so smooth now I really want to get this released as soon as possible, along with the dynamic car reflections. I expect to release a test patch next week.
All the vertices and pixels are now going through newly written shaders. The public version still uses DX8 style assembly shaders. The new ones are all HLSL. However, it's mostly made just to be the same as the old shaders as a direct replacement.
For this coming patch, only the reflections on cars and buildings look different. They have the Fresnel effect and a sky hemisphere environment map generated with the distortion to put the cloud reflections in exactly the right position. The reflection ray is calculated at each pixel so the reflections look better and don't distort along the lines of polygons.
Anyway, now all the shaders are written by me and in HLSL, it allows the possibility of writing new shaders to allow new types of shadow and of course many other effects in future.
Finally! I hope you made a lot of different kind of shaders, depending on which type of object it is (grass, road, cones, tires, glass, and wall for example), that will be nice to edit or create future detailed materials later.
Did you noticed a performance improvement after converting shaders to HLSL ?
I discussed that very briefly with Victor. It can't work with the existing skin system, as a jpg has only r/g/b channels. I suppose what we need is one more channel? E.g. use the alpha channel to specify how shiny a pixel is. Is that the main thing that is needed? If so, what would be the best texture format for uploading skins? I won't do that for this test patch but it's something to consider.
Yes, I have contacted them. They told me this:
"We do require that developers complete the onboarding process to gain access to our developer forums and the available VR demos, regardless of planning to ship content via Steam or not."
But it is actually not possible for Live for Speed to complete the onboarding process. A US Taxpayer ID is required, and partnerships are specifically excluded from onboarding.
Where did you see that note about posting priviledges? I can't find it, although googling showed that someone else had seen that same text.
Thanks. Interestingly a couple of issues I reported by email have been fixed, although I did not get a reply to my feedback email.
There isn't a different shader for all the materials yet. The reflections system took quite a while so I haven't gone far down the path of new shaders. There are different shaders for matt materials / shiny paint / glass / metal / black glass. But nearly all the world is simply matt materials at the moment. There are complications to consider, such as textures which are a boundary between road and grass. But of course I am interested in working on specular effects and so on for roads and grass in future.
EDIT: About performance, I did get a significant improvement, specially in the shadows code. Partly due to the shaders and partly due to a significant amount of restructuring. Now that everything uses a vertex shader and a pixel shader and the FVF system is not used, quite a lot of restructuring and optimisation could be done. I think most of the latest frame rate improvements are swallowed up by the generation of the dynamic reflections, but that depends on the situation. Also today I am adding an option to set the maximum number of dynamic environment maps. Probably separate options for the main view and the mirrors.
Maybe you don't like the idea but if the vive was a free development sample then a $5 payment to end registration would not be a steal.
Currently there is a lot of independent game that deserve some support.
Absolute drift is relaxing to me. Or maybe you can just add credit to your account, this way you don't loose focus testing something else.
So in my opinion that is not clear. I did ask them about it in my very helpful and polite feedback email recently, but there was no reply from either of the three recipients. It's a little odd how they have fallen silent and ignored both emails I've sent since I explained why their rules prevented me from completing the "onboarding" process which they invited us to do. That has nothing to do with the $5, by the way. Onboarding is the thing which allows you to sell on Steam, and for some reason if not onboarded you are not allowed to talk on the SteamVR developers forum, even if they sent you a Vive.
I'll try adding $5 to my wallet if I want to say something (on the public SteamVR forum). That might seem important when I release the LFS test patch with OpenVR support.
I don't mind considering the use of Steam for sales at some point in the future but we would need to first restructure as a limited company instead of a partnership. Clearly this is not something worth doing just to allow access to a developer forum.