Perfect prediction, Rift improvement idea

Given similar conditions, LEDs lifetime is only defined by use intensity and duration - how much does it change on average is irrelevant. The best thing you can do is to lower blue light intensity - among perception concerns, LEDs much better survive lower intensities than lower flash frequency. But either way, that'll cause the whole picture being yellowish.

OLEDs and LEDs are substantially different technologies with their own wear characteristics. Blue OLED pixels will dim faster than red or green, what I am suggesting is using the sensor to dim the red and green in concert to maintain an accurate colour balance over the life of the panel. My solution assumes this wear may be dependent on duration and intensity of activation, and will naturally differ across the panel depending on content, but settles for measuring the average. Perhaps if Oculus were really keen, they could design a driver board that maintains a running total for each individual pixel and compensates based on that. Maybe this is already a common feature in OLED driver boards. I don't know really, these things are usually super proprietary and I am not a display engineer. I'm just sharing musings here.

"owenwp" wrote:

I think there might be great value in incorporating the latency tester into the final Rift.

They said that it's in the new Dev Kit, which was just announced earlier today.

Apologizes if I am asking this here, but as a new member I cannot start a new thread so this seemed appropriate to me.

I am not sure I got totally this story of latency.

In my machine, the latency as returned by the function GetPredictionDelta() is 0.03

So .. if I get this right .. this means that "I am getting orientation about where something will be in 30 ms time", like to say "in 30 ms your head will be at YPR" ..

Now, if I am rendering 60 Hz with VSYNCH it means I cannot display anything faster than 18 ms and that, if I am slower than that, I will loose 1 frame ending up in displaying at 30 fps, there's nothing in the middle.

So I don't understand it fully .. in those conditions I *think* that I should have a delta of 0.018 OR, assuming that for "other reasons" I cannot have it ( other delays in the middle ? ) I suppose at this point I should get a DELTA of 0.036 and render 2 frames with the same YPR ( Yaw Pitch Roll ) values ?

I mean "I am sampling the movements of my head every 36 ms but I can render every 18 ms".

Is my reasoning correct ?

Also "the 1 million $ question", what can be done to make "at the absolute minimal" that blur one sees when moving the head ?

Thanks in advance for any explanation :)

I think the best prediction would be to add muscle sensors on the neck... or thought reading electrodes on the head! ;)

"GilesGoat" wrote:
I am not sure I got totally this story of latency.

In my machine, the latency as returned by the function GetPredictionDelta() is 0.03

So .. if I get this right .. this means that "I am getting orientation about where something will be in 30 ms time", like to say "in 30 ms your head will be at YPR" ..

Now, if I am rendering 60 Hz with VSYNCH it means I cannot display anything faster than 18 ms and that, if I am slower than that, I will loose 1 frame ending up in displaying at 30 fps, there's nothing in the middle.

So I don't understand it fully .. in those conditions I *think* that I should have a delta of 0.018 OR, assuming that for "other reasons" I cannot have it ( other delays in the middle ? ) I suppose at this point I should get a DELTA of 0.036 and render 2 frames with the same YPR ( Yaw Pitch Roll ) values ?

I mean "I am sampling the movements of my head every 36 ms but I can render every 18 ms".

Is my reasoning correct ?

The motion-to-photon latency is affected by your framerate, but it's not completely determined by your framerate. The latency tester shows that Unity games with Vsync on tend to be around 42-45ms latency, and it's half of that with Vsync off. This is Windows 8 64-bit, and same results whether you duplicate or extend your monitor. If you've got Vsync on and your framerate drops below the refresh rate, I'm sure that the latency will climb proportionally but I never actually tested that. The above may not apply for an engine/library other than Unity, and it also may not apply anymore with the new updates coming via SDK 0.3.1 and beyond, but I'm not sure about that.

"GilesGoat" wrote:
Also "the 1 million $ question", what can be done to make "at the absolute minimal" that blur one sees when moving the head ?

Keep your framerate as high as you can and as stable as you can. If you can lock your game at 60hz with vsync on you're good to go -- as much as is possible for the DK1 that is. In the DK1, the blur is a combination of the relatively low refresh rate of 60hz and the lack of a low-persistence display. DK2 attacks that problem with a two-pronged approach and is really amazing.

If I've misspoke on the explanations above, please correct me!

OK .. kinda clear .. of course there's "other stuff in the middle" like time to compute all that, send the data to the pc, extract information out and such.

However .. you say 42 .. 45 ms latency .. this is not a multiple of 18 ms ( 1 / 60 hz ) .. does it mean I should take the 'max' ( in this case 45 ), round it up to the closes multiple of 18 , in this case 54, get a prediction for 54 ms instead of 45 and then use it to render only every 3 frames ?

Because otherwise - I think correct me if I am wrong - I am always going to render and display a frame of a point in time where my head is not there.

I mean "time 0", my head is "point 0", I render "frame 0"

My head begins to move .. now I know that "at best" I can know and display where my head will be in 45 ms, cannot do faster than this.

But '45' is "somewhere in the middle" actually is really in the middle of the frame between 36 and 54 ( 9 ms after 36 ) so 1/2 of that frame should display what was before and 1/2 of it what is at 45.

I can't do that so "the best I can do" is to force myself to check where you head will be at 54, render it maybe while I am still rendering/displaying 0,18,36, then at '54' finally I can show you where you are because your head will be precisely there.

And of course '54' ms are a bit too slow to be good.

Am I getting this right ?

Otherwise I think part of the problem is you are always going to show a frame where in that moment your head is never exactly there ?

Those delays are not sequential.
So you should render frames at 0,60,120,... ms. And they will be displayed at 0+45,60+45,120+45,... ms