Status update on new Input System?

Seems like it has been several months since last time we heard any real news on the new Input System.

Can you guys (devs) share some info on what you're working on right now, what kind of milestones you have, etc...?

 

Up!

 

Fair enough, I posted an update here:
https://forum.unity3d.com/threads/w...d-info-please-read.397153/page-2#post-2928455

 

More than one year since this forum opened to get a new experimental build?

I will never understand how you internally work... You iterate over something and leave it and move on something else without finishing what you started... That way you will never finish anything...

You are thousands of people at Unity... You should work faster than before...

 

We are only two people on Input Team.

But if you think it's given that more people would let us finish Input faster, look up "The Mythical Man Month".

Input is an area where the design of almost everything depend heavily on everything else, so everything needs to be carefully designed with everything else in mind. That does not easily parallelize, which is one reason it's taking a while. Another reasons is that we have pages and pages of requirements the new system must address which the old one didn't. For any single game it probably seems like it can't be that hard, because most games only use a subset of functionality. But we're not designing an input system for one game, but rather for a wider variety of games and types of input than almost any other input system made. That takes time, and it also means we won't get everything right in the first go.

 

Keep up the good work! I like what we could see so far, seems to be going in the right direction.

 

Why not absorb Rewired as you have Anima2D?

 

The thing about rewired is it has been partial built on the old system. When the new system comes out Rewired can be rewritten and it will be better and easier to expand or create your own thing from the new input system.

 

I know Unity has absorbed a few other packages already, but I'm really not a fan of this practice. It's much better if they integrate a new system from the ground up in the native engine code. This is especially important for input handling

The problem with third party stuff is that they are almost always built as an unnecessary extra layer on top of Unity, and nobody knows for sure if they used proper coding/performance standards or not. It so common to see popular asset store packages that generate garbage and/or have overly heavy editor windows instead of being clean, simple and code-driven (which, in my opinion, is the case with Rewired)

 

@runevision I'm making a simulator. Do you think Unity 5.6/7 users can get "joystick" included in this new Input System prototype?

 

Sorry, we're no longer developing the input system prototype as we moved onto developing the proper system (based on new backend, not on the old input manager) quite a while ago.

In the new system we still don't have generic joystick classes (we've been quite caught up supporting various VR stuff recently) but it's on our list. Definitely not for 5.6 though, and probably not 2017.1 either. What we want to do once the new input system goes in experimental release is to develop this in close iteration with you guys.

Rune

 

@runevision Just a suggestion so that is more clear when we talk about or make reference to it. I mention the "new Input System". I think we are talking about the same thing. Do this new baby system has a fix name? In anyway, can you put it a name as soon as possible? So that is more clear for us when we refer to it. Is not the first time that this happened. A good example is old "GUI" versus new "UI". Can be, also, a final name that works only for this beta or experimental and change name in the final one.

NAMES
Input System Design (first Youtube video)
New Input System (This thread and blog)
new input system prototype (blog reference)
Experimental New Input System [ the web page ]

PS: I suggest to use Experimental New Input System [ ENIS ]

 

You said "Input System prototype" and I said we've left the prototype behind.

Here's some terms you can use:

Input Manager
The current/old feature in Unity where you set up axes and buttons in the Input Manager settings.

Input System Prototype
A prototype of the new input system, but based on top of the old Input Manager. It was released for gathering feedback on the design but is no longer maintained.

Input System
The new feature including both new back-end and front-end. It has similarities with the Input System Prototype, but has evolved quite a bit since that one.

Rune

 

I'm so excited for this progress! The features are greater! Thanks for the reply!

 

Any update on when the new input system is likely to become available would be really useful.

 

2017.1 and on has this interesting setting:


I'm not entirely sure what it means though, or if we need more downloads to make it work (like so many recent experimental features).

 

@runevision
Is there anything at all we can do right now with "using UnityEngineInternal.Input;" in 2017.2? Just a quick hello world to get started? Is it even part of the new system, or was it always there?

