Feedback wanted : new Input system support

In 1.0.0-preview.8 we have made the Event System component compatible with the new Input System.

By default, UI Toolkit’s runtime event loop relies on IMGUI events and the legacy Input Manager to get its data. However, Unity now offers a way for users to use a new Input System paradigm, through the com.unity.inputsystem package, and an option to disable use of the legacy Input Manager completely.

Since Unity encourages its users to try out the new Input System paradigm whenever possible, we want UI Toolkit to offer a graceful, out-of-the-box integration with that system. For our first stable version of the UI Toolkit runtime EventSystem component, we want our users to have a single component that automatically detects which Input System paradigm is in use and connects its event loop to the appropriate underlying data.

The EventSystem Component

Default implementation (with old Input Manager)

Up to release 1.0.0-preview.6, the only way for UI Toolkit runtime users to receive events was through the EventSystem component, which allowed them to remap a few of the standard input sources through InputManager axis and button names.

Starting from release 1.0.0-preview.8, users are now able to continue using UI Toolkit when the legacy Input Manager is disabled. We implemented an Input System-based version of the EventSystem component, swapping the implementation under the hood and providing a tailored custom Inspector, to make the user’s transition to the new Input System as transparent as possible.

Note that the component is exactly the same, no user action is required to replace one by the other, and the new Input System version is automatically chosen whenever the new Input System is available, i.e. both the package is detected and the Player Settings input mode is set to anything other than “Input Manager (Old)”.

In the code, a combination of UNITY_INPUT_SYSTEM and ENABLE_INPUT_SYSTEM compilation flags are tested to enable the sections that apply to the new Input System.

New Input System implementation

This version of component is inspired by the Input System implementation of UGUI’s Input Module (Class InputSystemUIInputModule | Input System | 1.0.2).

The emphasis is on the Input Action Asset field which serves as a starting point for configuring all the various input actions in accordance with the new Input System paradigm. Actions that aren’t configured can be left to “None”, in which case the action will never occur.

Once the Input Action asset is configured, a number of standard UI Toolkit actions can be directed to this asset:

  • Navigate is a Vector2 input equivalent to the “Horizontal“ and “Vertical” axes in the regular Event System. So are Submit and Cancel.
  • The Tab action offers a way to remap what input drives the focus navigation towards the next or previous focusable element of the Panel.
  • The Point action triggers PointerMoveEvents
  • The Click, Middle Click and Right Click actions trigger PointerDownEvents and PointerUpEvents, according to their “pressed” state
  • The Scroll Wheel action triggers WheelEvents

The other fields are:

  • Repeat Delay: Delay in seconds before a navigation or keyboard event starts repeating if input control is held down.
  • Repeat Rate: Delay in seconds between successive repeated navigation or keyboard events after the first one.
  • Fallback on IMGUI Keyboard Events: Enable this to get KeyDown and KeyUp events directly from IMGUI Event queue for maximal backwards compatibility.

Note that future versions of the UI Toolkit package may invalidate the serialization format of the new EventSystem component and lead to some loss of user configuration, until the component adopts a more permanent serialization convention. The current version relies heavily on the use of #if to detect the new Input System package, and may not retain any of the configurations from the regular EventSystem component when the internal implementation and custom inspector are replaced.


Unblocking users already working with the new Input System was primary goal, but we’re curious to hear about what you’d expect to see from a UI Toolkit and Input System integration.

12 Likes

Hi, Thank you for updating UI Toolkit to work with the new input system. I just tried out 1.0.0-preview.8 and noticed that UGUI is still receiving touches even though I have a UI Toolkit button on top of the UGUI. Is this expected or will this be fixed in a future release?

Hello,

Coexistence with UGUI is not something we have looked at yet. Can you tell us more about this use case? How would you expect to control the priority between the two systems?

