[4.0.20-beta] Multi-/box-select keyframes in new v4 Graph?

Friebel

Trying out the new Graph/Curve Editor in v4 I'm missing a box-select with Ctrl+drag (Windows), just like in the Viewport and the Dopesheet. Am I missing something or is it not yet implemented?

Nate

It's coming in the next version, 4.0.21-beta.

There is some info about the beta and a video that takes you through the basics here:
Blog: Spine v4-beta: it has a curve editor!

Friebel

Nate schrieb
It's coming in the next version, 4.0.21-beta.

There is some info about the beta and a video that takes you through the basics here:
Blog: Spine v4-beta: it has a curve editor!

Thanks. I've seen that video, very helpful.
There is a mistake in the video though: the voice over is consistently confusing ease IN and ease OUT. Around 7:15 he is talking about ease OUT, while he is showing an ease IN. And after that he says ease IN, while explaining ease OUT.
A curve always goes from IN to OUT, not the other way.

So ease IN is slowly at the start, faster at the end and ease OUT directly starts and is slow at the end. An Ease-In-Out both starts and ends slowly and is fast in the middle. It works like that in all animation software I know of, including js-libs, CSS, Greensock, After Effects, broadcast video editing etc.

I think it is too important to not mention this here. Please use the right terms in videos as for beginners watching this video and never worked with easing before, with this video they learn it the wrong way causing confusing and miscommunication with others when actually using it in real life.
He says it so many times consistently wrong in this little tutorial that I would advise you guys to re-record the video with the right terms to prevent beginners learning it the wrong way. It's hard to correct when learned wrong and used for years.

Nate

Friebel schrieb
ease IN is slowly at the start, faster at the end and ease OUT directly starts and is slow at the end

I don't think this is quite right. First, these terms are applied to the transition between two poses. We transition "out" of the first pose and "in" to the second pose. Next, "ease" means to move more slowly. When you "ease out", the transition starts slowly from the first pose (compared to the speed later in the transition). When you "ease in" you move slowly into the second pose. Note that you can have a transition that eases out and also eases in.

I agree it's important and it's one of the 12 basic principles. Here's an image from the Animation Survival Kit that helps visualize it:
Loading Image

I think the terms "slow out" and "slow in" are a bit better, and they match "fast out" and "fast in".

Friebel

Nate schrieb
...

Interesting. You're right, there seems to be two camps. Just found this article having the same confusion:
https://medium.com/@gordonnl/ease-in-or-ease-out-ed9a0969042e

It looks like the difference between the two camps is

A sees it from the perspective of curves/movement

IN is left, OUT is right (Google, CSS, Greensock, developers ...)

B sees it from the perspective of keyframes/poses

OUT is left, IN is right (so the complete opposite) (Premiere fades, 12 princ. ...)

What I know for a fact is that all Javascript animation frameworks and CSS I used last years all work with IN at the start of a curve and OUT at the end of the curve. And animations are curve-focussed (type A).

Just take a look here for Greensock (most used animation lib there is on js):
Type A: Ease-In is slow at start
https://greensock.com/ease-visualizer/

Threejs (most used 3D lib for the web)
Type A: Ease-In is slow at start
http://learningthreejs.com/data/tweenjs_for_smooth_animation/tweenjs_for_smooth_animation.html

EaselJs/CreateJs (output of AnimateCC, former Flash, for HTML5)
Used as renderer for games on the web and output by Animate CC when building for HTML5.
Type A: Ease-In is slow at start

Here for CSS
Type A: Ease-In is slow at start
https://css-tricks.com/ease-out-in-ease-in-out/
https://easings.net/

Google Developers about UI animations
Type A: Ease-In is slow at start
https://developers.google.com/web/fundamentals/design-and-ux/animations/the-basics-of-easing

Flash Actionscript 3
Type A: Ease-In is slow at start
https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fl/transitions/easing/Strong.html

Phaser game lib
Type A: Ease-In is slow at start

Robbert Penner's easing equasions
Ported by developers to several programming languages and used inside animation libs.
Type A: Ease-In is slow at start
https://www.pinterest.com/pin/69454019234740420/

