I have a simple app for Oculus Quest about exploration where one OVRPlayerController must go through 3 scenes , and when he achieves the third one, will go again to the first one and so on in a infinite loop. My issue is when I complete a cycle and start again into the first scene looks like the OVR plugin stops working, and the input controller (thumgsticks) stop responding anymore… looks like my singleton is not working properly. I have a singleton script attached to the OVRPlayerController gameObject, that looks like this:
using UnityEngine;
public class PlayerSingleton : MonoBehaviour
{
public static PlayerSingleton instance = null; //Static instance of GameManager which allows it to be accessed by any other script.
void Awake()
{
if (instance == null){
//if not, set instance to this
instance = this;
//If instance already exists and it's not this:
}else if (instance != this){
//Then destroy this. This enforces our singleton pattern, meaning there can only ever be one instance of a GameManager.
Destroy(gameObject);
}
//Sets this to not be destroyed when reloading scene
DontDestroyOnLoad(gameObject);
}
}
Looks like the OVRPlugin somehow is being blocked. The strange thing is that not only the controllers stop working , but some elements of the game like a trigger stop working as well, however on the Editor this trigger works fine after a complete cycle of loop.
With this I was trying to silence the OVRPlayerController before its awakening but the problem continues…
I don’t know what more to do , but I am sure that the singleton pattern is the problem, because if I place another OVRPlayerController into the second scene, the issue comes up at that scene when I try on Oculus quest … :S
I don’t use the OVRCameraRig (turns out, you don’t need it!), but my guess is that some script on that is trying to be helpful and do some clean-up when it is destroyed… such as somehow shutting down the oculus SDK, making it unresponsive thereafter.
The simplest solution is to probably give your game a loading scene. Put your player/camera rig in that, with the DontDestroyOnLoad method. Make it the first scene in the build settings. And then have it immediately load the first scene in your loop (which should no longer have an OVRPlayerController in it).
You’re going to need this sort of thing anyway, if you ever submit to the store, because it is very important that your app load as quickly as possible — even if it’s just to a loading scene. The player just sees blackness until your first scene loads, so you want that to be very quick.
Thanks for your help Joe, that’s a good solution. However I don’t actually want any loading scene , this is a very quick experience for a game fair. There will be a lot of Oculus quest, and we cannot use controllers even for the startup. That’s why I wanted the loop since the beginning. Previously I had a loading scene but I turned it out.
I could finally solve the issue by destroying the OVRPlayerController at the third scene, just before the first scene is async loaded and just after a greetings splash screen over a world space canvas. The solution is not the best but the result is pretty good hehe
I ran into the same issue, having an instance of the ovr rig in each scene (for simple testing of individual scenes) caused input to stop working when we moved between scenes. I use a similar destructive singleton pattern though and ours seems to work with that:
// Called on Awake
T tOnThis = GetComponent<T>();
if (Instance == null)
{
Instance = tOnThis;
}
else if (Instance != tOnThis)
{
if (replaceExisting)
{
Destroy(instance.gameObject);
Instance = tOnThis;
}
else
{
Destroy(gameObject);
}
}
The only difference I can see is that we don’t use DontDestroyOnLoad, instead our loading scene is kept around and other scenes are loaded additively. So the original rig stays in the original scene.
