Ease in/out function on keyframes

[Rhoel]

Hi Macton.

This is one way to cheat around the problem. There are others, some I already use.

Buy commercially, fudges are not the solution. Fixing the code is.

LM might wantto look at the real work of series animation, its cut throat. This is why Vietman and Thailand have series animation industries. Korea and Philippinnes are looding out because they are now too expensive to use.

How does this relate to lots of keys on the time line?

In the UK, I had a compositor who used to build his scenes as in Mactons demo, using lots of keys stacked up on a single timeline ... we fired him. Why, making changes to his work just wasn't commercially viable - it required a rebuild every time a changed was called. Unfortunately, we work in the real world with real animation directors who very frequently change thier minds.

For that reason, compositing means less keys, creating scenes which are easy to mod. In the bouncing ball scene its preferable to have the pan separated from the bounce ... that way the start and end positions can be altereed with just two keys, without affecting the actual bount timings. I have just finished a scene where the character is high-bouncing on the moon - sound familiar to the problem above???! As it turned out in this case, the director did call for the end position to be different - I moved just one key on one layer: Easy fix. Had I used the multiple step keys as above, I would have had to build it all again, and wasted a lot of valauable time. Currently, a compositor will complete a 4:30 episode in 1 week, including reshoots/corrections. Time is not a luxury.

Scripting:
My reference to the scripting was in fact to see how Moho actually stores its keyframe information. Unfiortunately, it only keeps a index number to the type of action required ... 7 is the value for an easy-in, 8 an easy out. There is no angular information that I can see at present. Its possible to write a new routine to calculate the correct numbers but this would mean re-writing the layer information with a key on every frame. How are you going to change that later, especially when you no longer have any idea which frames were the original keys?

But any kind of scripting ignores the obvious. The solution is fix not fudge.

This maths engine is broke and it has to be fixed - there just isn't any getting away from it. If LM don't, they commercially damage themselves by getting a reputation for writing shoddy code and worse, a cavalier attitude to fixing problems: That would be unfortunate because its not true and overall Moho is one damn good program.

But we must be honest: Having such a reported code problem in the fundimental maths engine, for such a long time, is just disgraceful. I am sorry if this offends LM but it really does need a kick up the jacksee: I suspect there are lots of other interesting things to be working on than the maths engine, and anyone who has programmed bi-cubics et al, know how mind numbing the calculation can be to debug. But unfortunately, programmers do not always understand the critical nature of such a calculation. In lay terms, Warners classic wild and whack animation such as Daffy Duck and Bugs, use these ease in or ease out for 90% of the fast action. It doesn't work without it. Period. Been there, done the line tests.

Worse. this problem will damage LM commercially. Moho is a damn good program, it has all the features and cost advantages that any animation school or student could possible want. And then some. So they evaluate the software, put it through its paces: And what is the first thing they are going to animate. Yeah, the damn bouncing ball, which Moho can't do.

Result. No sale.

And that is a shame bcause it should be used by animation schools and small studios. The alternative being used if Flash and that is grossly inferior and over-priced.

Point make yet, LM?

[Rai López]

YEAH! THAT'S INCREIDIBLE!!! THANKS for all that dedication macton , I LOVE all that scripts to follow paths that you have created (an old personal DREAM) and with they Moho is a more efficient program thanks to you! Well, emmm... now, a little question (although it upset me ), are you thinking in a possible "Paste Curve to Bone Position" script for the future? It'd be INCREDIBLE useful too ...Well, THANK YOU AGAIN!

EDIT: Ah, of course... about the Bouncing Ball and Easy In/Out issue... yes, I agree with you Rhoel, the number of keys must always be as minimun as possible so, as you say, we'd need a "real world" solution by LM part... (I think/hope!:)) CIAO!!!

[Rhoel]

Footnote;

On the Crashcode scripts. I have been using these, as has another compositor in the UK (I emailed him the link). The List External Files code has been especially useful, saving many hours of work and God knows how many prevented ulcers.

Definately worth the look at.

Rhoel

[Rai López]

Another Easy In/Out Related Threads:

http://www.lostmarble.com/forum/viewtop ... sc&start=0 HOT!

http://www.lostmarble.com/forum/viewtop ... sc&start=0 (more about the Bouncing ball...)

[Rasheed]

Thanks Ramón, for reminding us of those threads (especially the locked thread). It seems to me that LM is really eager to solve this problem, but that it is harder to solve than people thought at the time.

