Skip to main content
mousebear
mousebear
Honored Contributor
January 31, 2019

Oculus Integration for Unity - v1.34 (01/31/19)

Version 1.34 of our integration for Unity has been released.

We highly encourage developers who are using v1.32 of our integration to upgrade to v1.34. Developers using previous Unity 2018.3 versions, we also encourage you to upgrade to Unity 2018.3.3f1 immediately due to compatibility issues.

You can grab the latest version of our Unity Integration here (through the Unity Asset Store): https://assetstore.unity.com/packages/tools/integration/oculus-integration-82022

More information about this release can be found here.

1.34 Update Notes

Unity has released 2018.3.3f1 that resolves the issues encountered in versions 2018.3.1 and 2018.3.2. If you’re using any previous 2018.3 versions, we recommend upgrading to 2018.3.3f1 immediately. If you use 2018.3.3f1 for Oculus development you’ll need to verify that Oculus (Standalone) is installed in the Package Manager.

New Features

  • Updates to OVROverlay that include a GUI redesign and new features. Details about the updates and new features are detailed in VR Compositor Layers & OVROverlay.

    • Added the ability to ‘Override Color Scale’ on an OVROverlay layer, allowing you to change the color offset and scale on layers independent of the global color settings. For any given overlay, global settings will apply unless ‘Override Color Scale’ is selected, in which case the specified overridden color scale will be used.
    • Added the ability to opt out of “Use Default Rects” and define a texture input that contains stereo images in a single texture.
  • Added support for uploading language packs, asset files, and obbs to the CLI. For more information, please see the Custom Items page in the Platform SDK guide.
  • Added UI in OVRManager to setup the target Oculus devices (Android development only).

Integration Changes

  • The Unity Integration 1.34 contains the following changes to the Oculus Integration for Unity package:
    • Update the Oculus Utilities to 1.34
    • Update the Platform SDK to 1.34
    • Update the Audio Spatializer to 1.34

Sample Changes

  • No changes to the SampleFramework included in this release.

Bug Fixes

  • General performance improvements/fixes.
This topic has been closed for replies.

8 replies

cloudcanvas
Inspiring
February 1, 2019
HALLELUJAH to the OVROverlay documentation finally getting updated! Amongst all the other work that went into getting things 2018.3-compliant, of course. Thanks a bunch guys.
Also note that Unity released 2018.3.4f1 today which (officially) fixes a major bug we were running into with the Go.
Samsung Galaxy S8 (Snapdragon 835), Gear VR (2017), Oculus Go (64GB), Unity 2018.3.14f1
sh0v0r
sh0v0r
Up and Coming
February 3, 2019
[edit]
Nevermind, I found the reason was related the Player config settings needing .Net 4.0  
Mentioned in this thread: https://forums.oculusvr.com/developer/discussion/72158/started-a-new-unity-project-met-w-error-cs0234-the-type-or-namespace-name-policy

Hi, guys, I have a brand new project setup in 2018.3.4 and after importing the 1.34 Utilities I get this compile error:

Assets\Oculus\Avatar\Scripts\OvrAvatarSkinnedMeshRenderPBSV2Component.cs(4,23): error CS0234: The type or namespace name 'Policy' does not exist in the namespace 'System.Security' (are you missing an assembly reference?)
morte111
Participant
February 4, 2019
Found a fix/workaround for errors on recent import of Oculus Integration v1.34 on Unity 2018.3.4
In case my post/review doesn't make it to the Unity Asset Store review page which contains a 'does not work for me' from user 'GamerLordMat'
with following Unity console errors after import:
Assets\Oculus\Avatar\Scripts\OvrAvatarSkinnedMeshRenderPBSV2Component.cs(4,23):
 error CS0234: The type or namespace name 'Policy' does not exist in the
 namespace 'System.Security' (are you missing an assembly reference?)

AssetImporter is referencing an asset from the previous import. This 
should not happen.