Broadcast graphics
Working for years with several graphics software programs (2d/3d from titles to full virtual sets) for broadcast industry (television, like game shows and sports), I've always seen and used type A in both editors and APIs.

Figma design software (UI with animations)
Type A: Ease-In is slow at start
https://uxdesign.cc/figma-5-ways-to-add-animation-to-your-designs-e3c521aa8902

Some random tutorials on UI/internet/games animation
Type A: Ease-In is slow at start
https://medium.com/motion-in-interaction/animation-principles-in-ui-design-understanding-easing-bea05243fe3
https://blazinggames.blogspot.com/2018/02/the-key-to-animation.html

But...

To my surprise I now see Premiere is not in camp A, but in camp B:
They look at it from a keyframe focussed way: LEAVING a keyframe (OUT) or ARRIVING at a keyframe (IN)

After Effects
Looks like After Effects is also in Camp B, just like Premiere.
https://helpx.adobe.com/after-effects/user-guide.html/after-effects/using/speed.ug.html#:~:text=Do%20one%20of%20the%20following,coming%20out%20of%20selected%20keyframes).

I just looked in DaVinci Resolve and they don't seem to use the terms, but only show icons of curves as far as I see it now.

conclusion for me
If I were to write animation-software that's extensively used for code, used by developers and used for internet and games, like Spine, I would choose for method A without a doubt, so IN is left and OUT is right of the curve, so focus on curves. Next to that I think it's most logical to think in curves, as that's at least how my brain works (my brain sees curves/movement and uses keyframes/poses to get those curves/movement), I think it's also best to stick with what other big companies and technologies in that market have chosen:
Google, CSS, Greensock, gamelibs, flash/as3, threejs, createjs etc. all chose type A (perspective on curves, IN is left, OUT is right) and the developer world seems to have chosen the same in general. I think that's the market Spine is in so to me that would be the obvious choice to go with.

Especially because when working with both Spine and Javascript or other animation code libs together it's very confusing to use both systems together. We want to have one universal way of using the terms and developer-world seems to have chosen type A. Otherwise when animating one thing of the project with Greensock and than animating with Spine in the same project would be confusing.

Another reason to chose type A: We always first say ease-in and than ease-out when we say both so it makes sense ease-in is left and ease-out is right.
I see that's also happening in toonboom (I don't own the software, but see it on their page). So it looks like they work curve-focussed too (type A):
https://learn.toonboom.com/modules/animatic-animation/topic/adding-ease-in-and-ease-out-to-a-layer-animation

Switching to terms like 'slow out' and 'slow in' doesn't solve this issue, as it's still using IN and OUT, and that's where the confusion is. Also, an ease-in can also be elastic or bounce and that has nothing to do with slow or fast.

Nate schrieb
Friebel schrieb
ease IN is slowly at the start, faster at the end and ease OUT directly starts and is slow at the end
Note that you can have a transition that eases out and also eases in.

Yes, I understand. Then the curve has an ease-in-out. Or in libs like Greensock or EaselJs could be things like ease.backInOut or ease.cubicInOut.

Nate

Interesting research!

To restate what you wrote, in/out can be interpreted as:
A) Transition-centric: "in" means the start of the transition and "out" means the end. You'd say you are going slow/fast into or out of the transition.
B) Pose-centric: "out" means the part of the transition near the first pose and "in" means near the second pose. You'd say you are easing out of the first pose or into the second pose.

Friebel schrieb
animations are curve-focussed (type A)

Not sure this is definitive, since it could easily be said animation is pose-focused.

Friebel schrieb
when working with both Spine and Javascript or other animation code libs together it's very confusing to use both systems together.

Note the only place Spine uses in/out is in the graph video and likely in the upcoming tutorial video series. It's not found in the UI, API, or documentation.

For me, using Spine is primarily about animating and that the Animation Survival Kit and 12 principles are pose-centric indicates that is probably the way animation software should use the terms. I would not copy what other software uses since there is no insight into why they made such a decision. There can be value in matching what everyone is doing, but if it's a split then it's better for us to be correct than popular. I can see it being easier for tools/libraries that have no concept of poses to confuse the terms.

