Additive Blending(?) Roblox Animations

Feature Requests Engine Features
#1

I was talking to @Sharksie and @0xBAADF00D and they told me to post on the dev forums and ask @CodeWriter and @zeuxcg instead.

AnimationMask.rbxl (14.7 KB)

If you open up the animation editor you’ll see 2 animations saved. “Core” and “Idle”

Core sets the figure into a T-Pose
Idle is my hypothetical idle animation

Now with this idle animation, my character will turn his left arm back 90 degrees and twitch it down

However he doesnt, AND the Idle animation overrides his right arm back downward. (I know I can disable the Arm for this animation)

But I’d rather it carried over it’s previous rotation from the lower priority and then get adjusted
Instead of being able to use 1 stock breathing animation, I have to make one for each T-Pose
Or otherwise I have to manually set the C0s myself

Because right now Animations edit some sort of second C0 property and it gets the original C0 and C1s and edits that based on the Pose that passes through
I’d like for some way to have lower level animations stick around and be able to become additive
Im not sure if this is possible with what we have right now?

Heres another example of me trying to work with this online: https://www.roblox.com/games/386064700/MoCap
Essentially whats going on here is 3 layers of animations.
At the Core level I have a basic stance. When nothing is happening my character should look like this:

I also have a breathing animation on Idle which provides some movement in the arms and torso so I don’t look like a statue.

Lastly I have Movement level animations that help adjust my aim. The aiming moves my Torso, my Head, and my Legs (so I dont have my legs floating in the air behind my character, rather I have them planted on the ground)
The system I have set up for these Movement level aim animation is an AIMUP animation that looks directly up and an AIMDOWN animation that looks directly down. I adjust the weight between these too animations as I adjust my Pitch so:
Up is 1,0
Down is 0, 1
Middle 0.5, 0.5

When its all said and done, this is how I look like

Notice my arms are pointing downward due to my idle animation.

The issue I’m seeing is that Priorities seem useless. A Core vs Core (with a weight = 0.1) is the same as Core vs Action (with a weight = 0.1) If Weight exists and lower level Priorities are simply overwritten, why do we have Priorities. To me, with the naming of the Priorities as they are, it seems to suggest that these animations blend together with an additive effect however this is not the case. Instead of a foundation based animation system where Core animations set the tone and everything is offset from the bottom -> up; we get a waterfall type of sorting where animations simply override each other starting from Action -> Core.

Sorry for the rant however I’m not sure how Animations like this should be done. I know I can manually set C0s and C1s for different poses and lerp my C0s so I can still breathing over my animations however I feel like there should be an easier way.

5 Likes
#2

I believe this requires special support we don’t have.

Canonically, imagine you have a breathing animation B, and a walking animation W. You have to use math like this:

W + (B - A) * k

Where A is the pose you made breathing for - for example, if you use our standard joint setup you could just make breathing animation in the “still” position and A=0, but if you use a setup where angles are 0 in T-pose, you either have to animate “breathing” in T-pose (which is usually painful) or have A=standing, B=standing+breathing.

Anyway, our current setup does not allow for this. It’s not all that hard to implement if A=0 - this could literally be as simple as “blend mode” enum on the animation object.

The reason priorities don’t work that way is that you usually don’t want this for priorities - for example, the common use for Action priority is to animate some bones in a predictable fashion - let’s say you have a sword swinging animation, you don’t want it to be additively blended over whatever the arm rotation happens to be when the animation starts.

1 Like
#3

So is it an issue of it being too complicated to implement or too complicated to use?

#4

It depends. It’s pretty simple to implement and use if we assume all additive animations have to be authored using 0 angles as a starting point. I don’t know how well this is compatible with rig setups - our default rig has angles=0 in the “standing” pose I believe so it’s probably not too bad.

If we have to handle different rig setups we’d have to somehow handle that subtraction - in the animation editor I’m guessing - which may be a bit painful to implement properly.

1 Like
#5

“It depends. It’s pretty simple to implement and use if we assume all additive animations have to be authored using 0 angles as a starting point”
Yes this would be the idea.

“If we have to handle different rig setups we’d have to somehow handle that subtraction - in the animation editor I’m guessing - which may be a bit painful to implement properly.”
Isn’t this already the case when it comes to custom rigs with different hierarchies and naming conventions from animation to animation? I’m not sure if I’m understanding