It seems the Process method does not fire on Unity 5.5?
I have changed to Update for now, I do not know if this will give side effects however?
Have you filed a bug report?
Hi, No I have not actually.
I’m also not alone having this problem, for example see this comment
This is not something we currently know about. Could you please submit a bug report with a sample project so it can be investigated? Thanks
Sure, I’ll try to get around that later tonight
Hi again, since I wrote this post I upgraded to p3 to fix problem with Occlusion portals, and I guess this was fixed in p1-p3 because now it seems to work. I dont have time to downgrade to 5.5 so I cant help you with reproducing it, sorry
1 Like
I ran into this issue as well, I noticed it after switching from 5.4.3 to 5.5.0f3, but it’s possible it was occurring previously and never noticed… but seems unlikely. Anyway, I’ve narrowed it down to the editor focus. Clicking on the Game tab will begin Process being called, but if you click anywhere outside of the Game tab, Process will stop being called. Whereas Update is always called.
On the surface that doesn’t seem like an issue, and is probably some sort of performance improvement, but many of us are implementing BaseInputModule to get laser pointers working with Worldspace UI in VR, so if we click somewhere while trying to debug or just accidentally click, it makes the UI “lack collision”, i.e. the laser pointer goes through the UI element since Process is what is being used to set the laser pointer distance. FWIW, I’m using a modified version of the Wacki laser pointer implementation, but I believe all of the open source implementations are doing similarly. Super confusing “bug” until I figured out the reason, and remains a mild frustration everytime I put on the HMD and realize I had clicked elsewhere xD. Ideally this would be fixed in some way.
UPDATE: clicking outside of the game window in release builds also disables Process() from being called, which is a bug, and the fix is listed as Unity 2017.1.0b6, so the workaround for now is to put your Process() into Update()
Hope this helps!
Ah, so it was not related to the patch then, I have also noticed that it stops working some times, thanks for finding what’s causing it!
I too am getting this issue both in 5.5.0f3 and 5.5.0p4. So the general fix at the moment is to click on the editor game window. Annoy though, as I’m developing for VR
Come on guys, this is a mssive
Has a bug been logged on this? This is a massive issue for any VR developer, if a window is minimized, or loses focus, all UI within the world will stop responding to the player.
Additionally, my buttons in the desktop window are no longer responding to clicks.
This is what drives me nuts about Unity, instead of getting what I need done, I’ll now spend the next 3 days regressing versions to fix a bug that just randomly appeared out of nowhere.
We’re now like 6 dot releases since this thread was first posted, and the issue is still not fixed?
Did you file a bug report though? I cant see anything reported about this.
No, I haven’t since I’ve just found this thread now after fighting this bug for a day. I need to figure out which version of Unity introduced it, which will take me the better part of today, and then trim down a reproduction case before I can properly file a bug. Just so frustrating that these major things keep slipping through QA.
You can see that is is logged in the bug base for UnityVRInputModule, that most SteamVR people use: Intermittent raycast bug in Unity 5.5 · Issue #5 · wacki/Unity-VRInputModule · GitHub
You can also see it discussed here, in which is the primary UGUI VR interaction plugin on the Asset Store: [30USD] SteamVR UI Input System - Community Showcases - Unity Discussions
1 Like
I’ve went ahead and filed 2 bugs, since really these are separate issues:
#1: StandaloneInputModule is unreliable when using another InputModule
https://fogbugz.unity3d.com/default.asp?896932_uo5vj1j5ua2v09ed
#2: StandaloneInputModule is not processing when Window is not in Focus
https://fogbugz.unity3d.com/default.asp?896933_5i534ng9grqne3lv
1 Like
Also, I did find a workaround for #2, you need to allow the StandaloneInputModule to be enabled initially (I guess Awake, or OnEnable needs to run), but if you disable it in the next frame, then button clicks will no longer be discarded.
So, basically:
class AnyOtherClass : MonoBehavior {
public StandaloneInputModule standalone;
void Start(){
standalone.enabled = false;
}
}
This also gave me quite a bit of trouble … but I finally found out what caused it:
Someone was being smart and added this code to Unity UI / EventSystem in Unity 5.5:
protected virtual void OnApplicationFocus(bool hasFocus) {
if (SystemInfo.operatingSystemFamily == OperatingSystemFamily.Windows ||
SystemInfo.operatingSystemFamily == OperatingSystemFamily.Linux ||
SystemInfo.operatingSystemFamily == OperatingSystemFamily.MacOSX)
m_Paused = !hasFocus;
}
}
See also: Changelog on BitBucket.
Doing this will result in Process() no longer being called on any input modules, including in-VR input modules. So what you get is that when the game has no focus, there’s no more hover or anything. For flatscreen games, this isn’t great but it’s also not a big issue (once you click, the game gets focus and the UI works again). In VR, it’s fatal because there’s no way for you in VR to get focus back to the game. Not sure what the rationale behind that change was … maybe some super-eager optimization or something. Or did someone complain that the UI in Unity games reacted even though the game didn’t have focus?
BitBucket doesn’t have 5.6 in it, yet, so I can’t see if this is already fixed for 5.6.
As far as I can tell, the only way to work around this is to write our own EventSystem that don’t do stupid things like that.
So, here’s what I use now to work around this issue. Please be aware that you cannot simply copy and paste this code and expect it to work because this uses my own MotionControllerInputModule that you probably don’t have in your project, but it’s easy enough to adapt this to work with your own custom input module:
using UnityEngine.EventSystems;
namespace NarayanaGames.VR.UI.UnityUI {
public class VREventSystem : EventSystem {
// IMPORTANT: "MotionControllerInputModule" is the custom VR input module
// I am using. You'll usually want to replace this with
// whatever laser-pointer / VR-UI input module you are using.
private MotionControllerInputModule motionControllerInputModule;
protected override void OnEnable() {
base.OnEnable();
motionControllerInputModule = GetComponent<MotionControllerInputModule>();
}
protected override void OnDisable() {
if (motionControllerInputModule != null) {
motionControllerInputModule.DeactivateModule();
motionControllerInputModule = null;
}
base.OnDisable();
}
protected override void OnApplicationFocus(bool hasFocus) {
/*
* Don't do anything, it's quite stupid to pause
* just because we lost focus. Think of VR :-/
*/
}
protected override void Update() {
if (current != this) {
return;
}
base.Update();
// NOTE: We always want to have VR-input being processed
if (motionControllerInputModule != null) {
motionControllerInputModule.Process();
}
}
}
}
Hmm interesting. Let me look into this change on Monday.
Hi.
So the reason the window no longer gets input when not focused is due to this bug fix: Unity Issue Tracker - The mouse Pointer Enter EventTrigger is triggered through other windows when the app is windowed and not in front
I have made a note for the UI team, hopefully they can come up with a solution that satisfies both situations.
Hi Karl, thank you for looking into this and giving an update.
It seems to me that this was a classic case of throwing the baby out with the bathwater. The “correct fix” as I can tell would be making sure mouse events don’t go through other windows. That does seem like inappropriate behavior but I can imagine that fixing this is much harder than pausing the event system. But doing it that way would have the benefit of not causing side-effects like the one I (and many other VR developers) ran into 