Siniša, who voiced the video, surely has some input. He's a professional animator with a lot of experience and I defer to him for this decision. Let's see what he thinks on Monday.

Either way the most important thing is to be consistent to avoid (further) confusion. It wouldn't make sense to use the terms when talking about poses, then use the same terms for the reverse meaning when talking about transitions/curves.

Sinisa

Hello Friebel, let me clear the confusion,

Friebel schrieb
There is a mistake in the video though: the voice over is consistently confusing ease IN and ease OUT. Around 7:15 he is talking about ease OUT, while he is showing an ease IN. And after that he says ease IN, while explaining ease OUT.
A curve always goes from IN to OUT, not the other way.

There is no mistake here, the video and the content were carefully thought out to give the users the best info about the Graph and animation jargon.

Friebel schrieb
I think it is too important to not mention this here. Please use the right terms in videos as for beginners watching this video and never worked with easing before, with this video they learn it the wrong way causing confusing and miscommunication with others when actually using it in real life.
He says it so many times consistently wrong in this little tutorial that I would advise you guys to re-record the video with the right terms to prevent beginners learning it the wrong way. It's hard to correct when learned wrong and used for years.

I can understand the confusion, for that reason I specifically showed what is fast/slow out and fast/slow in, as I noticed for years people are getting confused with basically a very simple topic. That's why this video is perfect to learn the right way.

To put things in perspective, the term slow out/in (or ease out/in) was created by Disney's nine old men, and it's one of the 12 basic animation principles. They were created in the 1930s, so that was around the time Alan Turing presented the notion of a universal machine. It basically means that you slow out of the pose/drawing or slow in to a pose/drawing. I understand that is the opposite of the code but it's a term animators were using for years before code was even invented and still use to this day, so it would be actually a mistake to teach the other way around.

Friebel schrieb
If I were to write animation-software that's extensively used for code, used by developers and used for internet and games, like Spine, I would choose for method A without a doubt, so IN is left and OUT is right of the curve, so focus on curves.

Animation software is made to be used by animators. Animators do not care how the stuff is called in code, as we will probably never look at it.

Friebel schrieb
Google, CSS, Greensock, gamelibs, flash/as3, threejs, createjs etc. all chose type A (perspective on curves, IN is left, OUT is right) and the developer world seems to have chosen the same in general.

Again, the code is not in the focus here, the art of animation is. I will continue to teach the animation theory the same way I was taught by Disney, PIXAR, Valve, Weta, etc animators. All my lectures and videos are based on the lectures I received from them over the years.

Friebel

Sinisa schrieb
Hello Friebel, let me clear the confusion

I don't think there is any confusion, but a difference of opinion. I see where you're coming from and it's absolutely great you've been taught by the companies you've mentioned and you are absolutely right to be proud about it. I know I would.

That said, I have a background and years of professional experience too, but guess it's pointless in pointing that out and I don't feel like doing that either. For me it seems difficult to reach and convince you, because if my last extensive post based on factual information about the industry Spine is in wasn't convincing, it will never be. I'm a little dissapointed by that and was hoping for a little more open mind and realistic look at the real market Spine is in. But it's completely up to you and your choice of course.

You seem to divide people into Animators and Developers though and you practically wrote you don't care about code. I'm very surprised about that and it felt degrading to developers.

Me, for instance, am both an experienced senior Animator/Illustrator/Designer and a Developer. And in the country where I live in and the professional work I did for both tv-graphics-software and internet in our country and abroad for many years, that combination is no exception at all. I'm sure the same counts for the game industry here. It even has a great adventage if you can do both. I don't know you at all, you are probably a very great guy and knows your job well, I don't doubt that, but your post comes across as if you look down on developers as an animator and I don't get that. Like in your world users of Spine don't think about code and should be 'pure animators', if that only exists, even though Spine is made for runtimes in games in the first place, so there are all kinds of users. I don't get that perspective.

