Skip to main content
Up and Coming
November 28, 2013

Idea - How to get fast head tracking with any frame rate

Here's an idea of how to get low latency head tracking with almost any variable frame rate.

Render the scene from the player's point of view with no distortion, but to a larger render target with a wider FOV. The increased FOV should be large enough to take into account how fast a user might turn their head in one frame (I figure ~8 degrees?);



Then at a faster update rate (60 or 120 times a second?) sample how much the HMD orientation has changed since the last full render and calculate how far you'd need to pan and rotate the image.



You can then sample from the render in the highlighted frame and run the distortion effect on this and send this to the Oculus's screen. This would would eliminate any variability in the update rate of the head tracking for the user and would not require games to run at a stable 60 fps to have a smooth experience. Note: The player's movement and the simulation of the world would still update at the normal frame rate.

Ideally this whole process could run in hardware on the Oculus Rift itself. Doing so would require the hardware be able to apply the distortion and to accept a render target larger than the screen itself, which would need to be aware of the orientation it was rendered to.

Alternatively, doing this on the GPU is quite tricky. Running parallel updates alongside the normal scene render is not possible in any GPUs that I'm aware of, it would require a separate render pipeline. One other application of this would be to simply apply this technique at the distortion step of the current frame. This would reduce the amount of latency in the update by a little less than 1 frame (~ 16ms-30ms).

Is my thinking correct here? Any see any reasons why this couldn't work?

    22 replies

    Up and Coming
    December 2, 2013
    I had one thought about selective motion blur when I think of compensating cassadic masking breaking effect of the strobing displays. The idea is to build a motion map for every pixel and subtract from it reading of cassadic sensor (eye tracker), so that instead of screen-relative motion map we're getting eye-relative motion map. Then we're blurring the picture regarding this map, so that the objects that are still against the eye are not blurred, and objects that are moving against the eye get blurried out, thus acheiving natural motion blur without having to use >9000 fps physical framerate. But this requires more or less reliable eye tracker, or at least basic cassadic sensor. The pro for it is that it's a general motion blur, you don't need to implement any other kind of motion blur, and you don't need to worry that some players will think it's not a good thing to have it, switching it off thus [sort of] wasting your development time - it's a good blur by definition.

    In another thread where I suggested some methods of acheiving >240 framerate with current hardware through tweening, I suggested using a displacement vector map, which is supposed to be used internally by the Rift to perform morphing to display new frames in between actual GPU updates. This method is extrapolation of what you're suggesting here, basically, and it should work to resolve low framerate as well (but in higher rates it's yielding better picture, obviously). But this tunnel is very vibrant example where this doesn't work: when the picture changes significantly, as in new objects appear (not only actual objects but even wall textures from behind the corner) - this can't be acheived through tweening in no possible way. This is why it's important to keep actual framerate as high as possible, because even slightest lack of framerate easily generates lots of visual artifacts. Well maybe unless your game is really slow paced, something like sunday walk paced.
    Up and Coming
    December 2, 2013
    "raidho36" wrote:
    ... But this tunnel is very vibrant example where this doesn't work: when the picture changes significantly, as in new objects appear (not only actual objects but even wall textures from behind the corner) - this can't be acheived through tweening in no possible way. This is why it's important to keep actual framerate as high as possible, because even slightest lack of framerate easily generates lots of visual artifacts. Well maybe unless your game is really slow paced, something like sunday walk paced.

    The tunnel video contains some details that only last for a single frame. You cannot blur them by detecting motion between multiple time-sequential instances of that single-frame object. However, knowing that your viewer changes relative to content are relatively monotonic (change in a continuously smooth manner, except perhaps during collisions) you could blur such single-frame objects using know motion of the player and the general environment. Even then, the purpose of blur is to reduce the annoyance of flickering of aliased objects (single-frame, or periodically encountered similar objects that appear to be the same object, perhaps moving in the wrong direction due to temporal aliasing).

    And when I started the PTZ Tweening thread, I was considering that it would be best to do the tweening on the display side of any video bandwidth limitations such as HDMI. You want to do that as close to the pixels as possible, so you can update the display as fast as its technology allows (quite fast for OLED, for example).

    If multiple people are having similar thoughts on this matter, it just means the time has come for that idea to be realized.
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.