Perhaps we may see a better interpolation function in a next release of Moho. Until then we can use macton's solution as a workaround.

[Rhoel]

Thanks Ramón, for reminding us of those threads (especially the locked thread). It seems to me that LM is really eager to solve this problem, but that it is harder to solve than people thought at the time.

Perhaps we may see a better interpolation function in a next release of Moho. Until then we can use macton's solution as a workaround.

THanks for the thread references. It is a pity the original debate became hijacked by name callers ... it could have been a good opportubity to debate which way was the best way forward.

I go back to my original point. It needs fixing. The question is when, how and by who. Writing this kind of engine in not for the feint-hearted, it is mind numbingly boring.

Id there a case here for an open code solution. If so, lets discuss how. Do we use Bezier or Bi-cubics? Do we fudge (forward predict) the P1 point to a working Slow out? Exactly what functions are needed and what names are they to be called.

My suggestion is this:

• Base all calculations on Bezier - the results are good though not the fastest but whatever the parametreic calculation, the difference is going to be less than a few ms. The online information on bezier implimentation is very good.
• fairing names as such
  
  Smooth: function as now.
  Linear: Function as now.
  Slow in/slow out: New function. The slow in/out move. The number of frames to ease in/out must be set-able - critical to sync moves.
  Slow in: new function. slow fairing into move, no deceleration out. The number of frames must be set-able.
  Slow out: New function, decelerating move with a end fairing. The number of frames must be set-able.
  Hold: New name, old Step function. the position/data is held, ie, a lock frame.
  Step by. New function: Holds a position for x frames. default to be 2 frames.
  Noisey: function as now.
  cycle: Function as now.
• Code to be written in Python. This make implimentaion easier. it could be lua if others feel strongly about it but my hunch/gut feeling is Python.

If Mike/LM wants to go this route then lets agree the road plan. Here's mine:

• Agree on the above.
• Agree the parameter that the module needs (The existing keyframe data looks sufficient - desirable since we only want to mod the engine not the entire code).
• Agree a schedule.
• write the formula and test it.

Personally, I am happy to put my money (okay, time) where my mouth is. I am up for this as an open code project ... dividing the work amongst the many will get this problem fixed, fast.

Do we have any other takers on this one?

Rhoel.

[macton]

YEAH! :D THAT'S INCREIDIBLE!!! THANKS for all that dedication macton :), I LOVE all that scripts to follow paths that you have created (an old personal DREAM) and with they Moho is a more efficient program thanks to you! :)

Thanks - I appreciate that!

Well, emmm... now, a little question (although it upset me :oops:), are you thinking in a possible "Paste Curve to Bone Position" script for the future? It'd be INCREDIBLE useful too :D ...Well, THANK YOU AGAIN!

I can give you a big "MAYBE" on the bones version. There are some other things I want to do, and since we don't use bones supporting them becomes a pretty low priority. :)

[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!

Ha! Well, thanks. I know it doesn't solve Rhoel's problem, but it's practical and usable right now (for me) so I'm glad it could be useful to you too.

BTW: I added PART TWO here: http://www.lostmarble.com/forum/viewtop ... highlight=

[Rai López]

HELLO! An (before nothing) THANKS FOR ALL!!!

I can give you a big "MAYBE" on the bones version. There are some other things I want to do, and since we don't use bones supporting them becomes a pretty low priority.

Although I afraided it... It's a PITY! But well... really I can understand your position about bones animation cause treat to make possible a real bones/points operation can result (too much times) a in a real madness... It's difficult to explain and a little sad , but it's something to think...

...Well, but as I'm a little mad and I still treat to use bones in my animations (I LOVE that squishy results ) I think that maybe I should treat to modify your "Paste Curve To Layer Translation" to get that I want... Although I think this really can be a madness again, on the other hand I think too that shouldn't be a very much complicated thing, to start in some way I'll treat to extract some info of some bone based scripts (to make the changes over selected bone) and change this: "layer.fTranslation & layer.fRotationZ" for something like this: "fAnimPos & fAnimAngle" and then see what happend... I don't know, but I'm sure things will complicate'm... so, mmm... maybe I'll ask you for some advide in a near future Can I do it??? Well, anyway... GREETINGS & THANKS!

[Rhoel]

I have been working on this fairings issue for a couple of weeks since the original post - I have finally completed the formula and tested it. Its posted here on the scripting page.

http://www.lostmarble.com/forum/viewtopic.php?t=3100

Hopefully, this will eventually find its way into the main code.

Rhoel