Feedback On the subject AnimatorStateInfo.nameHash being obsolete.

It's been the case for a while that AnimatorStateInfo.nameHash has been marked as obsolete but I'm finally getting around to bringing this topic up.

It may be that this was marked obsolete simply to indicate to users that there are other methods for determining the name hashes, that in most cases, give better results. However, it concerns me that because this is marked obsolete it might also eventually be removed entirely. I'd like to get clarification on this as I absolutely rely on this property's functionality when dealing with nested animator states and want to know if I'm going to eventually have to stop using them.

 

I'm pretty sure it has just been split into fullNameHash and shortNameHash. Compare those two results with the nameHash. One will probably be identical, it's just that the old name was ambiguous as to which one.

 

They are not identical when using nested states. Hence the reason for my concern. It gives completely different functionality that in a few cases is actually quite useful. However, I do understand why in most cases it would not be useful and could be quite confusing if it were not marked obsolete.

 

But what can you actually do with the old property that isn't covered by the new ones? I don't use the Animator Controller system anymore, but when I did those two were all I needed to identify states.

 

The problem occurs when you are using layers in combination with sub-states. If you are checking to see what state you are in using scripts you have to either A) use the shortNameHash, which only contains the name of the state itself or B) use the fullPathHash which contain the state name plus the sub-statename plus the layer name. The old nameHash however is only the sub-state plus the state name - which is what I pretty much only ever need since I'm already specifying the layer index when querying for the current state info.

I suppose I could use strings instead of hashes but there are obvious reasons why I'd rather not.

 

Btw @SilentSin, I just checked out your Animacer asset. Been meaning to do something like that myself so you might have just saved me a bunch of time!

 

I'm actually working on an update for Animancer which I'll be releasing a beta test for in the next few days after I finish a bit more work on the new documentation. In particular it has lots of new example scenes with detailed explanations of how to use everything.

 

Hey, I just released an open beta version of Animancer v3.0 in case you want to check it out.

 

Out of curiosity, how is performance when compared to mechanim and does it generate any garbage? I was working on a hoard shooter a couple years ago and I'm thinking about dusting it off for a gamejam coming up. After optimizing the crap out of it, I found on of the biggest bottlenecks was mechanim. I was planning to write my own system that would work similar to what you have but ended up moving on the other things. Do you think there would be much overhead if I had say, several thousand animated sprites running all at once?

Wondered why my post disappeared and then I realized I had posted it in the official forum thread. Anyway, it looks great. All I can say is 'Shutup and take my money!'