We are hoping to leverage both UGUI and UITK (UI Toolkit) simultaneously since UGUI still has a lot of animation abilities that we would like to use. We plan to have both UGUI popups and UITK popups or a hybrid popup that uses both UGUI and UITK for parts of the popup where we need more advanced animation features. An ideal system would be if the UITK element processes a touch but will not propagate to the UGUI layer.

1 Like

I’ve setup UITK and new Input system on 2 different projects.

The first project was already setup to use the new input system. It had some issues with the event system, I couldn’t select any actions. I had to restart the editor to get it to allow me to set the event system up. After which it doesn’t accept any input on anything I try. I’ve tried uninstalling/reinstalling the runtime api and it keeps giving me the same problem I stated above. Not sure how to fix this one, going to keep trying different things to see if I can. As a side note the project was already using uGUI.

With the above issues, I started another project. Once I had everything setup, anything in the editor using UITK didn’t render correctly. Restarting the editor didn’t fix the issue, I had to switch back to the old input, then switch to the new input, after that everything rendered correctly and input worked at runtime.

Hello,

Would you mind giving us the combination of versions of Unity, UI Toolkit and Input System that you are using?

I am using Unity 2020.1.5, UIToolKit 1.0 preview 8 and the Input System is 1.0.

I’ve tried this exact version cocktail and I am not observing any rendering issues. Please do submit a bug so we can have access to screen shots, logs, etc.

The input system integration into the EventSystem is great, though there are some serious issues in runtime.

This is me interacting with a Slider control:

Using the latest UIToolkit and the latest Input System.

@LudiKha Thanks for letting us know! This needs to be addressed real soon.

Can you file a bug report using Help->Report a Bug… That will let us both track the issue and its fix.

2 Likes

Alright, I just submitted the report. Also verified this occurs in any fresh project.

2 Likes

I’d love to use the new input system. I’ve tried preview-8 and preview-9 in conjunction with 2020.1.6f1 / 5.f1 / 1.2f1 (all combinations I believe). 2020.2.0b4 does not forward-upgrade properly and the recommended 2020.2.0b2 is no longer available for download.

In the above configurations, installing the Input 1.0 package results in this:

Manifest for above (w/ 2020.1.6f1):

{
  "dependencies": {
    "com.unity.addressables": "1.8.5",
    "com.unity.collab-proxy": "1.3.9",
    "com.unity.ide.rider": "2.0.7",
    "com.unity.ide.visualstudio": "2.0.3",
    "com.unity.ide.vscode": "1.2.2",
    "com.unity.inputsystem": "1.0.0",
    "com.unity.mobile.android-logcat": "1.1.1",
    "com.unity.render-pipelines.universal": "8.2.0",
    "com.unity.test-framework": "1.1.16",
    "com.unity.textmeshpro": "3.0.1",
    "com.unity.timeline": "1.4.0",
    "com.unity.ugui": "1.0.0",
    "com.unity.ui": "1.0.0-preview.8",
    "com.unity.ui.builder": "1.0.0-preview.7",
    "com.unity.visualeffectgraph": "8.2.0",
    "com.unity.modules.ai": "1.0.0",
    "com.unity.modules.androidjni": "1.0.0",
    "com.unity.modules.animation": "1.0.0",
    "com.unity.modules.assetbundle": "1.0.0",
    "com.unity.modules.audio": "1.0.0",
    "com.unity.modules.cloth": "1.0.0",
    "com.unity.modules.director": "1.0.0",
    "com.unity.modules.imageconversion": "1.0.0",
    "com.unity.modules.imgui": "1.0.0",
    "com.unity.modules.jsonserialize": "1.0.0",
    "com.unity.modules.particlesystem": "1.0.0",
    "com.unity.modules.physics": "1.0.0",
    "com.unity.modules.physics2d": "1.0.0",
    "com.unity.modules.screencapture": "1.0.0",
    "com.unity.modules.terrain": "1.0.0",
    "com.unity.modules.terrainphysics": "1.0.0",
    "com.unity.modules.tilemap": "1.0.0",
    "com.unity.modules.uielements": "1.0.0",
    "com.unity.modules.umbra": "1.0.0",
    "com.unity.modules.unityanalytics": "1.0.0",
    "com.unity.modules.unitywebrequest": "1.0.0",
    "com.unity.modules.unitywebrequestassetbundle": "1.0.0",
    "com.unity.modules.unitywebrequestaudio": "1.0.0",
    "com.unity.modules.unitywebrequesttexture": "1.0.0",
    "com.unity.modules.unitywebrequestwww": "1.0.0",
    "com.unity.modules.vehicles": "1.0.0",
    "com.unity.modules.video": "1.0.0",
    "com.unity.modules.vr": "1.0.0",
    "com.unity.modules.wind": "1.0.0",
    "com.unity.modules.xr": "1.0.0"
  }
}

