Ease in/out function on keyframes

Discuss Moho bugs (or suspected bugs) with other users. To report bugs to Smith Micro, please visit support.smithmicro.com

Moderators: Fahim, Distinct Sun, Víctor Paredes, erey, Belgarath, slowtiger

User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Ease in/out function on keyframes

Post by Rhoel » Thu Jan 05, 2006 5:24 pm

Sorry to be the bearer of bad news but I think I have found a mathmatical error in the keyframe options. I was doodling a bouncing ball test over New Year - and discovered that I couldn't get the "right" bounce. I did some more tests to see what is wrong.

By marking off the incriments (on screen) of both an ease in, and an ease out, I discovered that both settings are Identical. Ease in (ease into next key) is wrong.

Smooth and ease in/out seem fine.

If someone is looking at the code, can an addition be added at the same time to the keyframe options - an [animate on 2's] function is highly desirable ... often the animation is animated on twos and this strobes when the camera/bg pans on singles. Being able to pan either the camera or the background on two's overcomes the cometting/bulleting effect.

Rhoel
User avatar
Rasheed
Posts: 2008
Joined: Tue May 17, 2005 8:30 am
Location: The Netherlands

Re: Ease in/out function on keyframes

Post by Rasheed » Thu Jan 05, 2006 10:13 pm

Rhoel wrote:Sorry to be the bearer of bad news but I think I have found a mathmatical error in the keyframe options. I was doodling a bouncing ball test over New Year - and discovered that I couldn't get the "right" bounce. I did some more tests to see what is wrong.

By marking off the incriments (on screen) of both an ease in, and an ease out, I discovered that both settings are Identical. Ease in (ease into next key) is wrong.

Smooth and ease in/out seem fine.
I couldn't reproduce your findings after I made this animation:

testease.swf

With ease in, ease out and ease in/out as frame interpolations
Here are the values of the x coordinates during the 24 frames animation:
Image

It may be that the displacement isn't according to Newton's Law of Gravitity, but ease in and ease out are certainly not the same and there is an accelleration type of motion in all cases.
User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Post by Rhoel » Fri Jan 06, 2006 3:29 pm

Okay, presenting this problem graphically is easier to understand.

Image

The top line is the plot of a standard Smooth keyframe.
Second is the combined ease in/out keyframe.
Third is the Ease in.
The fourth is an ease out.
The bottom line is how a Ease out plot should look like. An ease in would be the staight reverse of the plot.

The terminology of eases in and out follow the animators tradition where a move is described in relation to the next key, ie, an Ease out is a cushion or deceleration into the next key: As an ex-features motion control animation cameraman, this is insane but I have to go with the flow.

Okay, let's move onto the problem.

Look at both ease in and ease out incremental plots. You will see there are clearly acceleration/decceleration units at both ends of the move (one set is circled in red). This is clearly wrong. The increments of an ease out should be less, less, less. In this example, the units increase. increase, then decrease, decrease.

So how does this translate to an actual scene and the wway the animation looks?

Consider a ball which is droppped.

You would use an ease out cushion for the action. The ball, went released, will increase its speed until it gains teminal velocity ... it would then continue until it hits something.

But using the current moho mathmatics, the ball would suddenly deccelerate before it hit the ground.

When the ball bounces, you use an ease in for the upward action. The ball bounces upward rapidly but its vertical climb decelerates as gravity gets to work. We return to the next ease out as the ball falls again.

But again, becuase of the incorrect maths, the ball won't bounce correctly - it starts slowly, then accelerates. That defies physics and it looks wrong.

It explains why my bouncing ball excercise failed.

I hope this clears up the cpnfusion from my original comment.

I hope it makes sense to LM as well.




Rhoel.
User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Post by Rhoel » Wed Jan 11, 2006 6:58 am

Okay ... this is excercise 4 I use as a tutorial.

It assumes the student has already figured out the basic ball bounce and how to create a shadow. blur it etc.

The exercise is deceptively simple - "just" bounce the ball into shot, ping it off the wall and bring it to a stop on the floor. And just to make it really fun, there is a light which castes an off-centred shadow on the floor and wall (it changes size, density and its blur - and since the floor is too short, the shadow has to be matted (... oh, ain't I the bitter twisted tutor from hell :twisted:)

It should look like this.

Image

The exercise means all the keyframes controlling the ball bounce must use the ease in and easy out fuctions, nothing else.

But without the [Ease out] being correct as in the graph example above, ie, no accelleration into an ease out deceleration, the result will never be right. (even in Rasheed's test, you can see the boxes changing speed).

The questions really are
  • Has anyone else encountered this
  • Is this a bug
  • Do we need to have it fixed.
Feedback please.

Rhoel
Last edited by Rhoel on Wed Jan 11, 2006 11:26 am, edited 1 time in total.
User avatar
rylleman
Posts: 750
Joined: Tue Feb 15, 2005 5:22 pm
Location: sweden
Contact:

Post by rylleman » Wed Jan 11, 2006 8:34 am

Rhoel wrote:
  • Has anyone else encountered this
  • Is this a bug
  • Do we need to have it fixed.
Yes, yes and YES.
Of course the interpolation methods of the software needs to work properly, else what use are they for?
User avatar
Ramón López
Posts: 1802
Joined: Sun Aug 08, 2004 1:41 pm
Location: Elda! Again...
Contact:

Post by Ramón López » Wed Jan 11, 2006 1:23 pm

Of course I too... only that I'm still a "little" tired/bored of ask for this old issue... But I'm very HAPPY that there was new people here prepared to fight :) ...CHEER UP! :D
User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Post by Rhoel » Wed Jan 11, 2006 3:25 pm

Ramón López wrote:... only that I'm still a "little" tired/bored of ask for this old issue...
Thanks for the comments, Ramón ... I am curious, just how old is this issue? Which version was it ooriginally noticed?

At the end of the day, its a serious error and correct operation fundimental to much of animation: And its absolutely escential if match moves are required. If Moho is to become a popular teaching tool, then LM will have no choice but fix it ... if you cannot even do the animation equivalent to programmings "Hello World" exercise, then schools simple will not promote it.

As far as I can tell, there is no way to script past this (though I'll test it).

If LM need assistance with the bi-cubic/Bezier/Hermite or whichever parametric codec, then they need to ask ... the forumla is well known.

Rhoel.
User avatar
Ramón López
Posts: 1802
Joined: Sun Aug 08, 2004 1:41 pm
Location: Elda! Again...
Contact:

Post by Ramón López » Wed Jan 11, 2006 5:10 pm

HELLO! There is another "old" thread in some place here or there where the issue was discussed when LM added the Easy In/Out feature, that must be early Moho 5 was born, and I remember that althought the feature was very well welcomed (of course, imagine before this...) many people complaints about the function and personally I've never could get the expected results... Other times people has complain specifically using too the bouncing ball example and finally the solution (by the own LM) seemed to be add new keyframes arround keyframes to get the "desired" result in the curve of motion, not a good solution (or very bad solution, why not :twisted: ) for my taste, but well... seems that's all for now... Anyway I think LM must be working or thinking a real and good solution for resolve all about TimeLine actuall knowed limitations or... I HOPE SO! :roll:
Last edited by Ramón López on Wed Jan 11, 2006 5:35 pm, edited 1 time in total.
User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Post by Rhoel » Wed Jan 11, 2006 5:26 pm

Ramón López wrote: Anyway I think LM must be working or thinking a real and good solution for resolve all about TimeLine limtations or... I HOPE SO! :roll:
It would be helpful for Mike/LM to provide a little feedback on this.

Personally i think this is where open source is so valuable ... someone can add code or write a beta module for the master programmers to cut in.

Interestingly, the reason I got into programming was to calculate camera moves - I used Pascal on an amstrad PCW8512 (god that dates me). Back then, I used Brain Salt's calculations based on radial mathmatics. Becasue there was no mator interface (at least, one I could afford) everything was printed out on paper. I later cheated the maths so that it was cameraman friendly, that is, all the constant moves were a dirivative of one quarter handle turn of a roastrum camera handwheel: It speeded up the shoot by more than half.

Eventually, I changed the maths function to bezier to give me better/smoother moves. I never did crack the Bi-cubic matrix calculation

... my oxberry camera got automated so I never needed to complete it.
User avatar
Rasheed
Posts: 2008
Joined: Tue May 17, 2005 8:30 am
Location: The Netherlands

Post by Rasheed » Wed Jan 11, 2006 5:53 pm

I wonder if one of the wonderdoctors on Lua scripting (7feet, macton) could write a script to calculate the inbetween keys with a correct interpolation. It wouldn't be pretty looking with all those keys stacked together, but it would be a workable solution until LM has fixed in the main Moho code.
User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Matting problem

Post by Rhoel » Wed Jan 11, 2006 6:01 pm

NB: This is a spin-off from the above post. Before I call this one in as a possible bug, I'll continue testing and post the moho file if I find it is a real problem and not just me being thick.

---------------------------------------------

I was building a scene based on this exercise. Everything was going to plan until I started trying to matte the shadow.

I put the ball into one group and the shadow into another. I then (for reasons not important now) put the ball and shadow into a new group with the floor and wall layers. The floors and wall are the layers added to the mask.

I then started matting. The shadow matted first time, the ball displayed in the coposite window but disappeared in the render. I re-rigged the layers into different sub-layers and the same thing happened.

What appears to be happening is the "do not mask this layer" instruction is not being read (or is being over-ridden by the group "matte this layer" instruction).

I'll build a new test scene and post it tomorrow if work load permits. But the short of it is, it seems that nested group layers loose thier matte/mask instructions.

Again, anyone else experience this?

Basic folder layout is

Code: Select all

[Matte Group]                                                < Mask = hide all.
          [Ball Group]                                        < don't matte.
                  [Ball]                                          < don't mask this layer
                          (High light vector)                < don't matte
                          (Ball vector)                        < don't matte
                   --------------------------
                  [Shadow Group]                          < matte this layer
                          (shadow vector)
                   ---------------------------      
          (Floor vector)                                       > added to matte
          (Wall vector)                                        > Added to matte.
          ------------------------------------
--------------------------------------------
User avatar
Ramón López
Posts: 1802
Joined: Sun Aug 08, 2004 1:41 pm
Location: Elda! Again...
Contact:

Post by Ramón López » Wed Jan 11, 2006 7:28 pm

Well, for personal reasons I don't use masking functions too much except when it is indispensable (I prefer another kind of complex vector/hole solutions), but personally I have never experimented such a masking problem when I've worked with masked groups inside other asked groups... Well, maybe other opinions can be more useful :roll:
User avatar
Squeakydave
Posts: 316
Joined: Tue Aug 03, 2004 9:44 pm
Location: UK - London-ish
Contact:

Post by Squeakydave » Thu Jan 12, 2006 10:58 am

I'd just like to point out at this juncture that despite what the Makers of Flash think; an ease out is accelerating out of from key frame (Slow out) and an ease in is the reverse. (slow in)

That being said I would love more control of acceleration in Moho!
macton
Posts: 93
Joined: Thu Aug 18, 2005 6:29 am
Location: San Diego

Post by macton » Thu Jan 12, 2006 11:33 am

Rasheed wrote:I wonder if one of the wonderdoctors on Lua scripting (7feet, macton) could write a script to calculate the inbetween keys with a correct interpolation.
We're discussing quite a few issues. I'm going to have to tackle this in multiple parts. Let's just start with one for today. :)
Rhoel wrote:As far as I can tell, there is no way to script past this (though I'll test it).
Let me know if this helps at all.

EDIT: I've moved the description on using scripts for bouncing ball timing to this thread: http://www.lostmarble.com/forum/viewtop ... 7359#17359 since I didn't seem to be addressing Rhoel's problem directly.
Last edited by macton on Sat Jan 14, 2006 6:16 am, edited 1 time in total.
User avatar
jahnocli
Posts: 3388
Joined: Fri Oct 29, 2004 2:13 pm
Location: UK

Post by jahnocli » Thu Jan 12, 2006 3:27 pm

[mouth hangs open] That is a great explanation of a really useful script. I did not know how useful it COULD be until I just saw this! Thanks for all the time you've put in -- we are not worthy!

J
You can't have everything. Where would you put it?
Post Reply