I’m more worried about how they seem to be waiting for replies to close, or something. We haven’t had any updates on this at all in months, but supposedly it’s meant to be in Phase 2 and Phase 3 soon enough. I’m worried they might just be going dark until backlash can be avoided.
3 Likes
I’ve just gotten approval to add 3 additional levels to the AnimationTrack.Priority enum to address running out of priorities. While the code change is simple, this required a lot of internal discussion to make sure that what we’re adding does not complicate migration to the next major revision of the animation system (as most of you know, facial animation and other new features are coming).
We looked at all of the use cases, and determined that integer-based priorities are just not required for the existing system at this time. This does not preclude ever adding support for this, it just would have delayed this rollout even further to make such large change to the existing evaluator.
As soon as the support for the new priority levels is live, we’ll move this rollout to Phase 2 (the opt-out phase). What moving to Phase 2 means is that a Workspace.AnimationWeightedBlendFix setting of Default will become equivalent to Enabled, whereas right now it means Disabled. Any place files that are published with set to Default will automatically start using the new animation runtime (with blending fix) without further developer action. If your game currently has problems when this property is Enabled, firstly you should let us know, and secondly you should publish your game with this property set to Disabled, to ensure that it does not change before you’re ready for it.
9 Likes
While I appreciate the extra priorities, I worry that for more complicated scenarios, only 3 additional priorities may not be enough. This is still frustrating, because these new priorities, if they don’t all go above action, will actually require more work to fix than integer priorities.
If the new priorities are above action, this is a welcome change, but if they are between the other priorities, this severely complicates things, much more than necessary. It would mean having to update the same things as without the priorities, just with a tiny bit more wiggle room in that there’s a few more priorities to balance things out with.
I still really think this should be evaluated further depending on feedback once the change goes into opt-out phase before a permanent change is set into place, because if integer priorities are really that complex to add, it’s probably going to be a while before we get them once the final update is pushed, and that would make animations for morphs and other “stacking” items very tedious to work with, more-so than they already can be.
I believe releasing the update with integer priorities, necessary at the time or not, would encourage a better developer transition to the new blending mode and make updating games significantly less frustrating or time-consuming. As far as I’m aware, beyond the face animations update, not many developers have really been asking about the whereabouts of this update, aside from those concerned with the integrity of their projects, so unless the facial animation system is entirely dependent on this, I don’t see much of a problem with a delayed roll-out.
4 Likes
They are all above Action. There will be Action2, Action3, and Action4, all of which are reserved for developer use, there will not be catalog animations using any of them.
The reason this priority change is as minimal as necessary to address the stacking/blending issue is so the transition you speak of is as easy as possible both for developers, and for Roblox engineers to implement. A complex refactoring to arbitrary integers would make it more difficult to standardize the transition with a legacy-support blend node, since there would no longer be a clear convention with small, well-defined set of values. So the idea here is to add just as much support to the current animator as needed to prevent lots of animation republishing and recoding, but to let the new, more flexible system handle growing Roblox’s animation capabilities. The current system is very old and not suitable as a foundation for what’s in the pipeline: not just face animations, but runtime IK, procedural animation nodes, and other things the current system was just never designed to support.
5 Likes
Excellent. I can give this a pretty fair shot then. Although it’s not ideal, it should be enough, at least for my own smaller-scale projects. I appreciate the quick clarification.
1 Like
The animation editor is currently not allowing selection of any priority! Someone has already made a nice video of the new behavior in this thread:
2 Likes
@AllYourBlox Are there any plans for providing us with ways to seamlessly transition between animations?
This is somewhat easy to solve right now with the current weighting behaviour (simply keep animation A playing while transitioning to animation B), but my understanding is that this will not work with the new animation weighting.
“Delay between AnimationTrack:Play() being called and actual changes to the rig happening”, asset loading issues, and replicating server-side animations to clients are the main things that seem to make seamless transitions difficult.
I’ve updated my Sonic morph to respect the new animation stuff by changing the priorities for a fair few of the animations that needed it. If I find any weird bugs or inconsistencies, I’ll post them here, but for now, I’m happy to say it seems to be working fine. Thank you for these extra priorities, they’re a life-saver.
Option 1: How are we supposed to go through each animation and edit the priority? which would take even longer than Option 2?
Option 2: Doing our own replication and adjustments to weight would require a major reconstruction of our framework
which is just putting tens of hours into needless work just so our game can be viewed as intended whenever this compliance option gets deprecated
Option 3: Our animations are loaded from the client which means changing priority does not replicate to the server, which leads back to us performing a large reconstruction of our framework
We might as well scrap the thousands of hours of work with the deprecation of Enum.NewAnimationRuntimeSetting.Disabled thundering above the horizon
Being arguably forced to start from square one because of the way we’re taught to create and use animations on this platform shows an incompetent team behind ROBLOX
4 Likes
I agree that the update is frustrating. I’ll commend AllYourBlox for going through the effort of adding more priorities to make switching relatively easy, but for larger-scale projects, yeah, this is frustrating. I don’t mind the changes to animations themselves, but because of how common-place stacking animations of the same priority has become, I see it as a totally pointless change to add this new blending behavior when the blending behavior doesn’t produce any desirable results, at least not any that are in the foreseeable future. I don’t see how having two animations awkwardly combine is helpful in any way to the developer.
I still wish this behavior would be changed so that the performance increase could be applied while there was no need to drastically change what already works. Updating animations isn’t fun.
2 Likes
We’re finally moving today to Phase 2 of this rollout. What this means is default behavior of Workspace.AnimationWeightedBlendFix is becoming Enabled, rather than Disabled. If your game was affected and you have this property manually set to Disabled, it will remain opted-out for the duration of Phase 2. During this phase, you should be working on making whatever changes are needed to make your game work with the property Enabled, since Phase 3 is removal of the property, leaving it fully enabled for all places.
For blending breakage related to reliance on the stack-like behavior of same-priority animations, the simplest fix is to make use of the Action2, Action3, and Action4 AnimationPriority Enum values to override Action priority animations temporarily, as you would have previously done by simply playing another track at Action priority (which worked most of the time, though not as reliably as developers believed).
5 Likes
Has the date for Phase 3 been determined yet?
Also, if the integer animation priorities get added, how would they work with old animations? Would it just be a completely new property replacing the old Enum property, or would they take on some value depending on the Enum value? (for instance Action priority = 100 integer priority, or something) Will we need to resave our animations again… ?
Can we expect to see this issue fixed soon? I have a lot of animations with a marker on the last frame of an non-looped animation that does not get detected like YosemiteMe and Entelogical also reported in this thread.
2 Likes
The ability to disable this blending mode should not be deprecated for any reason. Massive projects with hundreds of animations do not have time to update each animation, and the animation blending simply does not look good. This is a disappointing update.
17 Likes
Honestly, I get the feeling it’s not really being done for the benefits right now, but probably to prepare for stuff in the future like facial animations and that sort of thing.
I honestly agree that it’s disappointing as it is now, but I don’t think it’s going to be preventable at this point.
3 Likes
This update is just totally disappointing since we all know how much games has tons of animations and this update is breaking every single animation on all the games. Many people doesn’t have the time to update each animation one per one because of this. Plus as TheLamentedStar said, it doesn’t look that good.
11 Likes
Has Phase 2 even been tested at ALL before release? Hundreds, probably thousands of games animations are currently broken (including mine) now due to this update, and will probably be permanently broken if they push the Phase 3 update.
Absolutely disappointed, hopefully, they at least keep an option to disable this as to save developers mountainous amounts of hours of having to reanimate everything.
13 Likes
Exactly, this bug is insanely bad my players are complaining heavily. roblox should revert this
1 Like
The new engine for sure will help out in more new/modern game development or further in-depth animation, but as multiple older animation-heavy games rely on overlapping animation tracks (with some even having more than half a hundred of them) there’s no real reason to force this blending feature onto these games with the amount of time it may take to manually multi-step patch fixed animations into their own game. At that point just allow developers to turn off the blending so they won’t have to deal with such a potentially long process.
7 Likes
i made a topic about that problem and then 4-5 people were messaging me with the same response.
im tired of roblox doing this without an option
2 Likes