I wonder if some of the latency could be soaked up by a physical adaptation of the display panel. Imagine a display that adjusts position manually/mechanically in relation to the head movement, enough to give the latency time to catch up with the underlying movement. People won't just sit in a chair and spin 360 constantly. If the physical display could shift the angle of view or the pan/scan of viewable pixels perhaps the rendering could happen a bit slower and catch up when the user stops for a second to focus etc.?
You could render a 'latency' buffer past the edges of the panel's physically viewable viewport and then the panel could expose that zone along with head movement while the rendering continues to work on catching up with the actual shift. When the head comes to a stop for even a handful of milliseconds the display can recenter while the scene is rendered to "time current" position.
Hmm on second thought you could also just render the "overscan" and have the IMU work with the display to shift the pixels into view while the processor works to keep the overscan updated. On pause you can re-render everything (overscan included) and start all over again on the next movement.
Eye tracking would allow even more latitude. The eye picks up very little detail outside of the central area of focus. It is also very good at inventing information to fill in any gaps - for example during the periods when the eyeball shifts position we are essentially blind but the brain fools us that we see a continuous image.
In Peter Watts' scifi novel "Blindsight" there is a description of aliens which could program their bodies on the fly to move only during the saccades of one human observer in order to hide themselves.
Michael Abrash's wikipedia page, which predates the blog post, says:
“He frequently begins a technical discussion with an anecdote that draws parallels between a real-life experience he has had, and the article's subject matter. His prose encourages readers to think outside the box and to approach solving technical problems in an innovative way.”
The section about "racing the beam" is interesting.
> But that means that rather than doing rendering work once every 16.6 ms, you have to do it once per block. Suppose the screen is split into 16 blocks; then one block has to be rendered per millisecond. While the same number of pixels still need to be rendered overall, some data structure – possibly the whole scene database, or maybe just a display list, if results are good enough without stepping the internal simulation to the time of each block – still has to be traversed once per block to determine what to draw.
You could do a pretty simple hack though, that might be good enough: Render the frame onto a buffer, as usual, but instead of displaying it, re-render it using beam-racing with the proper rotation around the viewer to counter the latency of the rendering and transfer time.
This would be a bit like how Google Streetview interpolates the panoramas when you move, but very much simplified, since you only correct for rotation.
Not necessarily. VR is, of course, free of visual misalignment, but there are other sensors whose readout may conflict with the rendered scene. Proprioception, balance, Helmholtz's efferent copies: unfortunately we're pretty good at integrating percepts and detecting state inconsistencies.