The reason for the judder in the OR DK2.
Posted: Mon Sep 22, 2014 1:44 pm
First off I want to say that I don't own a DK2 or and rift or VR headset, I am talking based on my technical opinion only and have nothing to do with the rift in real life, this is hypothetical prose you will read below.
The head is one part = part A, the display the other part = part B.
When part A moves, part B has to first calculate the way the head moved, the secondly display the thing that should be seen there.
When the head moves one way, and the display moves another way, the response seen is there is different movement than what should be there, this is what is called judder.
begin e.g.
Think of it using this analogy, you have two cog wheels with teeth grooving into each other like so;
http://library.creativecow.net/articles ... /pic29.gif
But when the head moves one way and the display moves another way the teeth don't groove to turn the cog wheels, and this is where you get the judder visual error.
end e.g.
The display is fast enough, it's oled and high tech so it has low latency, the video card is fat enough, so no HW issues with the display or PC video output, on the user the head turns so that part works OK, that leaves the third part the SW that processes the head moved the decides what picture to send to the display, and this takes time which makes error that is the cog teeth do not groove together, it's a SW issue.
Having worked on ffdshow setting when I wrote guides over at avsforum under the user name "8:13", I know that sw is not as good as hw when it comes to doing calculations because sw is slower than hw.
I think by having a dedicated chip to calculate the head position relative to the picture needing to be sent to the display that the sw issue will be solved or corrected enough to not be a issue or a big issue.
You can use sw optimizations etc, but nothing is as good as a dedicated chip.
The head is one part = part A, the display the other part = part B.
When part A moves, part B has to first calculate the way the head moved, the secondly display the thing that should be seen there.
When the head moves one way, and the display moves another way, the response seen is there is different movement than what should be there, this is what is called judder.
begin e.g.
Think of it using this analogy, you have two cog wheels with teeth grooving into each other like so;
http://library.creativecow.net/articles ... /pic29.gif
But when the head moves one way and the display moves another way the teeth don't groove to turn the cog wheels, and this is where you get the judder visual error.
end e.g.
The display is fast enough, it's oled and high tech so it has low latency, the video card is fat enough, so no HW issues with the display or PC video output, on the user the head turns so that part works OK, that leaves the third part the SW that processes the head moved the decides what picture to send to the display, and this takes time which makes error that is the cog teeth do not groove together, it's a SW issue.
Having worked on ffdshow setting when I wrote guides over at avsforum under the user name "8:13", I know that sw is not as good as hw when it comes to doing calculations because sw is slower than hw.
I think by having a dedicated chip to calculate the head position relative to the picture needing to be sent to the display that the sw issue will be solved or corrected enough to not be a issue or a big issue.
You can use sw optimizations etc, but nothing is as good as a dedicated chip.