Welcome! New input system resources and info (please read)

I'd be interested in seeing those threads if you have links.

If you want a place to vote for a feature like this, there is always the feedback site.

Right. Unfortunately we can't read all threads in the forums and I guess we missed those more specific ones.

Right. The problem is that with the long frames approach, you somehow have to be able to tell the back-end about what kinds of input you care about and what doesn't matter. And because we have a very minimal back-end and a lot of input translation and processing work happen in the front end only, there's no simple way to tell the back-end "you should resume on this specific input" because the input is in a different format on the back-end, and our translation logic only goes in one direction.

With the skip frame approach, we wouldn't have this problem as the code that handles the input can know exactly what input is used and what isn't and skip or not skip frames based on that.

For physics, you'll get the same amount of physics frames regardless of the target frame rate, so neither approach will make a difference there. For animation, skipping animation might make sense for a frame. If you could profile your games and see yourself which systems take up the most processing time, that could be helpful for informing if the skip frames approach might be viable.

 

A quick search for battery improvement desires from at least 2 years ago (usually with the suggestion being lower framerate):
https://forum.unity3d.com/threads/frame-rate-control-on-android-extending-battery-life.107939/
https://forum.unity3d.com/threads/phone-getting-hot-battery-drain.271749/
https://forum.unity3d.com/threads/battery-drain.196207/

Threads that specifically mention setting their framerate really low:
https://forum.unity3d.com/threads/how-to-save-battery.141519/
https://forum.unity3d.com/threads/feedback-on-battery-performance.265762/ (also mentioned at Unite in the video)

In google there are a lot more and there are newer threads as well, I just limited it to around the time of asking you guys asked for feedback or before. At this point, I think it's pretty well established its a pretty wanted feature. That being said if your project managers want some tangible numbers to prioritize then one of us can certainly set up something on feedback specifically regarding input. There is already a related one out there for the more limited solution you described.

https://feedback.unity3d.com/sugges...er-loop-for-lower-power-consumption-on-mobile

 

I certainly appreciate this, I have a lot of callback based input products and some inputs lend itself to a paradigm like this (button clicks, mouse movement, touchscreen push) and some don't (accelerometer, joysticks (unless you specify a dead zone), etc.). In the latter category motion sensors make no sense to ever do since they are noisy and are always changing no matter what you do (even if you laid it flat on a table). Joysticks are troublesome because there is no way to establish "intent" from a zero value, it could be no input like the user walked away or it could be the user is using it and actually doesn't want to move now.

That being said 90+% of the usecases are only going to care about the touchscreen and buttons because battery is only a concern on mobile. The remaining will care about mouse/keyboard using a tablet or laptop or other device that is battery driven. All of those input types should be distinguishable on the back end.

I've done some profiling a long time ago and while stopping rendering would help, it'd be only moderately effective because there are tons of other stuff going on. You really want nothing to be going on (animations, rendering, scripts, physics, etc.). You want the engine completely waiting. I do appreciate that your backend is probably going to be running in a different thread and that you have to tap the main unity thread on the shoulder and say "hey wake up".

I don't have access to Unity source but I'd actually think implementation wise this would be way easier than having each system of unity (rendering, physics, frame setup, etc.) check if there was any input this frame and then just return. Is there something I'm missing?

 

Alright, spent some time to get a lucidchart of how I was thinking how this system could work. This is very much simplified, but should give you an idea of what I was thinking we could hopefully achieve.

https://www.lucidchart.com/documents/view/643bbc32-cb1c-42e4-b171-7bed84584a38

Unfortunately, based on what I know the Application.targetFramerate sleeps the entire player loop thread for the remaining time instead of doing a checkable bool, but I hope we could get that changed or at least have a different player loop path for projects that use this Application.targetFramerate to limit framerate. Also, after I had a discussion with Rune outside of this thread for a bit, he informed me that the InputManager really doesn't have any C++ components other than the gathering step, and a vast majority of the logic is handled on the managed side.

 

There are a number of ways Unity's loop and major systems (physics, animation, etc.) could be implemented only @runevision and @Rene-Damm can really comment on that (or someone that has all the cash needed for a source license). I would doubt any of the input gathering piece needs to talk directly to any of the managed scripts I would think it's the higher level portion of the new input system (input processing) which in your diagram would be a part of the main Unity loop that takes care of that.

