Please state examples and I’ll refresh the table.
improved blending is one thing, not to mention that maskweight didn’t really do anything
How exactly has the blending improved?
Ye, it looks wierd cause maskweights being removed isn’t a bad thing. But it wouldn’t be fair to leave that out of the table thats why it’s there. It’s not really a negative part tho.
The table is pretty misleading if you just put it like that. MaskWeight is not relevant since it never really worked according to zeuxcg. The “Logical percentage of weights” line is mostly opinionated, I prefer how the new system does it. The “Replay animation without interference” line is misleading as well. For the new animations, this just requires you to properly code the animations. The old animations let you get away with improperly handling animations, although it never should have. (i.e. not stopping them when you don’t want them to influence the rig)
2 Likes
It might seem biased but really coding a weight above 1 is not logical. I’d even have to claim that those who wants to code weights above 100% are the ones doing it wrong.
It’s called force optimization. Something newbies (and vets alike) will have a hard time appreciating since it won’t improve their performance (given it’s already very low on cpu usage) but will cause mayham on their coding structure.
I must claim to differ. Playing a Jump animation when someone jumps without stopping the idle and walk animation is not improper, it’s very easy and good coding and it’s not going to burn your cpu alive.
If you code everything w.r.t a sum of weights of 1, then it means all of your priorities are static. In other words, if I play 2 animations of weight 0.5, then if I want to play another animation beside it I would have to change the priorities of all other animations before I can play the third one (without causing weird results). In the new system the priorities of individual animations are constantly shifting because the sum of weights is not the same all the time. This allows for more flexibility.
I don’t agree with the other two remarks you make, I think you can code it in a clean way, but I don’t really have an example to support that so I rest my case there
It’s not yet (but also see the rest of the thread - the old blending behavior may be coming back…).
To help me understand the possible use cases - how exactly did you need to update your game so that the behavior is different on iOS?
Make it a boolean property.
1 Like
Apparently a side-effect of this update is a bug in the animation editor that keeps animations in a weird state after the playback.
Given this and the uncertainty about the behavior the animation blending behavior will be restored (now) to better match the old one. I will update the post tomorrow to its final form.
Edit: This is done. The optimizations from the OP are partially disabled, and the blending logic has been restored. Tomorrow’s update will fix the bug and I’ll reenable the animation optimizations but this time they should not have any visible behavior changes - the blending behavior has been restored to the old one and stays that way.
8 Likes
Wow, just one minute before I was going to post something about the animation editor being broke.
hahahahaha no wonder all my stuff was broken even with the right coding
My anim studio works properly again
=)