I am not getting this on my end, can you post the Editor.log files showing all compilation errors?
I’d like to know as well what your Player Settings look like for the “Active Input Handling” setting.

Regarding 2020.2.0b2, you should be able to install it through this link: https://unity3d.com/unity/beta/2020.2.0b2

I am experiencing the same issue using 2020.0.0b2 after enabling the new Input System and doing the necessary restart of the editor. I am using UITK preview 9 with a new URP template project

Here is the error message from the editor log

I was able to fix the issue by installing the UI Builder package before enabling the new Input System. The problem does not reoccur after uninstalling the ui builder (for now).

I am experiencing an issue with the Input System when capturing the mouse.
I set up a little example below to illustrate the problem:

I set up two visual elements, one of which can be dragged around with the mouse and another that logs a message on mouse enter.

Here is the code:

public class UiTest : MonoBehaviour
{
    public UIDocument doc;
    private Vector2 dragStartPos;

    private void Start()
    {
        var root = doc.rootVisualElement;
        var drag = root.Q("drag-me");

        drag.RegisterCallback<MouseDownEvent>(e =>
        {
            e.target.CaptureMouse();
            dragStartPos = e.localMousePosition;
        });

        drag.RegisterCallback<MouseMoveEvent>(e =>
        {
            if (!e.target.HasMouseCapture())
                return;

            Vector2 delta = e.localMousePosition - dragStartPos;
            drag.style.left = drag.layout.x + delta.x;
            drag.style.top = drag.layout.y + delta.y;        
        });

        drag.RegisterCallback<MouseUpEvent>(e =>
        {
            e.target.ReleaseMouse();
        });

        var area = root.Q("area");
        area.RegisterCallback<MouseEnterEvent>(e => Debug.Log("Enter Area"));
    }
}

This is the behavior I get using the old Input Manager. The MouseEnterEvent on the area is only called once on enter, as expected.
6382434--711237--Drag_OldInputManager.gif

Using the new Input system I get this behavior. The MouseEnterEvent seems to be triggered with every MouseMoveEvent instead.
6382434--711240--Drag_InputSystem.gif

4 Likes

I’ve been running into an issue where mouse/pointer button events aren’t working. Mouse enter/leave is working fine.
I managed to use the debugger to find that the clicks are being caught, and reach the SendEvent function in InputSystemEventSystem.cs (line 454) - but the debugger freezes for me whenever I try to debug further into that, so I don’t know why it fails.
No error is presented, and I get that error even on the root element of the visual tree.

Hello ! I don’t know if MouseEnterWindowEvent and MouseLeaveWindowEvent are supposed to work at runtime (they are in the UnityEngine namespace), but I wasn’t able to do so using the new Input System.

Unity 2020.2.0b2
com.unity.inputsystem: 1.1.0-preview.1
com.unity.ui: 1.0.0-preview.9

Hello, these events will not be sent for player panels. There are really only meant for the Editor right now, though we may support them in the future for the player.

1 Like

Can you guys report bugs please? It is much easier for us to follow up on them this way! Thanks

Sure! Reported Case 1284910

1 Like