• Editor
  • Its possible Key all the Slots in One Frame?

Hi all!

I'm animating several characters for a video game. Each one has several expressions for the eyes and mouth, and 3q and back views.

This means that, when there is an animation change , there is quite chance that the character have the eye closed all next animation, or he forget to close the mouth

Is there a quick way to put a key in all slots of the first frame of each animation?

This would solve my problems

Related Discussions
...

You can call setSlotsToSetupPose() at runtime when you change animations, or otherwise use skeleton setAttachment. In the editor there is a hotkey for keying SRT on all selected bones, but nothing for slots. Generally you want to use as few keys as possible to reduce the work that needs to be done at runtime, so setting a key for every slot wouldn't be great.

In this context, could it be a feature to flag an animation to start fresh from setup pose? (maybe separately for slots and transforms?)

Otherwise, yeah, I agree an editor shortcut to key all slots (or more flexibly, key all selected bones' descendant slots) would be useful. Right now, I key certain slots at the start of every animation to make sure I don't accidentally inherit incompatible slot states from the previous animation.

The workaround I've been using is this: I have a dummy animation with nothing but slot keys for slots that I never want to inherit from previous animations, and just copy keys from that to any actual animations i need to make/use.

I have also had this problem with image switching.

I use the animation state to change animations, and the first animation has a key for changing an image, but the second animation doesn't. Then the second animation will start without changing the image back to default. I easily fixed this by keying the correct image in the second animation, but it was a little weird to find out what was happening.

Pharan a écrit

In this context, could it be a feature to flag an animation to start fresh from setup pose? (maybe separately for slots and transforms?)

It could be, though it is easily handled at runtime. Also, it would only work for the simple case where all animations start from the set pose. As soon as you only want to reset some slots (eg you have a weapon, armor, etc equipped) you are back to needing to handle it at runtime. Probably it is best to just handle it at runtime in all cases. I don't think keying all slots at animation start is a great solution. A hotkey to do that would just lead to it being used.

Scrapping the idea of resetting ALL slots;

It's undeniably necessary to make sure SOME slots begin as they're defined in the setup pose, or begin in a certain way by being keyed at the start of all relevant animations that might follow a previous animation that modified that slot, or for slots to change back to their original state when the animation is done (especially ambiguous if the animation is cancellable).

For this purpose, I'm inclined to ask for a shortcut to key the images of all descendant slots of a selection of bones. This is so it's at least easy to ensure that certain slots in certain animations will begin reliably. (also bypassing the need to use the tree for this, because navigating and doing things through the tree shouldn't be necessary.)

Is there a better solution or feature to support this necessity?

Maybe a flag that marks a slot to return to setup pose when the animation switches out.

I think it would be semantically correct to keep information like this inside the animation/json (ie, "this is how this body part should start off in this animation regardless of what animation came before it", or "this image change is only for this specific part of this animation. it shouldn't carry over to any animation that follows it.") and not be something that has to be implemented and handled per slot and condition in the code.

I imagine a workaround where there's an animation with nothing but slot image keys, but I think it wouldn't play nice with the queue system as it is.

Something could be done, I'm just not sure it will end up as only a partial solution. If I'm adding features, I like ones that are really solid. Lots of other things to do at the moment. 🙂

Right, just putting it out there since it's a pretty common problem.
Just need to get the conversation going with other users too.

Can't expect a half-baked solution especially if it has the potential to affect the spec profoundly.