Hysteresis

re: Hysteresis

trayle — Tue, 24 Apr 2007 17:15:21 GMT

Now you are talking my language. I am an engineer, although not a control theory expert. Your post made me wonder, how much control theory is used in the gaming field currently?

re: Hysteresis

GregGorman — Tue, 24 Apr 2007 17:58:05 GMT

Your idea makes sense but the implementation doesn't.

Say threshold = .7

const float hysteresisAmount = 0.1;

if (inputValue > threshold + hysteresisAmount)

All you've done here is move the threshold to .8 so now the gamer holds the joystick at that point and still catches the break between two animations.

To work like your example of a thermostat, you 'd have to modify the inputValue to something greater than your threshold. As gamers generally don't like their input being modified that's probably not a good idea.

The only way I see to handle the problem your suggesting is to do a moving average of the input value and test to see if that is greater than the threshold.

re: Hysteresis

GregGorman — Tue, 24 Apr 2007 19:57:15 GMT

Doh! It might help if made sure I understood what Hysteresis was first. Then I would have seen more in your code than I did. The implementation can't be reduced to one line like I did.

re: Hysteresis

zombiecrusher — Tue, 24 Apr 2007 20:52:07 GMT

Hah, I was going to call you on that, but you beat me to it. :P

re: Hysteresis

trayle — Wed, 25 Apr 2007 04:09:44 GMT

Ah but Greg and Zombie you have missed the point. If you hold the input at 0.79-0.81 it will only run the DoSomething() function until you get an input lower than 0.6. So you don't get a situation where your bouncing back and forth between DoSomething() and OtherThing(). If the input is bouncing between 0.79 and 0.81 there is no transition.

re: Hysteresis

GregGorman — Wed, 25 Apr 2007 22:30:29 GMT

Thanks Trayle. I saw that after I actually went to wikipedia and looked up hysteresis. On my initial read through of the sample code I effectively reduced the algorithm to one line - which doesn't work with this implementation.

Still another idea to achieve the same effect is to use a moving average of the input. The moving average would add the element of time into the calculation in much the same was as the hysteresis value. A moving average seems to be a slightly more complex solution though.

re: Hysteresis

blargg — Wed, 02 May 2007 06:45:57 GMT

The implementation shown doesn't clearly show that there was some hidden state added, that of the current action being performed. At first I also thought it wasn't demonstrating hysteresis. Without it, the action can be determined by the current input alone; with it, the previous action must also be taken into account. Here's another implementation that seems more direct to me (with concrete values for clarity):

[code]static float threshold = 0.5;

if ( input < threshold )

{

threshold = 0.6;

below();

}

else

{

threshold = 0.4;

above();

}[/code]

re: Hysteresis

ShawnHargreaves — Wed, 02 May 2007 07:06:15 GMT

This bit seems like a pretty clear persistence of existing state to me:

else

KeepOnDoingWhateverYouAlreadyAre();

Blog on Game programming with the XNA Framework

Walter Stiers - Academic Relations Team (BeLux) — Fri, 04 May 2007 10:05:36 GMT

Shawn Hargreaves Blog announces the release of the Game State Management sample . His blog entry on Transitions

re: Hysteresis

required — Sat, 29 Aug 2009 05:38:46 GMT

Interessting, i will remember this!

But your water heater example reminded me of a documentation video i saw about F-16's (Airplane) it has such an unstable non-aerodynamic form that only a computer can keep it in the air by chaning the position of the wings(the little things that go up and down at the end of a wing) all the time! The pilot's motion are then added to that. That way the whole thing stays stable... hmmm...