Oculus Rift Support

@rickard said: I've started with the 0.4 implementation, but so far haven't been able to run it. For some reason I'm having some troubles detecting my DK1. The new API will also require some architectural changes, at least in the long run, as the endFrame call now requires both eyeTextures.

Edit: rebooted and now it’s detected

Great – glad you are getting started on 0.4 (0.4.1.1 JOVR?). Architectural changes are fine & expected, hopefully we can just keep things as easy as possible for the end-user. I suggest putting the eyeTextures static somewhere, maybe OculusRiftUtil, so they can be easily accessed. Anyway, looking forward to what you come up with! Can’t wait for the Linux SDK release.

Progress, but still some issues.

I’ve had to do a couple of things to get here:
Disable swap buffers in application context to avoid flickering.
Remove the setViewPort calls in OVRAppState to avoid one of them being rendered on top of the SDK distortion (although this feels more like a work around, than a fix).

Issues:
The viewports are slightly too small (with or without the setViewPort calls). This results in the right one seeming cut off. Higher resolution means more cut off.
There is a significant disturbing effect when moving the HMD. I can’t explain it well, but it’s almost as if the resolution is low and the pixel swapping is very pronounced. When moving it slowly, though, or just being still and watching the cubes move, it’s not a problem. I don’t know if this is the ‘juddering’ jherico is referring to.
Some orientation issues, but these are minor in comparison.

Edit:
The OvrSizes coming out of prepareCameraResolution when running in 1280x800 are:
int w@0=462
int h@4=611
Sounds low. @phr00t. Can you verify if this is the same as in 0.3.x?

@rickard said: Progress, but still some issues.

I’ve had to do a couple of things to get here:
Disable swap buffers in application context to avoid flickering.
Remove the setViewPort calls in OVRAppState to avoid one of them being rendered on top of the SDK distortion (although this feels more like a work around, than a fix).

Issues:
The viewports are slightly too small (with or without the setViewPort calls). This results in the right one seeming cut off. Higher resolution means more cut off.
There is a significant disturbing effect when moving the HMD. I can’t explain it well, but it’s almost as if the resolution is low and the pixel swapping is very pronounced. When moving it slowly, though, or just being still and watching the cubes move, it’s not a problem. I don’t know if this is the ‘juddering’ jherico is referring to.
Some orientation issues, but these are minor in comparison.

Edit:
The OvrSizes coming out of prepareCameraResolution when running in 1280x800 are:
int w@0=462
int h@4=611
Sounds low. @phr00t. Can you verify if this is the same as in 0.3.x?

For some reason, I get this:

[java]
OvrSizei$ByValue(auto-allocated@0x7fe364948550 (8 bytes)) {
int w@0=461
int h@4=611
}[/java]

… for any resolution I set. Still looks clear, though…

I’ll let you know if I come up with any ideas to help… I don’t have much time on my Windows machine to help debug, unfortunately. Keep up the work in the meantime, though, and I’ll join ASAP.

I tried changing back to the ‘old’ way of initializing (initFilter), and I don’t get the view port cut off, altough the warning and other things are way off. I’ll continue looking at how we set things up.
Forcing the size doesn’t seem to do any difference.
I won’t check any of this in until it’s working properly, so there’s not much you can do (except come with suggestions on what to try :slight_smile: )

@rickard said: I tried changing back to the 'old' way of initializing (initFilter), and I don't get the view port cut off, altough the warning and other things are way off. I'll continue looking at how we set things up. Forcing the size doesn't seem to do any difference. I won't check any of this in until it's working properly, so there's not much you can do (except come with suggestions on what to try :) )

The “old” way doesn’t change the camera resolutions until after the filter gets initialized (e.g. defaultPass) and then calls initFilter. Do you see pixelation returning at the center again? Mind taking a screenshot of how everything looks off? I’m guessing the warning is expecting the filter to be initialized at whatever getFovTextureSize returns, which is why it is probably being put in a bad position.

@phr00t said: The "old" way doesn't change the camera resolutions until after the filter gets initialized (e.g. defaultPass) and then calls initFilter. Do you see pixelation returning at the center again?

Yeah, it’s still pixelated.

Observation:
The warning sign should probably be centered on the screen. It’s currently offset to the right, implying right part of the texture is cut off.
The left view port in the image takes up half the screen. So the view port dimensions seem ok.

This feels like the scene texture being sent to the SDK is too small, so when the distortion is rendered it doesn’t quite fit. Hmm

@rickard said: Observation: The warning sign should probably be centered on the screen. It's currently offset to the right, implying right part of the texture is cut off. The left view port in the image takes up half the screen. So the view port dimensions seem ok.

