SDK v0.3.2 Preview 2 Discussion

"vrdaveb" wrote:

What is the (lossy) scale of your OVRCameraController? 0.3.2 now scales tracking data by that, so if most of your scene is at a larger scale than the camera rig, you'll need to scale it up to match.

I'm not sure what you mean by 'lossy scaling' the objects don't have any scaling relative to the world, everything is built to scale.

If I create a brand new project and import the SDK and drop an OVRCameraController into the scene it doesn't seem to have any head/neck translation.

However the OVRPlayerController does, but if I remove the OVRCameraController from it and drop it into the root of the scene it loses the translation.

[Edit]

I'm not sure what happened but I dropped the OVRCameraController onto my character rig and the head translation came back. I thought it must have had something to do with being parented to something.

So I went into one of my other scenes and tried to do the same thing but then I found not even the OVRPlayerController Prefab had any translation now. So I went back to the scene I thought was fixed and sure enough it is no longer working anymore. There is something very odd going on, one thing I did notice that maybe related is that I would lose tracker input and would have to unplug the Rift from the USB and re connect it to get it back. Perhaps its something related to the sensor data?

Something I tried today which got it working again:

- Shut down Unity
- Disconnected the Rift from the USB
- Started Unity and clicked Play
- Connected the Rift to the USB
- Translation returned

I want to repeat that the head tracker was working prior, it just wasn't doing the neck offset translation.

"vrdaveb" wrote:

"excelynx" wrote:
Are there recommended settings for using Deferred and getting the best image quality or are you just recommending we don't use it at all?

Deferred rendering should work by default with 0.3.2. However, if you turn on "Use Camera Texture", there appears to be a bug in Unity's handling of the "Viewport Rect" field that makes it stretch the rendered viewport over the entire RenderTexture. We can probably work around this for the next release.

For now, the best way to use deferred rendering is probably to turn off "Use Camera Texture" and run your app at 1920x1080 to get better resolution on the undistorted image. There are image effect-based antialiasing methods such as FXAA and SMAA that work with deferred rendering. But they can introduce artifacts that are especially noticeable in VR. FXAA is in the Image Effects (Pro Only) package that you can import from Unity's Assets menu. An experimental SMAA implementation is here: https://github.com/Chman/uSMAA

Good info vrdaveb, although I was under the impression it was better to run the apps at 1920x1200, as it keeps the same aspect ratio as native 1280x800 resolution. Also, some Nvidia users seem to have HDMI colorspace issues w/ washed out blacks over hdmi at 1920x1080 (mosty mobile gpu users). Can you verify if it is in fact correct to use 1920x1200 as opposed to 1920x1080, if opting for running at higher resolution?

Edit: Hmm, strange.. when I choose 1920x1200 on one of my desktops it runs at "960x1200 60hz" on the rift. But on the 680m laptops I have, it shows the rift at "1920x1200 60hz". When running 1920x1080 on the desktop everything looks fine actually, but looks terrible and washed out on the laptops. I feel there's an issue that maybe not too many are aware of here.

"sh0v0r" wrote:
Can you verify if it is in fact correct to use 1920x1200 as opposed to 1920x1080, if opting for running at higher resolution?

In 0.3.2 we compute the horizontal and vertical fields of view based on your eye relief, not the render target. As long as the viewport uses all of the available pixels, it should have the right aspect ratio. So both 1920x1080 and 1920x1200 should work. I have seen some warping at resolutions like 1680x1050, which don't use all of the available pixels.

"sh0v0r" wrote:
Also, some Nvidia users seem to have HDMI colorspace issues w/ washed out blacks over hdmi at 1920x1080 (mosty mobile gpu users).

That's odd. 1080p is a very common resolution. Does it sound like this issue? https://forums.geforce.com/default/topic/523992/tip-for-nvidia-users-using-hdmi-and-getting-accurate-color-format/

You might get better results anyway if you run at 1280x800 and check "Use Camera Texture". Does that work for your app?