Or that every programmer doesn't care or doesn't know a thing about animation. Like the book about animation. I really think in 2020 there are very very little people doing even the slightest thing in animation nowadays that never heard of that book or at least the 12 principles. Also UX/UI designers practise those rules in software- and webdesign nowadays.

To me it comes across as short-sighted, even a little arrogant to me. Maybe you didn't mean it that way, but that's what it feels like to me. I hope you could see Spine wasn't meant for video in the first place, but for the runtimes. That's at least what Esoteric always advertised with: games. And games are all about development meeting design, so there are all kinds of users using Spine, everywhere on that range.

Your post also gave me the strong feeling you skipped all my concrete examples of actual tools and market leaders of animation software in the world Spine is in and actual real life uses cases of animation used for internet and games Spine is made for upfront.

I get it that it's difficult to embrace another opinion about something we learned and used for so long. We all been there at one point. But I was hoping for a little more open mind.

I'm a little dissapointed by your answer, but let's just agree to dissagree, and I believe I was also a little harsh about it in my post, so can't blame you really. And Nate is right, it's only in the video's not in the UI, so that's cool.

But please, no more dividing upfront: animators are cool, illustrators and designers are cool, developers are cool! And they come in all sizes and mixes between the three :smirk:

Nate

Friebel schrieb
You seem to divide people into Animators and Developers though and you practically wrote you don't care about code. I'm very surprised about that and it felt degrading to developers.

I feel you are reading too much into Sinisa's post. He is an animator and was speaking from an animators perspective. An animator really does not care about code, not out of disdain but because they are never going to read or write code, look at APIs, etc.

Overall Spine of course cares about both, provides APIs, and programming is a big part of Spine's workflows. However, the animator relevant parts of Spine are separate from the programmer parts, even if in some cases the same person is doing both. It makes sense to use animation terms in the animator relevant parts rather than adjusting the terms based on the programmer parts. The Animator's Survival Guide, Sinisa's extensive education in animation and real world experience as an animator, and other sources indicate that the terms in the animation domain are used in the pose-centric form, so it makes sense to use that for the animator relevant parts of Spine.

Your research is really interesting and shows there is widespread confusion surrounding the terms. As Sinisa mentioned, they were originally animation terms using the pose-centric form and were later reused with the opposite meaning for other, if related, purposes. It could easily be argued that was a poor choice and different terms should have been used rather than muddling the animation terms.

The pose-centric terms are still in use in the animating world and it's unlikely the opposite usage will cease, so there is always going to be confusion, no matter which we choose. Given that, we feel the pose-centric/animation focused terms are appropriate for Spine. As I mentioned, the terms are not used in Spine itself, nor in the documentation. They are only used in the tutorial videos which are teaching both animation theory and how to animate using Spine. It would not make sense to teach animation theory using the opposite meaning for animation terms. That is probably the most important point.

Friebel schrieb
I really think in 2020 there are very very little people doing even the slightest thing in animation nowadays that never heard of that book or at least the 12 principles.

That book and the 12 principles are the animation bible. I would go so far to say that any serious animator is very familiar with both and if they aren't, they should be.

Friebel schrieb
Your post also gave me the strong feeling you skipped all my concrete examples of actual tools and market leaders of animation software in the world Spine is in and actual real life uses cases of animation used for internet and games Spine is made for upfront.

Not at all and I specifically addressed that:

Nate schrieb
I would not copy what other software uses since there is no insight into why they made such a decision. There can be value in matching what everyone is doing, but if it's a split then it's better for us to be correct than popular.

We try very hard not to make decisions solely because other software does so. We strive to make decisions based on relevant considerations so we can better innovate and improve things. As one example, Spine does not have right click context menus (because discoverability is poor and tend to become junk drawers) and that has worked out quite well, despite being maybe the only software to avoid them.

Friebel schrieb
I get it that it's difficult to embrace another opinion about something we learned and used for so long. We all been there at one point. But I was hoping for a little more open mind.

I can't see how you can come to this conclusion when we have provided extensive reasoning for our decisions.