OPENGL NATIVE PLUG-IN ERROR: GL_INVALID_VALUE: Numeric argument out of range

[vinhui]

My device (pixel) keeps throwing this error on unity 5.6.0b10 (and 5.6.0b9) with sdk 1.30 (and 1.20)

[vinhui]

Does it maybe have something to do with the following?

03-08 12:57:27.154 10948 10948 E Unity   : Google VR Error [Daydream]: Exception caught while loading GoogleVR. Attempt to invoke virtual method 'java.lang.Object com.unity3d.player.l.a(java.lang.String, java.lang.Object[])' on a null object reference
03-08 12:57:27.156 10948 10965 E Unity   : Google VR Error [Daydream]: Google VR had a fatal issue while loading. VR will not be available.
03-08 12:57:27.156 10948 10965 W Unity   : Not running Google VR from an Activity; Ignoring execution request...
03-08 12:57:27.338 10948 10965 E Unity   : [EGL] Failed to create window surface: EGL_BAD_ALLOC: EGL failed to allocate resources for the requested operation.

[ghost]

I'm receiving the same bottom two lines as you:

03-08 12:57:27.156 10948 10965 W Unity   : Not running Google VR from an Activity; Ignoring execution request...
03-08 12:57:27.338 10948 10965 E Unity   : [EGL] Failed to create window surface: EGL_BAD_ALLOC: EGL failed to allocate resources for the requested operation.

It's causing my app to crash, in my use case I'm switching between mono and stereo versions of my app using VRSettings.enabled and VRSettings.LoadDeviceByName(), where my stereo device is Cardboard (not Daydream). It's not happening consistently and sometimes works successfully - haven't found anything on the web about this.

Have you got anywhere with it?

[vinhui]

I also do the switching between mono and stereo. I haven't found a solution and I assume i can't fix it without the help of unity or google

[ghost]

Yeah, I've done some reading and this used to be supported in the Google VR SDK via 'Magic Window', but this was removed while they are natively integrating with Unity. From the looks of things this will come back, but until then I guess the options are:

• Workaround the issue (I've had some success but it results in tonnes of OpenGL errors in the console) until 'Magic Window' comes back - which will probably be whenever the final release of Unity 5.6 occurs
• Use 5.5.x and an older version of the GoogleVR SDK where 'Magic Window' was still supported
• Find another solution to the requirement of Mono and Stereo versions - for me this just means two different applications for the time being

[vinhui]

5.5 isn't an option since I also need daydream support. I have the switching working, it just throws a ton of opengl errors.

[ghost]

Yeah figured that'd be an issue for you. Clutching at straws but doesn't the Google VR SDK contain the Daydream support now, so you should be able to import it all into 5.5 and it may just work? Not tried it myself of course, but might be something.

I'd make peace with OpenGL errors if it wasn't for the fact that I'm getting crashes too. Oh well, not sure we're going to see any official fixes until both Google and Unity are ready with final native support.

I did some more digging and I know that using the VRModeEnabled bool in GVRViewer.cs can be used to change between mono and stereo, but again this only works pre-native support, maybe that was the script application of magic window. I'm going to give it a try anyway.

[ghost]

I can confirm that on 5.5 I can use the VRModeEnabled bool to switch between mono and stereo without issue (or errors) and that's using Google VR SDK 1.3 - just don't switch on VR in the player settings and you should be good to go for Daydream or Cardboard as you please :)

[fredsa]

Note that VRSettings.LoadDeviceByName "Loads the requested device at the beginning of the next frame." See https://docs.unity3d.com/ScriptReference/VR.VRSettings.LoadDeviceByName.html for a code snippet for switching VR SDK / device at runtime using a Coroutine, which requests the async loading of the new device, waits one frame, and only then sets VRsettings.enable = true:

IEnumerator LoadDevice(string newDevice) {
    VRSettings.LoadDeviceByName(newDevice);
    yield return null;
    VRSettings.enabled = true;
}

In my game I'm able to reliably switch between VR (Daydream / Cardboard) and non-VR (my home grown implementation of Magic Window), using either of the current Unity builds which offer native Daydream support, which as of this moment (i.e. March 10th, 2017) are:

