The reason for the judder in the OR DK2.

Talk about Head Mounted Displays (HMDs), augmented reality, wearable computing, controller hardware, haptic feedback, motion tracking, and related topics here!
Post Reply
JDuncan
Cross Eyed!
Posts: 130
Joined: Wed Feb 09, 2011 3:30 pm
Location: My Left Hand
Contact:

The reason for the judder in the OR DK2.

Post by JDuncan »

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.
MSat
Golden Eyed Wiseman! (or woman!)
Posts: 1329
Joined: Fri Jun 08, 2012 8:18 pm

Re: The reason for the judder in the OR DK2.

Post by MSat »

From my understanding, the DK2 has gone a long way towards reducing judder. Any remaining judder could probably be attributed to the panel still remaining illuminated longer than what would be ideal.

Here's a good video explaining judder in HMDs http://www.youtube.com/watch?v=HoLHHUdi ... .be&t=6m5s
JDuncan
Cross Eyed!
Posts: 130
Joined: Wed Feb 09, 2011 3:30 pm
Location: My Left Hand
Contact:

Re: The reason for the judder in the OR DK2.

Post by JDuncan »

First off I want to show what happens when you have two parts that need to be correlated before sending a picture, then I will show my three ideas that culminate in the third idea for how head tracking should be done IMHO.

If you have a inverted pixel that beams light onto a mirror that then sends the light to the person looking at the display, you need to move the pixel to send the light onto the mirror, and then you need to move the mirror so the eye sees light from the mirror, the mirror is a plane mirror that sends light in a straight line.

Now it is possible to move both parts at once after you calculated how to move them, but there is twice the calculation time which means you have a greater difference in time between when the person moves their head and when they see the correct picture.

To fix this you bind the pixel and mirror onto a arm and then you move the arm and now you just have to calculate how to move one thing, the arm, that cuts down on the time when the person moves their head and the time the display is ready to show the person a picture from the display.

That was just a hypothetical idea to illustrate how multiple parts needing to be fixed makes the lag larger between when there should be a picture seen as compared to what is actually seen.

Because lag means you get a jerky motion by the picture belonging to one head motion being shown to another head motion.

And that was the background you need to know in order to understand the idea I will post below.

I will just show you the parts in action verbally instead of justifying it because it's less wordy.

You have a grid and you have a marker that moves on the grid, this lets the camera track the moving marker and correlate this to how the head is turning.

Original idea begin
The idea was based on a remote control that acts like a computer keyboard, by pressing one button on the remote control you treat the computer keyboard being emulated like multiple buttons are pressed which lets you control programs that need special key presses to do things.

That there is a keyboard means this is like the grid, and the presses on the keyboard are like the marker moving on the grid. then you just have to register the marker moving on the keyboard and correlate this to a letter in the alphabet.
Original idea end

That is where I got the idea for there being a grid that has a marker moving on it then linking this grid and marker to tracking the head position.

There are three ways this idea can be done I think;

- by beaming a light from the head visor onto a curved wall, then from the top of the person there is a camera that looks at the beam marker on the grid wall and correlates this to head motion.
That is one part, the other is a part that registers there is motion on the head visor, so the program looking at the camera knows the start and stop of the head motion.

- By having the grid on the head, it looks like a big box that has grid lines on the visible sides. And the marker is beaming onto the box on top of the persons head but the marker that beams the light is still, this means the grid moves but the marker is still, the marker is where the camera is above the person facing down.

This would require multiple markers in a area that area patterned on the xy connecting points of a grid.
Then when one marker stops touching the box on top of the head, this means previous to this time there was the two markers touching the grid box and the first marker that disappears correlates to the new marker being on a spot on the grid so the two markers creates a way to virtually constantly know where the first marker is in relation to the position of the head.

This is still a thing on the head that signals head motion so the program tracking the head knows when the head is still.

The difficult part is that looking up and down means the markers on the grid need to touch the grid on the side of the box on top of the persons head and there needs to be a way to show that this grid is from the side of the box on top of the head.

- the third and most easy way is to have a sheet that can let the marker light be seen through the sheet on the other side.
Then the marker is on top of the head, and beams light onto the grid on the sheet, and the camera is outside of the sheet somewhere in front of the person. The sheet is curved and looks like an egg shell that has grid lines all over it that shows where the moving marker light is on the grid.

There is still another art on the headset that shows the head is moving or not, to let the program know what is going on.

Now in the first idea where the camera is above the person, if the person looks up they beam light onto the camera, in the second idea the box on top of the head looks off and having multiple markers is asking a lot of the user, to set up the camera and markers and wear a big box on their head..

But the third idea lets the camera track when the person looks up, like the second idea does, and it lets the marker beam a light onto the grid like the first idea does, so the third idea is like adding ideas 1 and 2 together to get the best of both ideas.

Now in the samsung VR you don't have the fancy gadgets used to track the head like you do in the oculus vr, but yo can sure put the user in a egg like cocoon they have in front of them that lets them do idea three here and then all you need to do is add some part that registers the head starting to move and stopping.

Because the marker on the grid on one thing, added with the part that registers the start and stop of moving, this is keeping head tracking to two parts that are really linked into one part as far as the program using the moving marker and motion sensor is concerned.

The curtain can be simply a cloth and it is held on a aluminum bar and the camera looks at the sheet from a few feet in front of the person. The bar and cloth can cost 20 dollars max because it's fancy, but in reality it's like 4 dollars or something crazy like that.
JDuncan
Cross Eyed!
Posts: 130
Joined: Wed Feb 09, 2011 3:30 pm
Location: My Left Hand
Contact:

Re: The reason for the judder in the OR DK2.

Post by JDuncan »

Hi msat, I read on the oculus forum that not all games have the judder though, so if it was the display like you suggest this wouldn't be happening in only some intense games.
Post Reply

Return to “General VR/AR Discussion”