I got the same error messages (and multiple warnings) in console on first import of Oculus Integration Utilities v1.34, which went away after manually updating player settings to use 'Other Settings->Configuration->Api Compatibility Level' as .NET 4.x, and the forced restart/reimport of Unity after the internal Oculus Integration DLL update to v1.34 which doesn't occur until after doing the build settings/player settings update.
Subsequent standalone build and run of a sample scene like Oculus/Avatar/Samples/Controllers/Controllers works fine with Rift on my windows 7 x64.
Oculus compatibility page
https://developer.oculus.com/documentation/unity/latest/concepts/unity-req/

recommends using Unity 2017.4.17 or 2018.3.3,  which can be restrictive - so frustration from devs is understandable.

So, anyway, thank you Oculus dev team & support team for your continued hard work! 
It is appreciated. :D



MikeSwanson
Up and Coming
February 4, 2019
FWIW, you can also comment-out the using System.Security.Policy statement.
mlewy1
New Participant
February 4, 2019
how does one fix this I have uplaudednew unity and it does not work I get compiler errors. 
mousebear
mousebearAuthor
Honored Contributor
February 4, 2019
Update: the proper package has been uploaded! If you are still running into compile issues, please redownload and reimport the Oculus Integration package from the Unity Asset Store.

Thanks for the heads up everyone, it seems the Unity Asset Store has the incorrect build uploaded (as this compile issue should have been fixed). Stay tuned!
If you need immediate help or want additional support/context on an issue you are having with our platform or integrations: 1. Gather any and all logs , screenshots, and version numbers of relevant software (Oculus SDK, engine, etc.) 2. Please submit a ticket here through the "Contact Us" link (include what you've gathered in step 1). 3. Tag me @mouse_bear once you have done so!
Anonymous
February 25, 2019
Hi

After upgrading to 1.34 we noticed a regression on GearVR/GO when using the Renderheads AVPro plugin.

Using 1.32 SDK we were using Multi-pass rendering rather than single pass because it yielded a higher frame rate of 60FPS rather than 30FPS vis Single Pass.  After upgrading to 1.34 we found that stereo video playback suffers because the left eye flickers, which leaves no alternative other than to drop down to Single Pass and a lower FPS.

I will also post in the AVPro forum in Unity, but if anyone here has any idea what in the upgrade may have caused this then that would be great to hear.

regards

Nalin
georgehitoiris
New Participant
February 25, 2019
I've noticed a regression in the functionality of OVROverlay in the newest update. We use OVROverlay for the loading screens in our application and prior to this update they would work perfectly. But now, if a loading screen lasts for a fairly long time (30 seconds+), my application will freeze up and be unresponsive until I force quit it. The following error appears in the Unity logs, repeated constantly until I force quit the app:

[OVRPlugin][ERROR] Error -1006 in CommitTextureSwapChain() for LayerId 2[OVRPlugin][ERROR] Error -1006 in CommitTextureSwapChain() for LayerId 2[OVRPlugin][ERROR] OVR Error:
  Code: -6001 -- ovrError_TextureSwapChainFull
  Description: There is no room in the texture swapchain to accept more frames.

I used the Oculus debug tool to try and diagnose the error and found that turning off Layer 2 through the interface there made a portion of my compositor loading scene disappear. I recompiled my application with that particular portion turned off in Unity and the error changed:

[OVRPlugin][ERROR] Error -1006 in CommitTextureSwapChain() for LayerId 3[OVRPlugin][ERROR] Error -1006 in CommitTextureSwapChain() for LayerId 3[OVRPlugin][ERROR] OVR Error:
  Code: -6001 -- ovrError_TextureSwapChainFull

What's strange is that turning off Layer 3 doesn't appear to have any effect on my application. I've gotten this far and am not sure how to proceed further - the only solution I can see at the moment is to completely disable OVROverlay-related functionality on long loading screens but that definitely isn't optimal. Does anyone have any insight?
Terms & ConditionsAccessibility statement