The curve based animation format actually supports that kind of thing more naturally: Since curves are the main primitives in the new system, and those curves contain keyframes, the workflow that you’re talking about will actually be simpler. You’ll just be able to ask for the interpolated value at a given time right on the curve instance rather than having to do busywork yourself to figure out the interpolated value by looking at keyframes.
I’m a bit confused in terms of how curves will be implemented in the future - will current animations automatically convert to the new system, too? If not, then would I need to handle cases for both “legacy” animations & curve-based ones?
As you can see in the API dump there’s now a common base class AnimationClip
, that both KeyframeSequence
and the new CurveAnimation
inherit from. Basically, on the Animation / Animator side things won’t change, but on the definition side, the animation may be backed by either an old style KeyframeSequence, or new style CurveAnimation (and you may have to use a CurveAnimation to get access to new animation features that KeyframeSequence doesn’t support).
Hey @tnavarts, will Blender ever be built in as like a tool to import & export animations from there and into there? It’d be nice and it’d lessen the hassle of having to get a seperate plugin. Thanks!
I cannot do bug reports, but what I am trying to say is that when you change the frame rate it does not do anything to the speed. I’m not sure if this is intentional or not but it could be a bug
That is intentional. There is a new speed function in the editor. It is not saved, so if you want a different speed, you need to remember that speed and code it later, OR you edit the times manually. See this post:
We intend to support both formats in the AnimationClipEditor. Existing animations (KeyframeSequences) will not be automatically converted to the new system and you will still be able to work with them as you do today. However, there will be an option to promote an existing KFS animation to a curve-based animation.
Third time asking this question. Can I get an answer?
Hey @STRAWHATJOSHA, sincere apologies for the late reply … the team has been working in overdrive preparing for RDC21! Hope you will attend the conference this year
Also CC’ing @PierceMikyoto with a similar question.
We have been discussing several options to better integrate Studio with external DCC tools such as Blender and Maya. In the specific case of Blender, we can’t integrate its open source code directly into Studio because the license would force us to open source Studio as well, so any integration will likely be via plugin. At this point, there is no decision on how exactly we will do this integration, but rest assured we do want to improve this process for our developers!
Hey @sanjay2003, thanks for sharing these suggestions with us! I will bring these requests to the team: custom easing methods and custom increments to move keyframes/nodes in the editor
Hey @GolgiToad, just to clarify … you want playback speed to also be used during game play, right? Not just in the animation editor.
Also, “play animations in reverse” is a great suggestion … I will add it to our backlog so we can work on it soon
I assume open sourcing the studio might allow exploiter to find new backdoors to abuse. I do however think the studio being open source would also lead to alot good.
Id add a built in plugin into the studio. And in the plugin there could be an option to install an addon into blender.
Another idea i had was adding all the tools into the studio itself. create a tab for animation and give it all the tools that other softwares have (like blender and maya). i think it would be cool if we could do all of our work in studio alone without the need for external tools.
I would like the setting chosen for playback speed to be saved as the default speed when exported to Roblox. Right now, you can find the speed you like in editor, but then you have to go program that speed via script.
The purpose of this feature was to decouple the playback speed in the ACE from the animation speed so that it would be easier to edit fine details without having to stretch the timeline and scale it back. We probably do not want to store the playback speed as part of the asset and use that speed in the engine. There already is AnimationTrack:AdjustSpeed(…) to change the speed of an animation in a script, adding another factor to the mix would just be confusing (“I have a 5 seconds animation, with a playback speed of 0.8x, but AdjustSpeed is 2.5x, so the resulting animation is uuuh… 5 seconds times 0.8… no… wait…”).
However, the use case you mention seems valid to me. It does sound convenient to adjust the playback speed until you have the animation running at the speed you’re looking for. So I would rather suggest that we add a tool in the ACE to bake the playback speed into the animation. Using that tool would automatically scale all the keys by the current playback factor using the existing scaling method (meaning that the keys would snap according to the selected snap mode), and it would reset the playback speed to 1x.
I am (very) slightly worried that using that tool repeatedly on the same animation might degrade its quality. Every time we scale keys, we have to align them (either to the selected frame rate, or to the internal timestamp frequency if no snapping is enabled), and aligning keys means that they might be slightly moved earlier or later than where they should theoretically be. Scaling once or twice will not be noticeable, but abusing this tool could eventually result in a poorer animation, not unlike saving a JPEG file over and over and over again.
We will discuss this more internally and see what we can do!
In my head, I pictured the playback speed and adjust speed being the same variable. You could change it to 2.5, but it’s not multiplicative. If I have a part that has a default color of red, and I change it to blue, the engine does not hand me purple. 1.0 is AdjustSpeed’s “Medium Stone Gray.”
I’ve already run into the baking issue before, but I suspect that happened at export from blender. My blinking horse ended up in an animated state where no frame fully closed the eyes.
I suspect the biggest problem we will face while baking is that blender imported animations already exports too many frames, and all bones. I’ve confirmed this is an outstanding bug on blender. This is what the incorrectly imported horse animation looks like (only 2 eyelids are animated, once a second, and not even those frames are right!).
I don’t know what the key frames actually are, how will Roblox? When I finally do get around to cleaning this one up, it would be fairly important that detail is not lost in baking.
Oh I see what you mean. You would like the ACE to store the playback speed, so that when the engine opens the animation it sets its internal speed (the one usually affected by AdjustSpeed) to the speed coming from the asset rather than the default 1x.
That makes sense, but the concern would then be that you might forget to reset the playback speed to 1x before saving the animation (you make some changes, you slow down the animation to check one last detail, it looks good, and you save the animation without changing the speed back to 1x).
We intentionally designed the playback speed to be decoupled from the animation for that reason (and some others ).
Hey! I know this is a bit off-topic, but if possible, could I receive clarification on how fade times work with AnimationTrack
's ::Stop
and ::Play
methods? I’m working on calculating CFrames of a player’s limbs just from the keyframe data alone, and I’ve run into an issue where all my math becomes very off due to the fact that I don’t take into account for poses fading into each other.
All my animations have Weight values of 1 which should hopefully simplify things, but I still don’t understand how I’d go about taking into account for it all.
If anyone could shed some light on this, I would be super thankful!
To clarify: I’ve read the API, and this is the most meaningful information I could find:
The pose that is shown at any point in time is determined by the weighted average of all the
Pose
s and the WeightCurrent of eachAnimationTrack
I’m confused here - what does “weighted average of all the poses” mean?
How would you get an average CFrame from the poses? And would it be the average from all the poses in whole the track, or just the two neighboring poses that are currently playing?
If it’s the latter, does the AnimationTrack
object pause at it’s current poses the moment Stop
is called?
Sorry for so many questions, this is just very critical to continue development for my game, and I’m a layman in regards to math, so this is all a bit confusing to me.
If there are no plans on fixing the easing direction, would it be possible to reverse the easing direction in just the animation editor?
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.