So far, the most I've managed to accomplish is this:

Code (CSharp):

1.  
2. using System.Collections;
3. using System.Collections.Generic;
4. using UnityEngine;
5. using UnityEngineInternal.Input;
6.  
7. public class NewInputTest : MonoBehaviour
8. {
9.     void Start()
10.     {
11.         NativeInputSystem.onUpdate = InputUpdate;
12.              
13.         NativeInputSystem.onDeviceDiscovered = DeviceDiscovered;
14.  
15.         NativeInputSystem.onEvents = OnEvents;
16.     }
17.  
18.     void InputUpdate(NativeInputUpdateType updateType)
19.     {
20.         Debug.Log("Input update: " + updateType.ToString());
21.     }
22.  
23.     void DeviceDiscovered(NativeInputDeviceInfo deviceInfo)
24.     {
25.         Debug.Log("DeviceDiscovered: " +  deviceInfo.deviceDescriptor);
26.     }
27.  
28.     void OnEvents(int count, System.IntPtr eventData)
29.     {
30.         Debug.Log("event? " + count + " " + (eventData.ToInt32()));
31.     }
32. }
33.  
34.  

But I've yet to figure out how to actually register and use input events

 

We don't provide support on the low level API; it's extremely raw and not designed to be user-facing. (That's why it's in the UnityEngineInternal namespace.) It needs to be paired with classes that know the internal data layout of the data sent from native. No simple Hello World example would "unlock" it and make it suddenly approachable I'm afraid. We ask for patience for the managed counter-part to be released.

 

See the first post in the sticky thread for current status and timeline expectations:
https://forum.unity3d.com/threads/welcome-new-input-system-resources-and-info-please-read.397153/

 

Thanks for the update. Is this being used by the xr toolkit input stuff or are they extending the xr.inputtracking namespace instead in a separate effort?

 

Yes it's used by the toolkit.

 

Thanks @r3dthrawn @runevision does this mean that eventually the new input system will totally replace what is in xr.inputtracking as well as the more typical conventional input (Input.GetAxis, Input.GetKey, etc.)? It always was apparent that it would replace the typical input but the xr stuff seemed separate and more coupled to various sdks so I'm not sure if that's in the scope of the new input system.

 

Ideally, all tracking data and buttons will go through the new input system. That is the current plan.

 

That would be wonderful, I really hope this comes to be especially for XR. While XR.InputTracking currently allows you to get positon/rotation/etc. the buttons, touchpads, etc. aren't in that namespace as well as anything more specific like recentering the controller (and those vendors seem to be using non standard pairing so they don't show up in the normal Input API either). This usually leads to anything wanting to do XR crossplatform you need to use the 4 different C# sdks which is not ideal. It's bad enough to do that but recently 2 of the SDKs (Google VR and Steam VR) had breaking changes. It would be nice to have 1 API and not 4.

 

We definitely agree. As you are most likely painfully aware, up until now the hardware and SDKs were changing so fast that all of this was a moving target. Now we have a good idea of how we would like common functionality to be processed by a new input system.

 

That's wonderful! If I can help in any way whether it's an alpha test or anything else let me know.

I'd be a little hesitant to say it's not a moving target anymore, the knuckles controller this fall with the finger controls will be something that isn't in any of the other systems (I'm sure it'll be copied shortly though like gear vr did based on the daydream controller). That being said it is surely more calm than it was before. PC/console VR all have positional tracking, Premium mobile VR seems to have settled on a fake IK system from orientation, and budget VR is HMD/gamepad only.

 

Those are good points and agreed that it is still a moving target, we can just see a little further down the road now.

 

I just noticed that the input system disappeared from the release section on the roadmap. Has there been a change or plan? Cheers.

 

Some things outside the control of Input Team has happened. We will let you know when we have something definite we can tell you.

 

