Skip to main content
Inspiring
July 7, 2015

Oculus Utilities for Unity 0.1.0 Beta released

We have released the Oculus Utilities for Unity 0.1.0 beta. This package has basically the same API as our legacy Unity integration, but it's built with Unity's new first-party VR support (UnityEngine.VR). If you've been using Unity 5.1 with the new "Virtual Reality Supported" player setting enabled, you may have noticed the camera model and feature set differ from what was in the old integration. The Utilities enable you to update existing apps and also access Oculus features not exposed by Unity itself. Questions and feedback are welcome here.

You can download the Utilities and an updated copy of the SDKExamples from https://developer.oculus.com/downloads/.

Be sure to read the documentation at https://developer.oculus.com/documentation/game-engines/latest/concepts/unity-intro/.
    This topic has been closed for replies.

    80 replies

    Up and Coming
    July 13, 2015
    "cybereality" wrote:
    @wheatgrinder: Can you try this?

    VRSettings.showDeviceView


    To try to turn mirroring on.


    Thanks Cyberreality, but the problem was between the chair and keyboard.

    I was rebuilding in the same directory in which I had built in prior to upgrade to 5.1. using the same name etc..
    Thus I still had a <project>DirectToRfit.exe file that mostly worked.. and the result was.. well, no monitor view.
    I was about to ask another question about why was my build still making that DirectToRift.exe when I looked at a it a bit longer and realized what I was doing.

    I deleted all the files in my build directory and did a fresh build.. Just one binary and it works fine, including mirroring.

    I do note that the image in the mirror is pretty bad.. double \ghosting image etc.. in the HMD looks great.. is this expected..?


    Thanks for your solution though, I did use the VRSettings.showDeviceView parameter to turn it off and on, which is good.
    Inspiring
    July 13, 2015
    Yes, I'm seeing the motion blur on mirroring as well, and I'm investigating.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    July 14, 2015
    I wanted to followup with a couple of pictures from the profiler showing what I am seeing with Unity 5.1.1p3 + 0.1.0utils + 0.6.0.1 runtime and native VR selected. I have a fairly CPU-bound application that was capping around 100fps previously. Here I am running on my DK1 machine with a target of 60fps, but I get same results on my DK2 machine as well. The application is not able to maintain 60fps/75fps in this case. It appears that every-other frame misses some cutoff and lags a frame. If I run this same exact application using Unity 5.1.1p3 + 0.5.0.1 Unity integration + 0.6.0.1 runtime, I get near 100fps solid (I can disable vsync in older integration to see this) and a much flatter profile.

    I'm showing back-to-back frames here.It seems like there is plenty of buffer in PlayerEndOfFrame/OculusWaitForGPU, but there is no visibility into what is actually going on in OculusWaitForGPU, so I can't tell what is causing this. Any ideas? This is the profiler running on the built application, and not in the editor, as I find that returns better profiling results.

    frame1.PNG

    frame2.PNG
    Inspiring
    July 14, 2015
    @ccs: Can you send me a simple test project that shows the issue so I can reproduce here?
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    July 14, 2015
    "cybereality" wrote:
    @ccs: Can you send me a simple test project that shows the issue so I can reproduce here?


    I tried to mock up something simple with a simple scene and a fake CPU delay script which I could soak up a variable amount of time on the main thread with, but it wouldn't exhibit the same behavior. I can't send you my current project as it is too large and contains protected content. If I can find some time, I'll try to put together a more complex scene that is still small in size but exhibits the issue.
    Inspiring
    July 14, 2015
    OK, yes, I understand.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    July 14, 2015
    Hey Cyber-

    Try this:
    https://www.dropbox.com/s/tysp459fmhd26 ... t.zip?dl=0

    It uses a freely available Star Trek Enterprise model (1/100th scale - kind of fun to look at!) + 3 dynamic lights to add some rendering complexity (problem doesn't occur with blank scene).

    Build for x86_64 and developer build + auto-connect profiler to see the graph similar to the one I posted.

    There is a component called "Delay Test" attached to the OVRPlayerController game object, and it has a delay time set to 7, which simulates 7ms of CPU processing (i.e. a CPU-heavy app). With it set to 7 on my DK2 machine, it creates a similar judder and graph as shown in my earlier post. If you set it lower the problem goes away, and if you set it higher the app goes into 37.5fps lock instead of bouncing between 75fps and 37.5fps. I'm guessing it may vary per CPU/GPU your machine uses, so you may have to play with this value to repeat the effect. Perhaps all this experiment indicates is the new integration just isn't as CPU efficient as the older integration. That is kind of a bummer because there were great promises of speedup with new native approach due to only having to render shadows, etc. once.

    I'll port the above experiment back to 0.5.0.1 integration and see what kind of FPS I can get with vsync off or see how high I can set the delay with vsync on before judder occurs. That should give us a good idea of the performance drop from old integration to new native setup.
    Inspiring
    July 14, 2015
    OK, I will share that project and see if anyone here knows more.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    July 15, 2015
    OK. I made a 0.5.0.1 integration version of the project I posted (same version of Unity: 5.1.1p3 and runtime: 0.6.0.1), and I can crank the CPU delay all the way up to 9ms and it runs stable at 75fps. Beyond that it started to judder and drop frames. With the same project on 0.6.0.1 + these utils, I can only crank the CPU delay up to 6ms before judder and dropped frames set in.

    So I'm losing 3ms of CPU time on the main thread when moving to native Unity VR + utils. That is a pretty huge difference. I think others complaining about performance with the new native Unity implementation + utils are probably running fairly CPU intensive applications.

    I hope you guys can work on making this better. I can't do much with 6ms of allocated CPU time on the main thread, and this will only get worse with 90fps CV1 goal (lose another 2.2ms). Let me know if you want me to post 0.5.0.1 version of this same project, but it should be easy to replicate.

    thanks
    ccs

    p.s. I tried turning queue ahead on but that didn't seem to make any difference. It is off by default.
    vrdavebAuthor
    Inspiring
    July 15, 2015
    What MSAA level are you using with the legacy integration? It is set to 8x in the repro project.