Would it be possible...?

[Toontoonz]

Would it be possible to write a script(s) to set up an action that is universal for all characters?

For example: A walk cycle. Or jump or whatever.

The script would be based on a uniform number of bones per character (I think 3D programs do this) - say the script for a bi-ped (2 legs) or quad-ped (4 legs) - each having X number of bones (three in leg, two in arm, whatever).

I would have my character and then instead of everytime having to set up the walk cycle for each new character I just apply the script and it is set up.
And I have the ability to tweak the walk to add a bit of personality to my character.

Or is there a better way to do this - making a universal action to apply to all characters? (I know of actions, but don´t know if one can apply the walk action of Character A to Character B.)

[7feet]

Even though it kind of backwards from the way I work, it can be done perhaps more directly by creating a master skeleton, setting up it's actions, and then importing it as a Moho Object. It would certainly be possible to write a script that would create and assign keys and actions to an existing skeleton. But more than the number of bones, it would be very important that the bones had been drawn in the correct order. Or barring that, that the bones followed a strict naming convention. Applying movements to a skeleton of different proportions from the original would probably give you some unexpected results.

One other way it could be done, maybe, is if you were able to copy keyframes from one layer to another in the timeline. Than would give you a lot of options, but LM would have to throw that in.

[jorgy]

Just throwing this out there, but could that also open the doors to motion capture animation? (specifically, generically creating and naming bones?)

[cribble]

Just throwing this out there, but could that also open the doors to motion capture animation? (specifically, generically creating and naming bones?)

What type of motion capture? because isn't motion capture something that 3d programs are good at, and also give you better control over.

[7feet]

I'd thought of motion capture for a while. 3D style motion capture files would have to be transformed to 2D and made into something that Moho could interpret. Not really to trivial a task, since you have to create a camera to flatten out the data from a particular direction, and then set up all the bone rotations and scaling. There are plenty of freely available motion capture files around, but I think most of them are for motions that are way too extreme for Moho to handle well. But being able to import a natural walk cycle would be cool. Maybe I'll start thinking about this again.

There are also motion capture formats that are 2D already, primarily for medical and sports analysis. I've seen some simple programs where you put some markers on a person (or animal?) and video tape them. Import the video, tell it which points are which joints, and then it tracks them and outputs a file. That would probably pretty easily do-able for Moho. Still don't know how well the movement would work if the skeletal proportions aren't pretty close to the original.

[Lost Marble]

The problem with either motion capture, or universal actions is that Moho is still a 2D program. In a 3D program, you can create skeletons that are basically the same - they may have slightly different arm and leg lengths, etc, but they're essentially the same.

In Moho, a skeleton setup is highly (completely?) dependent on the viewing angle. Motion capture is independent of the view, so in 3D, the same motion is valid whether you're viewing the character head-on or from the side. In Moho, there is no way for the program to know the difference between a head-on skeleton vs. a side-view skeleton. Clearly, in 2D those two skeletons will not behave the same at all, even if they are meant to represent the same character.

Then of course, you have the 3/4 profile, a back view, a view from above, etc. Depending on your animation, not all characters will need all those views, but the point is that those skeletons are not at all compatible - in 3D it would all be one skeleton with different camera angles, but in Moho those are all different skeleton setups that should move in different ways.

I think the best way to approach this in Moho would be what 7feet suggested: to create a "master" skeleton that can have actions already applied to it. Then, you can import this skeleton, add your own artwork (or skin) to it, and start using the actions. The master skeleton would only be good for one viewing angle, but you could make multiple master skeletons, one for a side view, one head-on, etc.

