Is the recommended action response format efficient for things like looking around with the mouse?

[Chris-Trueman]

@marcospgp

but if I’m doing a Transform.Rotate() on the camera for every mouse move event I’m doing ~8 rotations per frame, as I checked in the inspector. If I checked the mouse delta inside Update() I would only be rotating the camera once.

This leads me to believe it’s not as efficient. It’s probably equivalent to calling Transform.Rotate() ~8 times inside Update().

I just tested this myself, the faster the mouse moves the more it triggers the event. I get an average of 2 for my current game, but it is up to 8 that I can see.

@marcospgp

I’m not sure what this means, the wording is not super clear. They say:

“The Input System processes events at irregular intervals determined by the current framerate.”

But it doesn’t say how the event processing relates to the framerate. Do they poll for input events 10 times per frame? Once (not the case from what I’ve tested so far)?

Yes it doesn’t make any sense and is not clear enough. After testing all the update setting it appears that no matter what I do I cannot get it to only trigger once per frame, even calling InputSystem.Update() manually. I am also testing which phase the event is in as per this post and it is triggering the performed event multiple times per frame.

This leads me to conclude that my original statement still holds true, cache the value and use it in Update instead. Setting a Vector2 or a float 8 times per frame is trivial.

For the record, with profiling my player script update takes 0.00ms as well as the InputSystem event processing taking 0.00ms.

Maybe @Rene-Damm can clarify more on this and tell us why it would trigger 8 times per frame.

@marcospgp

For now I’m inclined to attaching the input action asset to my input handler script and using InputActionAsset.FindAction() inside Update() to poll actions like “Look around” or “Move” once per frame.

This method is not something I found explained in the manual anywhere though - the only polling example I remember seeing is
Keyboard.current.space.wasPressedThisFrame
here.

This page does describe polling as a way of dealing with events (“You can poll the current state of an Action whenever you need it; to do this, use InputAction.ReadValue<>()”) but it doesn’t say anything about how to get a reference to the
InputAction
objects.

The first bit of code I posted is how you get that reference using the created class that matches the name of the InputActionAsset you created. It creates properties for each ActionMap that has properties for each InputAction that you can reference for convenience. PlayerInput is a wrapper around doing that, only it doesn’t need it to be a class and uses the InputActionAsset directly. You only need the class if you are not using PlayerInput.

@marcospgp

I think the manual should not focus on listening for events if that is not as efficient as polling inside Update(). And to describe polling, it should point out the
InputActionAsset.FindAction()
method.

This is completely subjective. It’s entirely dependent on the type of project. Some projects will be looking for every possible avenue to reduce frame time like VR, which will still need responsive input. Others will not care and just want it simplified because it does really matter. Unity will focus on the simple, while allowing for more customization/optimization for those searching for it. After all VR or high end graphics are not a beginner thing.

@marcospgp

I’m saddened by the lack of clarity in the documentation. It doesn’t feel like the person writing it tries to put themselves in the headspace of someone who is completely new to the system.

I agree it is lacking and difficult to find what you are looking for. That being said the system is not as hard to figure out for someone with more advanced skills or experience. In my 16+ years of programming experience this system is a god send compared to the old one. More like what Unreal has, not to compare really just that its more modern and modern programmers should be better educated or more experienced. Novice programmers/developers tend to create badly programmed games, and if Unity focuses on ease of use(artist focused) maybe that can change. Until then the programmers have to take up the slack.

@marcospgp

Still, it’s better than the current UI Toolkit documentation :p:p:p

I whole heartedly agree with you there. It isn’t a verified package though, so there is that. Then again the InputSystem is and the docs need a bit of a makeover.