kooinam

slots do not go away when starting a new animation halfway from an old animation.any clue?
kooinam
  • 記事: 2

Pharan

That's just how it works. Slots don't hide unless you tell them to hide in the next animation. This is sort of a feature that allows the system to combine multiple animations.

Unfortunately, the feature has the sideeffect of not assuming you that you want to start fresh and play the animation as it looks in the Editor.

If one or two images are having problems in animations, a possible solution might be to add a key to make them disappear at the start of every animation that has the problem. It can get really dirty really fast if you do a lot of swaps.

But— assuming those slot images are hidden in the setup pose— the other solution is to call SetToSetupPose in code before each possibly problematic animation which is makes working with animations cleaner, but performance doesn't scale well if you have a LOT of skeletons (and therefore Nate doesn't recommend?).
アバター
Pharan
  • 記事: 5366

Nate

アバター
Nate

Nate
  • 記事: 9730

Pharan

So, Nate, are you recommending calling Set%%%%ToSetupPose now?

It's not too bad?


Is it better than applying a "Reset Animation" (an Animation that has nothing but keys to all bone transformations in the Setup pose or some variation of it)? I'm inclined to do this so it still works with the queue system, and also so I can pear down the keys according to two or more AnimationState "bone domains" that won't affect each other.

Now that I think about it, it seems like I'm also cobbling together an Animations-as-Base-Poses system. But I do wonder about performance VS SetToSetupPose and where the difference lies.

I was musing on some other solutions for this problem if you wanna hear about them or something. I had to take down a thread I opened 'cause I thought you were adamant about SetToSetupPose not being ideal to call every time an animation is switched. Some things still apply though.
アバター
Pharan
  • 記事: 5366

Nate

setToSetupPose is fine to call when changing animations, which doesn't happen all that often. You could even call it every frame, it isn't free but it is unlikely to be a bottleneck in a real application.

A reset animation is also fine. It probably has slightly more overhead but it is a negligible difference.

If you have a complex app, you might want to write your reset function. Eg, maybe you want to only reset some slots and/or bones but not all.
アバター
Nate

Nate
  • 記事: 9730

Pharan

That's good to know. Thanks, Nate. (It really feels like I'm flying blind without Unity Pro's profiler to say for sure how much a thing costs. xD)

A function that selectively resets bones and slots would need a list of bones and slots to reset though (that's what I was talking about when I said "bone domains"— just sets of bones that an AnimationState has jurisdiction over).

I think it's both more flexible and sensible to keep that sort of data in the skeleton JSON as an Animation rather come up with a separate system for specifying the list. As an added bonus, I could reset to any pose I want instead of being stuck with the setup pose.

But yeah. Feels like it would prevent the 1-game-frame delay if I just made myself a reset function to do an immediate resetanimationobject.Apply() when the animation changes— or the queue dequeues— instead of squeezing that reset animation into the queue itself.
アバター
Pharan
  • 記事: 5366

Nate

The setup pose has meaning beyond just something common to reset too -- all animations are relative to it. Eg, an animation that rotates a bone 45 degrees only stores that it rotates 45 degrees. This is applied relative to the setup pose, so if the bone is at 15 degrees it rotates 15 to 15+45=60. This allows changing the setup pose to affect animations, which makes an easy way to do procedural animation (eg, aiming procedurally while applying a running animation). I remember at one point we looked at the worthiness of having multiple setup poses. I don't remember the details of the discussion, only that we chose not to do it. :)
アバター
Nate

Nate
  • 記事: 9730

Pharan

Ah, right. I was aware of that part. (and I saw the actual formulas in the code where transforms get applied. pretty basic, but hard core. lol) Always good to review.
I certainly don't argue against the single "official" setup pose being a good design choice especially with regard to the animations being relative to it.

My idea was just that the modified AnimationState's reset function could just apply a custom reset pose that's specified in the Editor (the pose is saved as a regular animation but one that only has keys at time 0).
アバター
Pharan
  • 記事: 5366

Søren

One thing we talked about a couple of times was the ability to have multiple setup poses, so you could choose which one to use for specific animations. However this unfortunately complicates the runtime.
アバター
Søren

Shiu
  • 記事: 2396

Pharan

Haha. Just to be clear, I wasn't recommending or requesting any official changes. This all works with how Spine is set up right now. Less than a dozen extra lines of code in the runtime to support it, which I've already done. Just sharing what I'm doing.
アバター
Pharan
  • 記事: 5366


Return to Runtimes