I have the exact same image quality issue with 0.3.2 SDK: no anti aliasing, no more over sampled resolution. On both PC and Mac, same uggly thing.
I found a workaround though (on Mac I didn't try this on a PC). I launch my demo in 1920x1200 with the occulus unplugged, then I plug back the oculus DVI in once the demo runs, the Mac detects the oculus, switch everything to the oculus resolution but the demo still runs at the oversampled resolution (1920x1200) with nice AA.

"excelynx" wrote:

"contempt" wrote:
Use Camera Texture does produce a much better image, you're right. I assume this isn't the default for performance reasons, but it looks so much better.

Yes camera texture is very power consuming, the framerate drops down dramaticaly when it is turned on.

"vrdaveb" wrote:

"sh0v0r" wrote:
Can you verify if it is in fact correct to use 1920x1200 as opposed to 1920x1080, if opting for running at higher resolution?

In 0.3.2 we compute the horizontal and vertical fields of view based on your eye relief, not the render target. As long as the viewport uses all of the available pixels, it should have the right aspect ratio. So both 1920x1080 and 1920x1200 should work. I have seen some warping at resolutions like 1680x1050, which don't use all of the available pixels.

"sh0v0r" wrote:
Also, some Nvidia users seem to have HDMI colorspace issues w/ washed out blacks over hdmi at 1920x1080 (mosty mobile gpu users).

That's odd. 1080p is a very common resolution. Does it sound like this issue? https://forums.geforce.com/default/topic/523992/tip-for-nvidia-users-using-hdmi-and-getting-accurate-color-format/

You might get better results anyway if you run at 1280x800 and check "Use Camera Texture". Does that work for your app?

I think you misquoted... :D

Yes, thanks sh0v0r! To your question (which was covered in another thread), we fixed the neck model problem you ran into. The workaround for 0.3.2 is to replace your profile with one from the new config util.

I tried 0.32 but there was too many things that it broke in my program to switch to not just switch back to 0.25c until the DK2 is out. Is anyone using the new GUI system yet? I was thinking about revamping some of my gui stuff but I'll wait on that for sure now that I know it's all changing around. I had some problems with the OVRPlayerController prefab too, the lens distortion worked right in the editor, but the left eye was weird and the right eye was right. The left eye was distorted, just not like it was supposed to be, no black border on that side either.

even without the DK2 camera the calibration of the Rift seemed better, less prone to get messed up and have to recalibrate. :mrgreen:

edit: Upgraded Unity from 4.3.4 to 4.5 and tried again. Imported the Unity integration package, deleted the ovr player controller prefab that replaced the old one and dragged the prefab from the ovr assets folder into the project and it worked fine, a lot of the weird issues I was having before went away using Unity 4.5. For some reason I had to check the right eye box on the right camera to get it to work.

Is that lens ditortion mostly for the DK2? I kinda like it on the DK1

"molton" wrote:
Imported the Unity integration package, deleted the ovr player controller prefab that replaced the old one and dragged the prefab from the ovr assets folder into the project and it worked fine, a lot of the weird issues I was having before went away using Unity 4.5.

Glad to hear it's working better with Unity 4.5.

"molton" wrote:
Is that lens ditortion mostly for the DK2? I kinda like it on the DK1

The new lens distortion is absolutely for DK1 too!

We upgraded to Unity 4.5 as well and while testing 0.3.x before with no luck I gave it another try.
Besides all those quirks with flipped and blurry images (vertical FOV is NOT camera Field of View, costs me some time to understand, but even after calibration I could lower down the calculated value -20 to get a much sharper image without any black borders in DK1) I still can't get a dual camera setup to work.
But we need a second pair of cameras to place HUD Elements far away over Cockpit Geometry. 0.2.5 worked fine in that way.

My favourite method would be to parent as many camerapairs as you want under one OVRCameraController and it handles them all. The new OVRCamera Script let's you already choose left or right cam so the first step is taken ;).