This feels like the scene texture being sent to the SDK is too small, so when the distortion is rendered it doesn’t quite fit. Hmm

The warning sign in this image:

http://i.imgur.com/by6pppa.png

… seems to be positioned correctly. When viewed through the Rift, it should seem centered. If the warning was in the center of each viewport, it would seem infinitely far away, when it is meant to be shown up close. If we could just solve that cutoff on the right in this screenshot, we’d be all set (excluding the other bugs you mention, like orientation or “pixel swapping”).

You are correct.

This is what it looks like if i comment out cam.resize:

No cut off regardless of resolution

I was thinking, perhaps the cutoff is due to the assymetric field of view. The default FOV angles for right and left frustum limits are different. Perhaps you’re applying the same FOV to both cameras. They have to be calculated for each one.

Just wanted to help, sorry if I don’t.

2 Likes
@yombo said: I was thinking, perhaps the cutoff is due to the assymetric field of view. The default FOV angles for right and left frustum limits are different. Perhaps you're applying the same FOV to both cameras. They have to be calculated for each one.

Just wanted to help, sorry if I don’t.

Thanks for the tip, but it looks alright. One calculation is done for each eye.

@rickard said: Thanks for the tip, but it looks alright. One calculation is done for each eye.
Ok! :)

Couple of ideas… not sure if any will help…

Try resizing the cameras after the filter is initialized?
Resize the cameras, but don’t reshape the filter?

Maybe the eyeTexture is too small, so it can’t fit the full image, so it is getting cut off? Maybe try manually adjusting the OvrSizei result that gets passed to the eyeTexture (with and without playing with the camera sizes).

@rickard said: You are correct.

This is what it looks like if i comment out cam.resize:

No cut off regardless of resolution

Also… I can’t tell if there is any pixelation in this image, since there isn’t much detail at the center of it. Is it still happening here? If not, maybe we don’t need the camera resizing (which wouldn’t make sense, but we can try for science).

I have sort of “fixed” it.

Forcing the size in prepareCameraResolution to 1280x800 before resizing the camera makes it ok. Again, it’s more of a work around, but at least we know where the issue seems to lie.
And btw, doing a print on the OvrSize doesn’t return its current values, but the the native object’s. That freaked me out a bit before realizing it.

@rickard said: I have sort of "fixed" it.

Forcing the size in prepareCameraResolution to 1280x800 before resizing the camera makes it ok. Again, it’s more of a work around, but at least we know where the issue seems to lie.
And btw, doing a print on the OvrSize doesn’t return its current values, but the the native object’s. That freaked me out a bit before realizing it.

Is the warning centered & is there still pixelation? Setting the camera to 1280x800 is the same resolution the cameras should start with, since it is the resolution of the Rift’s display (or window?), so I wouldn’t expect resizing them to the same size to do anything…? :S

It’s fine as long as I set the width to >= the width of the application. I’ve tried a bunch of different widths and heights, and it looks great regardless of resulting aspect ratio.

1 Like
@rickard said: It's fine as long as I set the width to >= the width of the application. I've tried a bunch of different widths and heights, and it looks great regardless of resulting aspect ratio.

So no pixelation & the warning is centered? How does it look in the Rift?

Are we no longer then resizing the camera to what the fovTextureSize is returning?

The current work around is:
[java]if(size.w < app.getContext().getSettings().getWidth()){
size.w = app.getContext().getSettings().getWidth();
}[/java]

Since it’s normally 1122, it’s not a big change as long as the resolution is 1280. Cameras are still being resized. Any dimension is fine as long as it’s more than the current width and height of the application.

No pixelation what i can see, and the warning is centered.

I think we need to get to the bottom of the issue in the future, but at least I can move forward now. No more time today though.

Edit: updated correct texture width

1 Like
@rickard said: The current work around is: [java]if(size.w < app.getContext().getSettings().getWidth()){ size.w = app.getContext().getSettings().getWidth(); }[/java]

Since it’s normally 1122, it’s not a big change as long as the resolution is 1280. Cameras are still being resized. Any dimension is fine as long as it’s more than the current width and height of the application.

No pixelation what i can see, and the warning is centered.

I think we need to get to the bottom of the issue in the future, but at least I can move forward now. No more time today though.

Edit: updated correct texture width

Interesting, ha! OK, so cameras being resized the “current” way, not the “old” way, right? Maybe we should put in a check for height (e.g. size.h) too, just in case?

Do things look “as expected” in the Rift (if you’ve tested it there yet)?