(The master skeleton could be viewed from different angles by rotating the layer or camera, but you can only take that so far. If you rotate it too far, the character will become obviously flat and 2D, so you couldn't use a side-view master skeleton for a head-on shot.)

[Toontoonz]

I will have to experiment with the Master Skeleton/Actions idea.

I thought I could save me some time in not having to set up a walk (or other) movement every time I have a new character. For example, I have 7 different characters and they are all walking. If I had just one Master Walk action and could apply it to all the characters (then tweek to give each a different gait, step, etc) that would save a lot of time over having to set up the walk cycle over and over and over for all 7 or more characters.

[janimatic]

hey,

i think i will setup some tracker importer soon...
indeed, why using 3d motion capture while using 2d tracking data is so much easier.
That could be used on skeleton (i remember a similar tool applying face motions to 3d models inside maya thanks to real time 2d tracking software + a camera).
I already wrote a shake tracker to maya anim script for shake (which has an exxxcelent 2d tracker)
http://animatic.no-ip.com/pub/dev/shake ... erExporter

The reuse of skeleton is basically just... replace the drawings and bones offsets at image 0 and ur done!
the reverse _apply another skel's motion data_ requieres so much tweeking, i don't think it would save time..

But ! i asked to LM _he didn't reply yet_ if we could add lua expressions in animation channels, adding custom variables directly in the timeline.
That would help a lot to to reuse and apply motion dat, adding offsets, multiply curve amplitude, etc...

[Lost Marble]

But ! i asked to LM _he didn't reply yet_ if we could add lua expressions in animation channels, adding custom variables directly in the timeline.
That would help a lot to to reuse and apply motion dat, adding offsets, multiply curve amplitude, etc...

Sorry, I must have missed that. It isn't possible to do that now, but the original idea with scripting was (besides creating new tools) to allow you to embed scripts inside your Moho file to control various parameters. For example, instead of adding keyframes to a layer's translation, you could attach a bit of script to define how it moves.

Such scripts could be simple mathematical functions, or they could get as sophisticated as you could want. An example: you could write a script that controls the color of an object based on the current weather conditions that the script downloads from the internet.

The problem is that Lua is not exactly fast. Embedded scripting like this is going to take a good amount of work to allow it to perform well.

[janimatic]

o i understand,

but maybe just a lua command interpreter would do it then
(type in lua commands in moho through some command line input?)
We could type
someAnim = math:rand()
or such, exactly as we do but with real time evaluation (no more save -> CTRL F5 to reload scripts)
Lua seem pretty quick under windows .. (it's even an argument vs python !)
i was just wondering is it the lua interpreter which is slowing down the mac version?

But i agree virtual systems withplenty exoression links get really slow in the end, and i love small / quick and creative tools such as yours!

[Lost Marble]

I think an immediate command interpreter is probably not that useful. If you type in your commands and they don't have quite the effect you want, then you have to type them in all over again with minor changes. It would be more efficient to just write a menu script and tweak it as needed.

The Lua interpreter is part of what was slowing down the Mac version. This was improved quite a bit in Moho 5.1 (the Lua slowdown on Mac issue).

[janimatic]

hey LM,

i think what could slow things down is real time re-evaluation of variables at each frame.
A great architecture would make the following possible (just some though) :
> user can enter lua formulas and hit "bake keys"
> values are hard coded to speed things up (no re-evaluation of any value)
> when usr needs to tweek a value, he can go back to the formula and hit "bake keys" once more

That way you get the best from every worlds (slow powerfull virtual systems and quick no-undo tools : quick powerfull systems!)

That the idea deside some highend compositing tools :
every parameter is linkable, animation-able
BUT
you can transparently tell the systme to prerender a branch of the tree
AND

it's all hidden to the end user!

Just some ideas...

Sincerly yours

Julien

[Lost Marble]

You can "bake keys" right now by just writing a regular script. People have mostly written general-purpose scripts, but there's no reason you couldn't write a script that was designed specifically for the needs of one particular animated sequence.

The interesting possibilities of re-evaluating scripts at every frame are the kinds of things you wouldn't want to "bake". For example, a script that would make the eyes of a character follow another object in the scene. As you move this object around, the eyes would always follow it. Or a script that triggers an action for character A whenever character B walks past a certain position. These kinds of things could be baked in, but that would make them less flexible.

[7feet]

I have to say, I really like the idea of being able to insert expressions or lua scripts into the timeline. You couldn't get to that quick enough for me. Are you intending it to be a keyframe value? As in "this script keeps running until the nect Script keyframe"? Off the top of my head, it strikes me that that would probably be a pretty flexible way to throw in fun stuff like gravity or collision detection without having to create a million keyframes. Any progress on that one, LM?

[janimatic]

well,
i spend my life adding custom anim. variables and writing expressions instead of hard coded anim... in other packages
I am thinking of a GUI in moho to link existing variables just using lua and 'dummy object's' (say some invisible layer) anim curves...