I suspect that all of the Unity systems (physics, new high level input processor, animations) that need to be effected by the delta time of a frame, are actually built with this in mind and would operate the same if woken up early. Physcis for sure would do this and say ok it's been 16ms since last frame and my fixed timestamp is 2ms so I need to check 8 physics frames worth. It wouldn't be effected if woken up early. Also, the whole point to saving battery requires that nothing is going on at the moment, so you aren't in the middle of an animation or anything else that might not like the variable framerate.

I really think that all that would need to happen is that the input gathering thread would need to wake up the main Unity thread that contains the loop. Depending on implementation of the Unity loop this might involve different things depending if they are checking a timestamp periodically, or waiting on a timer, or something else, but in general it would need to signal the main thread and then the main thread when notified would wake up early and do it's normal stuff for all the systems in the loop. After that I suspect that everything else could proceed as normal since the subsystems likely check the timestamp anyways as a part of their processing and firing off more events.

The only part that I can think of that would be important is the flag for when this mode should be enabled (which should be actually set at runtime by the user and probably not in player settings). The main reason being is you wouldn't want this logic for waking up early to be in play when running at your full framerate (lets say 60fps or 16ms). The input gathering thread is likely running faster and under normal operation you don't want input detected at 2ms and then it trying to wake up unity every 2ms (500 fps) because no hadware is going to be able to achieve that. In general, I think that's why you'd want to explicitly set this mode at runtime and then have unity turn it off when it first detects input and wait for you to turn it on again. Something like Application.enableInputEarlyWakeup(int newFramesPerSecond); which would set the mode and specify the new low framerate.

Only those with source will know for sure though.

 

Yeah, I put this diagram together after I had a talk with Rune. He requested I bring it back so that he wouldn't need to repeat himself. He mentioned that the C++ doesn't know anything about input/actionmaps and is currently all driven from managed code. The gather phase is the part of the input system that is driven on the engine/c++ code. The managed code handles all of the actionmaps, input state stack, and will fire our queued events prior to the script update phase. This is to ensure that the inputs can be propagated on the managed script context, and changes as a result of the input can be handled by the usual change monitors.

Yeah, from what I understand this is exactly what FixedUpdate does for the physics system. It doesn't actually update on a separate thread. The FixedUpdate progressively steps forward to the actual frame time that many times before triggering the next script Update(). The input system's managed side depends on a signal before the first FixedUpdate to process the "changes" and fire out the appropriate input triggers, but keeps those triggers around and available for the next Update() as well. Regardless, this mechanic doesn't really work well for what I want it for, which is to wake up the player loop thread on the engine immediately so that there is relatively small amounts of delay between input.

I had a Unity contact check into this to see if they could give me a rough idea on how their current Application.targetFramerate works, and from what I understood, the code is actually sleeping the player loop thread based on the remaining time left of frametime. So interrupting it currently isn't really possible. As you mentioned, the player loop thread would need to conditionally check a flag/time, and the concept of forcing the next frame would set the time to < 0 or using a bool flag. This to me is the biggest disappointment because this is a big multi-platform change and thus a good chunk of risk. Unless we could somehow get a specialized interruptable player-loop developed and tested for mobile that doesn't risk other platforms.

Yeah you're correct. You don't want this input thread to wake the playerloop when running at our target framerate. Having a sync flag on the InputManager that allows us to "forceFrameOnInput" could be a good way to handle it. So that when we return to our desired framerate, we can set that flag to false and the managed input thread wouldn't check wake inputs anymore.

Regardless, I understand the desire to get the new input system out ASAP, and for a lot of platforms what we're trying to do here isn't really applicable. Most desktop, VR, console games are going to not have this artificial frame delay. Having said that, mobile dev is a huge chunk of Unity's user base and I hope that Unity recognizes the importance of allowing devs an easy way to adjust framerate without input delay. This would be a big win for developers, but more importantly the perceived quality by end-users of our products.

 

I didn't realize that the managed "input processing" piece was actually another thread as well apart from the others (4 theads pictured in your diagram). When Rune mentioned that it was tied to the main loop I assumed it was on the same thread with the main loop and that just the input gathering piece was on a separate thread. Doesn't this make the problem the same though? That "input processing" piece is still in a separate thread and has to signal the main loop to wake up early.

I'm not familiar with what Unity uses for threads or sleeping on the C++ side whether they use a library or roll their own (like std::thread and usleep, posix pthreads and sleep, etc.) but the concept of waking up another thread via a signal from a separate thread is fairly basic and regardless of implementation should be doable. This shouldn't be a holdup from a technical perspective.

