Oculus Utilities for Unity 0.1.0 Beta released

"vrdaveb" wrote:
What MSAA level are you using with the legacy integration? It is set to 8x in the repro project.

The projects are exactly same other than swapping in OVR integrations and I did clean removal by removing all of OVR + Plugins dirs, then replace with new OVR + Plugins. Same exact quality settings. 8x.

I just tried with MSAA off on both. With legacy, it doesn't seem to make any difference. I can't crank the CPU delay up past 9ms. With new native integration, I can add an additional .5 ms of delay (to 6.5ms), but it still exhibits the same issue at that point. Still a 2.5ms difference and I really need anti-aliasing in my project or it looks terrible.

I also tried 2 driver versions: 350.12 that you guys recommend, and latest 353.30. That didn't seem to make any difference either.

In case you are wondering about my machine specs I have 2 dev machines:
desktop: i5-4570 @ 3.2Ghz, GTX760, 16GB
laptop (if you can call it that): i7-4710HQ @ 3.5Ghz, GTX980M (no optimus), 24GB

laptop generally runs VR apps about 20% faster than my desktop, and I tested this issue on both machines, and with both DK1 and DK2. It seems like others are noticing performance loss as well, so I don't think it is specific to my setup.

I appreciate you guys looking into this! And I do really like the direction you are heading with native VR setup in Unity.

Thanks
ccs

I was optimizing last night and a lot of my frames were ending up in physics, I found this thread https://www.reddit.com/r/oculus/comment ... mestep_to/

and modified my default timestep to 0.00666667 this made a dramatic improvement in my projects performance, its almost equal to pre-5.1 unity integration performance. YMMV

That is definitely a good tip if your application uses physics heavily. I had already done that for the app I originally posted about because it is physics intensive. The sample app I uploaded showing same degradation in CPU performance has almost no physics in it at all (just character controller + flat plane to walk on), but I will make the adjustment there as well (default is 0.02ms - 50fps) just to see if it fixes the ping-pong effect.

Hi. Does this package allow access to the separate eye RenderTextures?
The OVRCameraRig contains left and right eye cameras though it seems all rendering is done using only a single camera. Is there some sort of workaround?
thanks in advance

No, you can't access the eye buffer textures directly at the moment.

Took me a while to get a point where I could update to Runtime 0.6.0.1 in order to try this out, using Unity 5.1.2f1.

My initial impression is that I'm very impressed! Pressing play in Unity found my DK2 with zero hassle, in Direct Mode. Can see mono version with headtracking in the editor, and the scene is butter smooth in the DK2. Running from built executable is also flawless. So far so good, will see if I run into problems like what ccs reported once I test this on bigger projects.

The Runtime itself seems to have great backward compatibility with demos built with 0.4.3, 0.4.4, and 0.5.0.1. Seems like they performed even better, actually.

Lastly, I would like to chime in and cast my vote for getting the ability to access the individual left/right cameras, even if it means losing out on some potential optimizations:

1) Ability to configure separate culling masks for the individual eye cameras (I've got TWO apps on the Oculus Store that rely on this!)
2) Ability to use OnPreRender() for the individual eye cameras, OR the ability to configure a mix of monoscopic and stereoscopic layers.

I think I'm able to do the above (?) if I continue using the legacy integration, but I don't know how long that will be supported given how potentially awesome the first-party support is. :)

Setting up per-eye parameters is a popular request, and I'll make sure to share this feedback with the team.

Hi,

Wondering how/where to best report bugs with Oculus Utilities Unity 0.1.0 Beta and Unity VR Integration?
Its also unclear where to report a bug which could end up being part of the runtime/sdk, Unity vr integration or just the Oculus Utilities. This is important since the bug i've discovered may be due to any or all of those aspects.


So the problem.
In Unity using VR.RenderScale to change the size of the render ( eye targets?) works fine, but if you increase the size the rendertargets dimension will never decrease again, at least as reported by OVRManager.display.GetEyeRenderDesc().

So worse case scenario here is when you start increasing the renderTargets for the eyes, reducing the scale does change the render area but maybe does not rebuild the renderTarget, maintaining the larger dimension.

Now personally I think thats unlikely, since I feel that it would require more code to make it happen that way. However going by the returned results from OVRManager.display.GetEyeRenderDesc() certainly gives that impression since the renderTarget dimension stays high but the result on screen does deteriorate once you go low.

