Posted: Thu Jan 12, 2006 4:02 pm
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?
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?
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! 
), are you thinking in a possible "Paste Curve to Bone Position" script for the future? It'd be INCREDIBLE useful too 
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...
and I still treat to use bones in my animations (I LOVE that squishy results 
Can I do it??? Well, anyway... GREETINGS & THANKS!