Normalize Processor has no effect

I’m using the Input System (v1.0.0 in Unity 2020.1.2f1) to read input from a pedal (part of a G29 steering wheel kit). I am using path <HID::Logitech G29 Driving Force Racing Wheel>/z and this returns a value from 1.0 (when pedal is not depressed) to -1.0 (when fully depressed). I am using it as a Value / Axis.

I’d like to convert this to a value that is 0.0 when the pedal is not depressed, and 1.0 when fully depressed.

So I created an Invert Processor on my Action, and this does what I expect: -1.0 when not depressed to 1.0 when depressed.

Then, to narrow the range, I added a Normalize Processor, directly underneath the Invert, with Min set to -1, Max to 1, and Zero set to 0, however this seems to have no effect at all. I had expected it to go from 0.0 when not depressed, and 1.0 when fully depressed.

Is this intended to work the way I’ve described, or have I misunderstood something?

Putting “zero” at -1 should do the trick. The configuration of the processor isn’t super obvious.

In 1.0 the processor ended up not being public. Fixed in 1.1 where the respective setting will be in the API docs.

@Rene-Damm thank you, that worked, however I’ve noticed something a little strange.

In my case I have a second pedal (different to the one I described above) that goes from -1.0 released to 1.0 fully depressed (i.e. not inverted like the first pedal). I’ve added a Normalize Rule with: Min -1, Max 1, Zero -1. I’m using the Visualizer sample to watch the value.

What I’ve noticed is that when the pedal is exactly half-way (i.e. at 0 raw, or 0.5 normalized), the value suddenly goes to zero. If I go slightly beyond 0.5, it jumps back up to the correct value,. Same thing if slightly below 0.5. It’s like there’s a hole at 0.5. The visualizer shows this by the green bar suddenly disappearing at 0.5, then reappearing on either side.

It’s easy to hold the pedal at this point because of a deadzone (not sure where that’s implemented, but I can see it clearly in the Input Debugger).

The weird thing is that the first pedal I mentioned, with the inverted raw values, doesn’t do this. Could this be a function of the driver? Maybe a raw zero is zero plus some other metadata I can’t see that kills the control value?

I noticed this as well. I believe this is a bug in deadzone implementation as it only uses the original data, not data processed by normalization. What happens here is that deadzone overrides the normalization and sets 0 in place when the axis is near original unprocessed 0 value. This obviously fails hard when you’ve changed your -1…1 axis to map as 0…1 and the deadzone sets 0.5 to be 0 instead.

Also worth noting that for me this reproduces easily on a gamepad (tested this on xbox one controller + dualshock 4) when using the stick.

As another note, I find this current setup really confusing. Why there isn’t just some remapping processor instead where you give controls min and max and your preferred output min and max (could invert the axis with this too).

@rz_0lento interesting - I’m not actually using the deadzone Processor in my “stack” though. In fact I don’t know where the deadzone is being implemented. It’s as if the pedal is set up for rudder/flight mode, hence the mid-point deadzone, but I couldn’t find anything about this in the G29 docs or support software. And it only happens on one of the pedals (the left most “clutch” pedal). Neither the brake nor the throttle have this behaviour.

@pitchblende I bet the pedal you get that for is detected as Stick/Y which somehow gets stick deadzone applied.
You could try adding deadzone processor yourself to it and set the min value to something like 0.0000001 and max to 1. You can’t set the min to zero as then the system defaults to 0.125 or whatever is in your settings (I have another thread about this bug).

If you need something that works right now with DirectInput/HID, I’d advice to look somewhere else for the time being as current 1.0 has tons of issues, especially on HID side of things.