What might be more likely is that OVRManager.display.GetEyeRenderDesc() is returning bogus information, that it gets stuck with the maximum dimension renderTarget size that had been requested for some reason.

Just to add to the confusion there is definitely a bug with the Oculus Utitlities and UpdateResolutionEyeTexture() in OVRDebugInfo.cs. Here it multiplies the returned value from OVRManager.display.GetEyeRenderDesc() for the eye resolutions by the Unity VR.RenderScale value. Yet its clear that the resolution returned is already being altered by the Oculus SDK/Runtime as its value changes.

Below is an example of what happens as you change the VR.RenderScale in sequence starting at the default value of 1.0.

Renderscale | OVRDebugInfo | GetEyeRenderDesc().resolution | Unity RT Via FrameDebugger
1.0     |     2402 x 1464      |     2402 x 1464       |     2402 x 1464 ( total 2 x eyes)
0.5     |     1201 x 732       |     2402 x 1464       |     2402 x 1464
1.5     |     5404 x 3294      |     3602 x 2196       |     3602 x 2196
2.0     |     9608 x 5854      |     4804 x 2927       |     4804 x 2927
1.5     |     7206 x 4390      |     4804 x 2927       |     4804 x 2927
1.0     |     4804 x 2927      |     4804 x 2927       |     4804 x 2927
0.5     |     2402 x 1463      |     4804 x 2927       |     4804 x 2927

As can be seen OVRDebugInfo reports incorrect values since GetEyeRenderDesc().resolution changes and it multiplies by RenderScale.

GetEyeRenderDesc().resolution looks correct at first but as can be seen will never drop back below whatever max resolution you happen to go to, although its clear on screen that dropping back to say RenderScale of 0.5 that the actual screen resolution is correct. i.e. going back to 0.5 still looks pretty blocky despite GetEyeRenderDesc().resolution claiming its using a high resolution renderTarget.


EDIT:
So I had the brainwave of checking the Unity FrameDebugger and as initially suspected ( though not sure how it happens) the total eye RenderTextures are the same as the values reported by GetEyeRenderDesc().resolution. This probably means the bug is with Unity VR Integration since changing the renderScale never creates a lower resolution renderTexture for each eye than the maximum RenderTexture that has been assigned to the eye at some time.

Whilst I can see that this is unlikely to effect performance ( I assume Unity is simply using a smaller area of the renderTexture, just like we used to do when only POT textures were supported and you wanted a non-POT texture) it does mean a considerable amount of wasted GPU memory if you allow a user to increase the resolution via the RenderScale, since they wont get that memory back if they then scale back down until they restart the application.

I'll log a bug via the Unity Bug Reporter and include this information. I'll post the ticket number back here later.
EDIT: Unity Bug Case Number 715858

However it should be noted that Oculus Utilities OVRDebugInfo .cs UpdateResolutionEyeTexture() is also buggy as it should not be multiplying the resolution by Unity's VR.RenderScale. So that should be fixed too by Oculus.

I'm happy to report the CPU performance issues I was previously experiencing are vastly improved with the latest version of Unity posted today (5.1.2p2). In the test project I posted where I could simulate fake CPU load, I find these results:

5.1.1p3 + 0.1.0 Utils: 6.0ms (number from previous testing)
5.1.1p3 + 0.5.0.1 Legacy Integration: 9.0ms (number from previous testing)
5.1.2p2 + 0.1.0 Utils: 7.9ms
5.1.2p2 + 0.5.0.1 Legacy Integration: 9.0ms

The testing involves cranking up the fake CPU load as high as possible before judder or dropped frames set in, so a higher number is better. This simulates how much CPU time the app actually has for its own processing outside of rendering + overhead. As you can see above, the new version of Unity gets most of the way back to the performance level I was experiencing with legacy integration. This is important for those with high CPU load applications like mine. If you were GPU bound, there may not be a difference or may even be an improvement since the new integration is supposedly more GPU efficient.

Thanks Oculus and Unity for the continued improvement! I won't complain if you make more performance improvements on the CPU side. :)

Also, for those asking about separate eye textures/rendering, support has been added back for this in 5.1.2p2 by allowing you to select which eye a camera renders: both, left, right.

ccs

@anticleric, does Unity 5.1.3p2 fix the level loading crash you encountered?