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
Ease in/out function on keyframes
Moderators: Víctor Paredes, Belgarath, slowtiger
Re: Ease in/out function on keyframes
I couldn't reproduce your findings after I made this animation: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.
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:
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.
Okay, presenting this problem graphically is easier to understand.
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.
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.
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
)
It should look like this.
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
Rhoel
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
)It should look like this.
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.
Rhoel
Last edited by Rhoel on Wed Jan 11, 2006 11:26 am, edited 1 time in total.
Thanks for the comments, Ramón ... I am curious, just how old is this issue? Which version was it ooriginally noticed?Ramón López wrote:... only that I'm still a "little" tired/bored of ask for this old issue...
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.
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 ) 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! 
) 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!
Last edited by Rai López on Wed Jan 11, 2006 5:35 pm, edited 1 time in total.
It would be helpful for Mike/LM to provide a little feedback on this.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!
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.
Matting problem
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
---------------------------------------------
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.
------------------------------------
--------------------------------------------
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
-
Squeakydave
- Posts: 328
- Joined: Tue Aug 03, 2004 9:44 pm
- Location: UK - London-ish
- Contact:
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.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.
Let me know if this helps at all.Rhoel wrote:As far as I can tell, there is no way to script past this (though I'll test it).
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.