1. "Stable": 5.4.2f2-GVR13 (https://unity3d.com/partners/google/daydream)
2. "Beta": 5.6.0b11 (https://unity3d.com/unity/beta)

My home grown Magic Window uses the "" (=none) VR device and the phone's gyroscope to recreate magic window mode.

Note by the way that the order of the VR SDKs in 'Player Settings > Virtual Reality SDK' matters. Unity will try to load the first supported device based on the ordering in that list.

Personal recommendation: Unity 5.4.2f2-GVR13 has proven quite stable for me as I've been using it for several weeks on my main project. However, the 5.6.0 beta series is really coming along nicely as well. It seems there's a new build every few days which is noticeably improved from the previous beta. I'm still seeing some "beta"ness in 5.6.0b11 (which is of course expected for a beta). If you want an as stable as possible build, use GVR13. If you can tolerate a bit a "beta" in your dev environment, or would like to have all the latest fixes, they do follow the 5.6.0 beta series, and don't forget to check back every few days!

[vinhui]

@fresda I actually have to wait 2 frames instead of 1 before enabling vr because otherwise cardboard wasn't showing stereoscopic

[fredsa]

@vinhui I've definitely seen cases where a second yield statement was needed.

Thinking about this a bit, I wonder if it's due to the difference between yield null (as recommended in the docs) and yield new WaitForEndOfFrame(), which is I think what I've since switched to everywhere in my code where I want to wait for the next frame. See also this thread: http://answers.unity3d.com/questions/755196/yield-return-null-vs-yield-return-waitforendoffram.html

Could you try something like this:

IEnumerator LoadDevice(string newDevice) {
    VRSettings.LoadDeviceByName(newDevice);
    yield return null; // try also: yield return WaitForEndOfFrame();
    if (!VRSettings.loadedDeviceName.Equals(newDevice)) {
      Debug.LogWarning("Waiting extra frame…");
      yield return null;
    }
    VRSettings.enabled = true;
}

See if

1. You always need the second yield return null
2. The runtime behavior changes if you replace with yield return null with yield return WaitForEndOfFrame()

[vinhui]

I use the waitfornextframe instead of null but I didn't know about the difference between the two. I got the switching working as well, and seems to work nicely apart from the log bring spammed with opengl errors

[fredsa]

Glad it's working for you.

I've left the defensive !VRSettings.loadedDeviceName.Equals(newDevice) checking in my code, to make sure I can easily catch this situation in the future. I also have a similar !VRSettings.enabled check after setting enabled = true, just to be sure. (Those two extra checks are cheap at runtime and only happen when switching between VR and non-VR.)

[vinhui]

By the way, you could also put the equals check in a waituntil https://docs.unity3d.com/ScriptReference/WaitUntil.html Makes the code just a bit shorter, but yeah, actually waiting for it also seems like a good idea

[fredsa]

After reading https://docs.unity3d.com/Manual/ExecutionOrder.html more closely, and after some testing, it seems that the https://docs.unity3d.com/ScriptReference/VR.VRSettings.LoadDeviceByName.html documentation is correct: use yield return null after invoking VRSettings.LoadDeviceByName(...) to wait until the next frame.

Using yield return new WaitForEndOfFrame() is not the right thing to do as it returns control at the end of the current frame, which is too soon.

[dave8172]

Hi, I can assure that Unity version 5.6.1p1 (patch release) fixes the OPENGL NATIVE PLUG-IN ERROR and hence fixes the crash. I have tested it and I am getting no crash at all. Thanks.

[nathanmartz]

Great!

[lachlansleight]

I am most definitely still having this problem in Unity 5.6.1f1, specifically when switching back and forth between VR mode on and off a couple of times. Still testing.

EDIT: After some more testing, here are my findings:

On a non-daydream device (Galaxy S7 Edge), and only when I do not have daydream included in the list of VR devices (i.e. only "None" and "Cardboard"), I am able to swap in and out of VR mode many times (read: I tried it like 10 times and it didn't break) without crashing, although I do get the constant "GL_INVALID_VALUE: Numeric argument out of range" errors getting dumped to the console.

When daydream is included in the project settings, I get "Error Enabling Async Projection. Aborting load operation etc. etc." every time and can never successfully enter VR mode (it just opens my VR scene in 2D mode)

On my Pixel XL, when I do not have cardboard included in the list of VR devices (i.e. only "None" and "Daydream", I'm able to enter VR mode sometimes once, sometimes twice, but always I will eventually get the dreaded "Numeric argument out of range" which is always followed by a crash.

To clarify, this is the function I'm using to switch devices (with VRDeviceName being either "cardboard" or "daydream" depending on whether I'm running in cardboard or daydream mode. I replace VRDeviceName with new string[] {"daydream", "cardboard"} in the case of including both daydream and cardboard in the player settings):

VRSettings.LoadDeviceByName(VRDeviceName);
yield return null;
if(!VRSettings.loadedDeviceName.Equals(VRDeviceName)) {
    Debug.Log("Waiting an extra frame to set VR device to " + VRDeviceName);
    yield return null;
}
VRSettings.enabled = true;
if(!VRSettings.enabled) {
    Debug.Log("Waiting an extra frame to enable VRSettings");
    yield return null;
}

[arjenveenhuizen]

The exact same behavior (ton of GL errors/random crash on switch) is still happening on Unity v2017.1.0xb3 when switching from None to Cardboard or vice-versa (on Samsung S7 Nougat)...

[CJNA]

It is solved by updating to patch release. (p4) Assuming this is Unity Engine issue, you won't be able to perfectly solve it by work round. I highly recommend updating or degrading the unity engine and start building.

[Sanoend]

Unity 2017.2.0f3 there is this bug ((((

[rusmaxham]

Try the latest Unity patch release of 2017.2

[Neogene]

Have the same problem on latest 2017.3 on Android - Nokia 3 device.

[Epiczzor]

Having the problem in 2019.1.6f1 on Oculus Quest when using Oculus Avatar SDK