Realizing this was a realized by Unity at the 11th hour, it's understandable for them to not want to slot it immediately, they have more pressing matters. It's certainly their decision. Having worked for large companies in the past though, this will mean it will likely not be incorporated for a long time (years heck the rewrite in general is going on 3 years now and still feels like it won't be non experimental and on more than desktop before end of year). Not trying to sound ungrateful, in fact personally I feel the opposite, especially if in the end we get something good like uGUI rather than a bit shaky like UNET. I'd rather they take all the time they need. It's just important to know that this means that waiting on a responsive Unity with a low framerate will be a long ways off. In the meantime writing that new input module will be necessary and will at least register all the clicks but won't render it until the player loop comes around.

 

I think your understanding is what is currently correct. The managed input system is handled predominately on the main managed thread. My proposal was to add another managed thread to handle this wake-up mechanic. The reason why I want to put it on the managed side was so that we could still have closer access to the types of inputs that would wake-up the player thread (such as the actionmaps and input parsing) without duplicating that logic to the C++ side.

I'll yield to you and other's knowledge of threading APIs. I certainly didn't look at the source myself. However, regardless, they need to change the player loop thread to check a conditional statement for its sleep. Not a minor change in my book. For something that is called every frame on every platform it will need to be profiled and analyzed to determine there aren't unintended side effects much more thoroughly than an opt-in experimental new input system.

Ha, as a person who does a lot of UI work I would argue that UnityUI has been pretty shaky too. I share the same concern for delay, hence why I started ringing alarm bells when I saw that post. Thanks for your help trying to push this feature. Hopefully, we can convince the right people of its value and it doesn't get put on the back burner for another 3 years.

 

Ah, I see. I would say that if Unity does manage to have the input gathering thread signal the main thread to wake up early, this would be unnecessary. It would still be able to do all it's action map stuff and everything else when the main thread is woken up due to detecting the input occurring.

From a coding perspective it's fairly small. From a testing perspective I'm totally with you that it's huge as the main player loop is the most core aspect of Unity and effects everything made on the platform. You certainly would want to make sure that it behaves correctly and without side effects on every platform since various OSes handle these basic things differently. I don't think it's likely that we see this for the soon to be here experimental build (although to be fair if this is going to get eventually adopted then an experimental build is what eventually will have to be done anyways). If full regression testing is going to be needed regardless of what changes with the new input system then it might be best to get that code in ahead of that rigorous testing that was going to take place anyway. I doubt this will happen though and it will come later, if it ever comes.

It has it's quirks and under certain cases has performance issues but vs. the old onGUI() stuff it's much better. If you're comparing it to NGUI or something else then it's debatable. If I'm not really pushing things I prefer to use the uGUI system and only go back to NGUI when really necessary due to draw calls or other things. From a usability perspective, uGUI is much faster to get off the ground but not as well optimized. UNET is on much shakier ground.

I hope we'll see it too, it frees a big pain point for a lot of games/apps, can't say I'm that optimistic though. Only time will tell. Every now and again Unity still surprises me and does something quickly like when they were a smaller company. I'm well aware that when you get big its very difficult to turn a ship quickly. Being large has it's benefits too (like supporting all the platforms they do) but certainly has its drawbacks as well.

 

@Ferazel @greggtwep16 and others who are interested in low frame rates to preserve battery, let's continue this discussion here:

https://forum.unity3d.com/threads/b...t-with-immediate-new-frame-upon-input.476263/

I'd like your thoughts on the post there.

 

Any way we can start toying around with the new Input System in the current 2017.2 Beta (0b.2)?

I see there is a setting for it under player settings

 

RIP Rewired. Just bought it!

 

Looks like it's on the roadmap now as well, so there's hoping to be able to test it soon.

 

I'm using rewired fine and currently I don't have a plan to stop using it unless Unity's one performs better and is more reliable. I think that will take a while

 

So I wanted to check this out, got 2017.1, changed the setting in Player settings, but can't find any single reference to anything other than the legacy input system. All the docs/getting started guides seem completely out of date.

Is it disabled for now or something?

 

I think it's

Code (CSharp):

1.  
2. using UnityEngineInternal.Input;
3.  

But I haven't yet taken the time to figure out how to use it

 

Is there no GUI?

 

They said they would announce an experimental separate build when it's ready. Since that hasn't occurred yet, this is just what people have discovered that's in place before the experimental build. I'm sure the first time we'll see the GUI is the experimental build.

 

Ah, okay. I was under the impression something was available since there was a option to toggle it.

Thanks

 

Wait... you're a moderator?

 

Yeah?

 

You can use Asset Post Processor script that will parse the entire AppDomain using reflection and dynamically create ActionMap assets mapped to attributes found in classes.

 

I watched your Input Design video and what you appear to attempt to do appears good! because it tackles local multiplayer handling and appears to not rely on project wide hardcoded Input Axis as currently is the case.

Good things are: runtime-bindable "input axis" and intra-project changable bindings of them

Also a good thing is (if this is possible on PCs): polling of input values independent of frame rate eg polling at 500 Hz.
This can be used like: using the sampled input values linear-interpolated to calculate the position of the controlled object at each time of a sample taken (yes, 500 positions when 500Hz) and then estimated at the time of the display of the next frame (yes, this is "guessing" which gets updated each frame and yes this requires starting one time-derivation further down in the motion deq if one handles position like that but it is the most truthful implementation) (non-linear interpolation is not increasing precision significantly here) (think flight sims or racing sims) (I used this approach for a basic sim of a controllable flying object but for some reasons then did a simpler model).

 

Moderator: yes. {Some epic dude/dudet/?both/either/nor/all that has offered up time and effort, rarely for financial compensation, that typically has no direct association with the company or site outside of its use that has been given rights to govern activity on said site based on loyalty or w/e criteria has been achieved. _well this site_.}

Unity -insert title here- : no. {Paid Professional or Contracted Employee or etc. of said site/Company}..

Your confusion is warranted . The distinction is clear though. Blue vs Black Title Tag.

 

Glad to see this is on the 2017.2 roadmap although it looks to be 'endangered' again. I will use 'Rewired' asset in the meantime as I'm sure even when the new Unity input system in finished and polished 'Rewired' will be adapted to take advantage of it.

 

Just found an option to select the new "Input System (Preview)" in the player settings for 2017.1
But Can't find any docs to support it, any ideas anyone? @runevision ?

 

We can't do anything with it yet. See https://forum.unity3d.com/threads/status-update-on-new-input-system.451818/#post-3167468

 

Thanks for the Hot Tip @PhilSA

 

I need to start adding Input. I purchase rewired time ago, but I also like Unity core code. What do I do at this point?
Start using rewired or the Unity one?

 

It's up to you, try both of them

 

New Input System will allow something like virtual/simulated input? I would like to fill input values from many sources like touch, or network. This way, I can use only one system to read data from player in many ways.

 

Yeah In Control and Rewired does that too, but I actually build yet another layer on top of that so it's basically all based on a single preferred controller of my choice so my AI can use it too. I think Unity's new input allows this behaviour and pattern also.

 

Yep, that's supported.

Some cases we have tested is creating a virtual gamepad device driven by UI controls on the screen, and creating a virtual head mounted display that's driven by mouse and keyboard. You can create any virtual devices and drive them by your own logic.

 

@runevision what are the chances of having mappings for all common controllers like rewired does? I just work with my virtual controller, but it has common bindings with all current market controllers, such as xbox 360, xbox one, ps3, ps4 and a large number of logitech and other devices.

Rewired does have this and it's the reason I hesitate to swap. Because I know my users will plug in their joypad and there's a very, very high chance it works with zero binding or modification on the User's side. This is actually far more important than any other feature in my mind... and the sole reason I can't switch, probably ever, unless I can address it and I don't have those resources.

My thoughts are (honest and unfiltered): Why would I make customers downrate my app or game?

Basically I'm saying that the feature set is far less important than it just working out of the box on devices out there in the wild without requiring remapping from the user. If unity hasn't considered this, then it offers nothing over what asset store has.

I would recommend at least a unified way for people to submit hardware mappings so we could all benefit? Or maybe that's a plan we can start working on - need to be able to just have it work on the majority of devices without remapping

 

Input standardization is a major feature in the system and our goal is to have mapping for all common controllers. We don't currently, but it's on our roadmap.

At an earlier point we were working together with Patrick of InControl to be able to use converted versions of those device profiles. However, since then we have made changes in the input backend which allows for greater flexibility (some controls are now exposed that were not even made visible in the old input manager), but also unfortunately means we could no longer perform any automatic (or manual) conversion of those existing profiles. They will have to be built up from scratch.

Anyone will be able to add profiles just by having them in the project folder, without needing source for the Input System. And if the community is able to add support for certain devices faster than we're able to get around to it, we'll be happy to take pull requests. I know this is not the ideal scenario; it would be better if we had this all out of the box from the beginning; but we're a very small team with a quite large task, so bear with us.

 

That is stunning news, thanks. Was foolish to be worried!

 

Is it possible yet to use any of the GearVR controls ( on the headset or the separate controller ) with the new Input System in the latest Unity beta?

The new XR stuff is great so far for supporting viewing in multiple devices, hopefully the new Input System will have an equally great way to support all of the various input systems!

Currently, I'm using Input.GetKeyUp(KeyCode.Mouse0)) for detecting a tap, which works fine, but would be great to start using the new system.

 

I'm really looking forward to this feature. I'm glad to see it will be coming soon.

I noticed that the input-prototype-demo includes an example of a virtual joystick. I was wondering, how does the virtual controller support in the prototype input system compare to what is currently in development for preview release (i.e. how similar do you anticipate the APIs in the actual system will be compared to the APIs in the prototype).

Also, the roadmap page lists the new input system as being part of "Feedback builds". Is this accurate, and if so, is there a way to get access to these feedback builds for testing purposes?

Thanks

 

@runevision
will the new input system have a way to set the mouse cursor position?
being able to lock the cursor to a region while dragging a camera for example would be really helpful.
I know you can already lock the cursor, but that does not offer enough control.
We need to be able to control whether the cursor stays locked to one position (any position, not just the center of the screen) or if it should be clipped to some bounds.

Being able to just set the cursor position would solve everything though.

 

May I suggest pitchforks I've heard those usually help in situations like this no?

It better be the A-team then , If its got anything to do with a V+R team.. its well, lets not imagine.

Seriously I was expecting to see the new input system make its way into 2017.2 ...atleast 2017.3...look do we need to send in the pitchforks?

 

@runevision
Cool OK these things do happen. I suppose you pushed someone's buttons.

 

So I am not quite understanding how it can take already more than 1.5 years to do the new Input Manager. Not trying to sound rude or such but I have seen others create whole games and software in that amount of time. Personally I would much rather use Unity's Input Manager than having to rely on third party plugins. So with the current update/news... what kind of timeline are we looking at now?

 

I can't understand it either. The existing built-in system is ancient, inflexible, and leaves much to be desired. For some platforms it's just straight up not good enough for non-trivial games - try telling a PC gamer that they need to quit and reload to change key bindings! Can the new system have really been so bad that starting again is necessary?

Personally I use Rewired, which is an excellent system. It has some rough edges, all of which could probably be smoothed over with direct engine-level integration. Despite that, it already does all of the things I wish the Unity system did. At this stage, since there's precedent (TextMesh Pro), I think it'd be a good idea to have a serious conversation with Rewired's developer.

 

You don't need to quit and reload to change control bindings, but I will agree that the amount of effort required to get it working in your game using the existing Input System is definitely non-trivial.

 

Hi there! I know that the Input system team is seeing a restructuring and all, but I do just want to mention that I really like the direction it was going in. The multiple layers of abstraction are JUST the kind of thing we need when porting a game to NINE platforms like ours. We use InControl, which is great, but it will be awesome to have a built-in solution!

 

As far as I my research went, it seemed not possible to properly detect if and what Controller was disconnected, without writing custom plugins.

How can any Unity game, that only uses built-in Input, pass Microsoft's or Sony's technical requirements?

 

Consoles almost always have their own APIs. So the answer is simply you wouldn't only use the built-in Input.

 

Any news on a Beta? or is it safe to use the Prototype?

 

It's a bit odd that unity's native input manager has barely changed, if at all, for many many years. Even if you're only developing for PC there are bazillions of joysticks/pads you'll want to support as well as user-defined keyboard configuration, and not being able do such a [seemingly] simple thing out of the proverbial box, is mind-boggling. As I own a Unity 5 pro licence, I now fully expect any form of input manager upgrade to completely overlook me and require me to switch to Unity 2017.

I'll likely get something from the asset store to address this as it's cheaper than going the Unity 2017 route. This isn't ideal, though. You wouldn't be happy if you bought a new bike and had to source your own handlebars (or make do with a lump of old tree branch).

PS: Hello Hippocoder. Small world!