- 수정됨
Framerate editing
Hello everybody,
Being a professional animator myself I find Spine very efficient for animation. However I think there is not enough control on the framerate.
For example, I am currently working on a personal project where I need some kind of traditional animation feeling with a low framerate like 12 fps.
On Maya, once I am done with my "splining", I usually bake my animation. What it does is that it creates a key every X frames and convert all the keys in stepped. At the end of the day I have a 12 fps animation out of my 24 fps animation, and it has this kind of traditional animation feeling. But in Spine, as the default framerate is 30 and cannot be changed, and as there is no baking feature, I need to manually create a key every 3 frames to have a low framerate animation, and still this is not 12 but 10 fps.
I think it would be great to be able to change the default framerate of Spine if that is possible. Else, to create some kind of snap grid in the dropsheets that helps you putting your keys every X frames (every 2.5 frames in this case) or a bake keys feature like in Maya. I have seen this feature in Spriter and this is quite convenient, even if Spriter is much less convenient to animate overall.
I already checked the playback features but this is not what I am looking for. In theory it would do the trick by applying a 0.4 speed rate to the animation and taking off the interpolated option, but the thing is that then when I am exporting it for Construct 2 this is not understood by the plugin I am using. So I need to have a 30fps animation with step curves to cheat it and make it believe this is 10 fps.
Does anybody else think that such a feature would make sense ? or if maybe I can already do what I want another way ? do I make sense ?
Thank you very much.
Few key things you need to understand:
(1) Realtime 3D animation (as opposed to prerendered 3D animation) doesn't have an actual "framerate". Everything is interpolated in conceptually continuous time— sliced arbitrarily by the update rate of the engine; The framerate you see is however quickly your computer can update. For the average computer-user, and at reasonable detail levels, that's actually around 60fps.
Spine rests on a similar paradigm and, in game engines, piggybacks on the same systems.
(2) The "framerate" you see is only as a user of Spine editor. The timeline has lines, numbers and snapping so it feels like you're animating at 30fps. 30 is currently locked as the one-second mark. In fact, it should probably say "1 second" and not 30, because when it's saved, the keyframe time values as saved as seconds and not frames.
But, you're right. There is such a thing as stepped. And no, that probably wouldn't be the best way to go about it.
(3) I wholeheartedly agree that professional animators trained "classically" and who work with the limitations of 8fps/12fps/24fps need to be able to work with Spine comfortably. A custom framerate purely on the timeline (being able to set frame 12 or frame 24 or frame 60 as the 1-second mark) was removed from the list of planned features many many months ago. I'm still not sure why.
Regardless of this, the keyframes will still be saved in terms of seconds, and without the proper code on the runtime side, the framerate will still play at the full capability of whatever machine, system or engine it's running on. It could be 30fps. It could be 144fps.
(4) To achieve discrete-framed animations, the runtime code can be easily modified, given that your engine also allows you access to observable time and manageable variables (or at least allows you to manage your own).
The Spine runtimes are already set up to receive customized update time deltas.
Limiting the framerate amounts to just delaying animation updates until enough time has passed (eg, 1/24 of a second, or 1/12 of a second).
And achieving discrete and predictable 12 and 24 fps poses (like you would expect in hand-drawn or pre-rendered animations) amounts to restricting the time values being passed into Spine's runtime code in discrete 1/12 or 1/24 chunks.
(5) Therefore:
On the editor side. It's a pain to animate "classically". You can't snap the keys in the correct times. And you can't preview it at the correct frame rate.
On the runtime side, because the source is editable by the game developer depending on the game's needs, you can make animations play at 12 and 24 fps. In fact, the same frame-limiting code can be used to improve performance if Spine animations are bottlenecking the performance such as when there are too many instances updating at once.
Yes, I agree that the editor feature of changing the framerate on the timeline (which affects snapping) is very useful. I think the feature makes sense, whether for animating things to have a traditional feel, or translating or combining frame-by-frame animated things with interpolated ones or achieving better pose-accuracy at high framerates, it's very, very useful.
I've been barking at this tree for a long time. And I appreciate it when people express their use cases for this.
Hello Pharan,
Thank you so much for your detailed answer. Everything makes more sense to me now.
So I kind of found a workflow to do what I want : I am working on Spine with a 0.4 speedrate (in the playback options), toggle off interpolated option. That way I have this preview of 30*0.4=12 fps animation and can accurately create a 12 fps animation.
Then, as you said, we edited the plugin's (for construct 2) runtime code so that it refresh the spine object 12 times per second regularly, whatever the actual framerate is (thanks deltatime). Then we only have to multiply the speed rate by 0.4 as well in the plugin, and the result will be exactly the same than in my Spine preview running 12 fps animation without interpolation.
However I agree that it is not very intuitive, the fact is that I am slowing down my animation in Spine so that I only have 12 keys to manage for one second. But in reality my animation has been slown down. So yea, a feature to change the amount of frames to make 1 second would be great in my opinion.
Even if at the end of the day it wouldn't change a lot for me. As you say that exporting the animation with 12 stepped keys per seconds is not the best way to make this 12 fps animation feeling, and that this is better to edit the runtime, if the feature was there I would just have to take off this 0.4 speedrate in the runtime.
May I ask you just for curiosity, why is it better to edit the runtime rather than exporting a 12 stepped keys per seconds animation ?
Anyway my problem is solved, so that's great, thanks a lot for your help !
There are a downsides to animating with 12 stepped keys per second for every item you have to animate:
DATA
Just in general, more keys means more data. More data means bigger files and slower load times.
In pre-rendered animation, this doesn't matter, because frames are just flattened into images anyway. And whatever is playing back those images doesn't care about the amount or kind of data. (But if you've watched the Spine promotional video, you'll know that pre-rendered has its downsides too.)
But for real-time animation, all that data is used in real time, which brings us to the next downside...
PERFORMANCE
More keys means more items the animation system needs to search through. I'm actually not 100% sure by how much slower it will be based on the algorithms the animation system uses (there's definitely binary search in there). But you'll be sure it won't slow down if you don't have so many unnecessary keys.
WORKFLOW
One of the obvious benefits of the typical interpolated skeletal and 3D animation nowadays is.. well.. interpolation.
That means between the first pose and the last pose, you only need to define two poses and the interpolation curve, instead of one pose per frame. Sometimes, it may be worth it to really set poses for 2 to 4 or 5 frames to get a super specific movement.
But doing it for everything, surely that'll eat up your time. And time is precious... I think.
3달 후
Pharan wroteThere are a downsides to animating with 12 stepped keys per second for every item you have to animate:
DATA
Just in general, more keys means more data. More data means bigger files and slower load times.In pre-rendered animation, this doesn't matter, because frames are just flattened into images anyway. And whatever is playing back those images doesn't care about the amount or kind of data. (But if you've watched the Spine promotional video, you'll know that pre-rendered has its downsides too.)
But for real-time animation, all that data is used in real time, which brings us to the next downside...PERFORMANCE
More keys means more items the animation system needs to search through. I'm actually not 100% sure by how much slower it will be based on the algorithms the animation system uses (there's definitely binary search in there). But you'll be sure it won't slow down if you don't have so many unnecessary keys.WORKFLOW
One of the obvious benefits of the typical interpolated skeletal and 3D animation nowadays is.. well.. interpolation.
That means between the first pose and the last pose, you only need to define two poses and the interpolation curve, instead of one pose per frame. Sometimes, it may be worth it to really set poses for 2 to 4 or 5 frames to get a super specific movement.But doing it for everything, surely that'll eat up your time. And time is precious... I think.
So,are you planning to give us the feature to change framerate in the editor ,now?
Well you actually kind of can do it if you want, with the speed rate in Spine.