Oculus did pick the right display device for DK2

This issue really bit me as I do a lot of wireless stuff. None of the wireless video products seem to know know what to do with native portrait :(

"kaetemi" wrote:
Yes. This left-right scan is suboptimal.

I wouldn't be so dismissive about that. It could turn out, that this is actually a huge benefit. The time required for a image scanout is known. So assuming that within a single frame the user's head movement doesn't change drastically this information can be used to predict the head positions for the time the image is visible to each eye. The resulting differential will be small, but nonzero except there's no head movement at all. This in turn can be used to give to determine interdependent, time adjusted view transformations for rendering each eye.

If you want to get fancy you could even think about advancing animation / simulation timesteps per eye, effectively doubling the animation / simulation framerate.

Combine this with active VSync timed render-and-swap delays, as discussed in viewtopic.php?f=32&t=7457 and it might turn out, that the horizontal slow-scanout direction is actually beneficial.

I don't have my DK2 yet, but this is something I'm definitely going to experiment with.

"WG1" wrote:

Same here, but do you have to switch Primary Display back and forth between between desktop and DK2 extended?

No.

I have a right-click and open-with context menu to open any .exe into the second adaptor so all demo's go to the DK2 fine for me.

You can either create a short cut to the .exe and go to properties and add into the end of the target line -adaptor 1
(adaptor 0 is my main display) and the demo/game should open onto the extended monitor, the DK2.

"datenwolf" wrote:
This in turn can be used to give to determine interdependent, time adjusted view transformations for rendering each eye.

Your stereo parallax needs to be consistent between left and right eye if you don't want to get dizzy.

"mrcrisp" wrote:

"WG1" wrote:

Same here, but do you have to switch Primary Display back and forth between between desktop and DK2 extended?

No.

I have a right-click and open-with context menu to open any .exe into the second adaptor so all demo's go to the DK2 fine for me.

You can either create a short cut to the .exe and go to properties and add into the end of the target line -adaptor 1
(adaptor 0 is my main display) and the demo/game should open onto the extended monitor, the DK2.

Thank you MrCrisp. Got it sorted out now. Writing this using Virtual Desktop, DK2 is awesome.

"kaetemi" wrote:

"datenwolf" wrote:
This in turn can be used to give to determine interdependent, time adjusted view transformations for rendering each eye.

Your stereo parallax needs to be consistent between left and right eye if you don't want to get dizzy.

Exactly! Here's the point: The left and the right eye are get their photons at slightly different times (namely exactly half a refresh interval apart, about 6.7ms. It would be a different story if a LCD was used, a complete picture drawn with the backlight off, then a very short, bright flash would send the picture to the eyes and the next image was updated to the display.

In essence this means, that for the parallax to be consistent between the eyes we have to take head movement into account that happens in the 6.7ms between the start of scanning out the left and the begin of the right eye scanout. One possible solution is to timewarp once per frame the images for the left and right eye at 6.7ms apart, but then any deviation between the predicted and actual head movement between V-Sync and when the right eye finally gets its picture will add parallax inconsistency.

Thats the reason why so many people report, that turning V-Sync off makes their experience a lot better. Ideally the scene would be rendered as the lines are flashed up, i.e. tearing on a scanline level; effectively this would be the opposite to rolling shutter warping.

Somewhere inbetween is a mix of synced and unsynced-delayed swapping. I've been experimenting with that the past night (insomnia can lead to productivity). To make a long story short, all the syncing APIs lack something important: The ability to buffer swap for arbitarily desired scanout lines, not just the vertical retrace. So if a buffer swap could be queued for scanline 0 (which is the widely known v-sync behavior) and then scanline 960 (i.e. right at the DK2 eye separation), this would make parallax consistency even better for rapid head movements.

"datenwolf" wrote:
Exactly! Here's the point: The left and the right eye are get their photons at slightly different times (namely exactly half a refresh interval apart, about 6.7ms

Yes and no. I don't know the exact specs of the monitor, but you can assume the actual scanout is faster than the frametime. There should be a fair amount of VBlank time. Especially when using low persistence.

The SDK already handles the timewarp separately per eye, as far as I know. So it's not even anything you need to worry about.

The problem is that, even with low persistence, the image is physically on on both eyes simultaneously at some point. (Especially when low persistence is off, I don't know what the line persistence is under low persistence.) This isn't a CRT screen. The technique of separating eyes would work perfectly fine if you can do low persistence on each eye in turn, but that is not the case as far as I know. The fact that light is fully visible on both eyes simultaneously will break the accuracy of this effect, and effectively might make it worse.

The left-right scanout, within one eye, also poses potential issues with the consistency of the parallax, as the brain interpolates visible movement. Look at a classic red led display with simple one-row-at-a-time scanout, and perfectly orthogonally placed leds, and have the text move sideways, the text will appear slightly italic, even though the leds that appear on are perfectly orthogonal. This is because the brain has interpolated to top row further in time by the time the bottom row is visible. When you do the same with a monitor that scans left-to-right, you are getting this effect as well, but now your brain's interpolation is slightly skewing time in the direction that is used to get depth cues, which is in fact an issue.

"datenwolf" wrote:
Thats the reason why so many people report, that turning V-Sync off makes their experience a lot better. Ideally the scene would be rendered as the lines are flashed up, i.e. tearing on a scanline level; effectively this would be the opposite to rolling shutter warping.

VSync off works fine on DK1 if you can live with some random horizontal tear line, but is terrible on DK2 because often your right eye image will randomly lag behind by either full (frametime), or by (frametime - (scanout time / 2)) if you're compensating for the scanout time.

"kaetemi" wrote:

The problem is that, even with low persistence, the image is physically on on both eyes simultaneously at some point.

That would require for the whole display to light up simultanously. But that's not how OLED displays are operating.

Interestingly you could do a "flashing" low persistence easier with LCDs, because those have a single backlight. I.e. scan out image to the display matrix with a dark backlight, and at V-Sync flash up the backlight for a few µs. OLEDs however can light up only one (or two lines) at a time, because active light emittance requires current to flow and you can push only that much current through InTO2 conductors without heating them up too much.

"kaetemi" wrote:
This isn't a CRT screen.

OLED displays have a strikingly similar behavior to CRT screens in the way they emit the picture. The most notable difference is, that OLEDs can be scanned out much faster because there is no "inertia" from the electron beam steering solenoids. Accurately steering the electron beam with a frequency that approaches 1MHz is serious work. That's why you could physically damage CRTs if you fed them a mismatched horizontal synchronization frequency (later generation CRTs would detect harmfull frequencies and display a warning message instead).

Anyway, I just took a quick measurement using my Galaxy S4 Mini which display is very similar to the DK2 display. The measurement was taken by directly connecting a photodiode to a oscilloscope test probe, i.e. I was using it in photovoltaic mode, which has a much slower response slope compared with reverse bias mode, but for a quick qualitative measurement it suffices: Result: The vertical refresh frequency is 240Hz and each line lights up for less than 50µs. if each line lights up only for the time its scanned out it would be 1/(240Hz * 960) = 4.34µs, but to measure that I'd first have to build a small reverse biased photodiode amplifier.

I definitely will do that measurement once my DK2 arrives; I want to get an accurate figure in which way the buffer swap sync timing relates to the display output.

Interesting. If you measure, I'd like to know what difference there is then in single-line persistence between low persistence and non-low persistence mode of the DK2 screen.