Thanks Rune.

 

Good things? (I hope)

 

Update please? The "current status" section at the top of this post does not seem to reflect the actual status.

 

+1 for new status update

 

Okay, the current status is this (updated in the welcome post some of you linked to as well):

Input Team's plan was that the new Input System would be available as a preview release with support for a limited set of platforms and devices for Unity 2017.2. (Indeed, the GitHub repository we have internally can be used with Unity 2017.1 or 2017.2 already.) However, the Input Team were told in the summer that our team has been discontinued and a new Input Team will be formed instead under a different part of the organization. As part of this process, the people involved are taking a step back and reevaluating what to do, which means previously planned timelines no longer apply. We will try to update here when we have new information.

 

That... sounds like bad news.

I'm guessing you cannot say but...

-Why?

-Is the new team taking over what you've done, or are they starting from scratch?

 

Wow that really don't make no sense. That's like running a hundred yard race getting to 99 yards and decided to start all over again. Waited over 5 years for them to start a new input system a year and change on prototyping and rewrite of the input system and now to start all over that's ridiculous instead of keeping the same team in place and adding more people to the team starting a whole new team mean they going to rewrite everything that was done so far. That's a shame so sad. Every game need two main core pieces, that input and output and unity can't even get that input right.

 

It sounds like bad news, but we don't know all the details. For all we know, maybe they've found a team that has tons of experience with input and who knows how to solve issues that remained in the current version of the project. Maybe it is for the best

My only hope is that the new NEW *new* Input System doesn't take a million years to make just because they want to support every possible VR/touch/motion/gesture thingy. I could be wrong, but it really seems like this was a huge obstacle for this new system and that everyone else paid the price for it

Maybe it should simply start by being a really solid & low-latency low-level input API, and then once that's done, you can release it to the public and start building the more high-level / UI parts on top of it

 

Can you release the internal github. And we just stop upgrading unity 2017.2.

 

Thank you for the update, much appreciated!

 

Hmm thats sad, I hope this doesn't have anything to do with that VR fad that unity is pushing currently.

It sounds like the new input system has to deal with many orthogonal problems at the same time.
Shouldn't it be possible to split up the problem into smaller parts?
So having multiple "parts" of the input system and everyone can use whatever part they need.

Just like everything else in the computer world.
First GPUs had a fixed function pipeline, then someone came up with the idea of having shaders;

first we had the monolithic unity render loop, now we're moving towards the scriptable render pipeline.
...

Couldn't a similar paradigm be applied here as well? Splitting this huge new thing into multiple smaller components (so people can use the parts they need)?

(I'm not judging at all, I'm just genuinely interested in what's going on, so feel free to pm me )

 

The jokester in me is thinking they've decided to shelve their own attempts and just buy out Rewired.

 

-"Psyche! All your work was for nothing!"

Such fun!

 

That would at least make sense. However, if they were going to do that they should have just done it years ago (I still would prefer that versus starting from scratch).

Large companies starting/stopping/restarting projects is the worst in terms of frustration. Very rarely does it come from a logical choice versus a political one and when size of a company grows it happens more often, unfortunately.

 

They just bought asset from the asset store and integrate - give the developer a job and all done would save lot of time as there so many out there now..

 

Yikes! That's not funny. I hope they're not planning to double the size of the Unity API!

 

Ok. Do you have a timeframe in which you think you will be able to come back to us with more informations ?

Thanks

 

"Oh, and guys - you haven't been working for us the past two weeks. Your last pay cheque will reflect that."

 

I get that was a joke, but just in case anyone might be in doubt: No one who was in the team have left the company. (And no, we don't have any updates on the situation yet.)

 

Thank goodness

But this input system saga is two-season Netflix special length by now

 

It's part of the Unity cinematic universe. I'm personally looking forward to the 1st season of "Lightmapper" where we see the transition from Beast to Enlighten, and of course the final cross-over of all the series.