Moho Animation Forum

here is an example

i want to create a null layer (invisible layer... just a place to put my custom variables in the timeline)

I want those variables (modified by some custom math expression) to act on some character layer channel

ex:
character layer translation = null layer's translation * 2

local initSelection = moho.layer

--methode 1 : whole channel referencing (how to add expressions ?)
initSelection.fTranslation = nullLayer.fTranslation

--methode 2 : act on copy of some vector
local vec2 = LM.Vector3:new_local()
local vec = nullLayer.fTranslation:GetValue(moho.frame)
vec2:Set(vec.x*2, vec.y*2, vec.z)
initSelection.fTranslation:SetValue( moho.frame, vec2 )

I can add expression using method 2 (and could write some func to do it on every kframes) but i can't pass the value by reference!
(if the null layer change later, no re evaluation on my character's layer)

How can i pass values by reference AND add expressions to it?

a combinaison of both methods could do it :

>1 null object : my animation channel (say some tacking data)
>1 null object : some expression
>n null objects : u can add many expressions
>last null object : here is the math passed on every keyframes
>my actual visible object's channel,
which references last null object channel!!

7feet wrote:Any progress on that one, LM?

Not really. The problem is what I was saying before about Lua performing slowly when you have to re-evaluate scripts every frame.

The other problem is the possibility of writing Moho viruses. Besides the exciting possibilities of embedded scripts, the whole idea of combining data with executable code is kind of scary.

Lua performing slowly when you have to re-evaluate scripts every frame.

..And hit some "bake" button when ure done tweaking your character's value (also it could save your expressions somewhere)

Depends on how it's implemented. It wouldn't really have to be that different than running any other script, except that it's evaluated every frame. It does open up some ugly possibilities, but that would seem to be an issue for any program with an embedded scripting ability. One option would be to disable the OS access just for the timeline scripts. Or to protect the unwary, make an "expert" section for the project settings where the ability to use that sort of thing resides, make it default off, and include a rather dire warning if you enable it. And hopefully there wouldn't really be that many people out there who would be interested in writing Moho-bombs anyway.

LM, you had said that part of, or the problem you were having with OSX was Lua. I'm curious what the specific problem was. I've also seen some statements around that disabling Lua's garbage collection while you are doing something really processor intensive can speed things up considerably. Also that toLua's bindings are not really the most efficient around. Lua+ looks pretty interesting. I was curious, since it's basically the tools that are written in Lua, and you are generally not doing a whole lot with the one that is active when you are playing back, why Lua would be slowing down the whole process? Is some of the core code in Lua also? If not, it wouldn't seem like it would be doing much at all most of the time except polling the mouse and keyboard. But what do I know. I'm just a scripting chimp.

re-pass values by copy at every frame and do re evaluations to do that in an event based manner (if some onTimeChange event exisit internal moho code for example), would probably be slower than passing values by reference, but the Value setters/getters in the api do not allow referencing

I guess "baking" would be a good option to get things to perform well. If you have timeline scripts attached to 50 different animation channels, that's really going to perform badly, but if only the one you're tweking is "live", and when you're done you bake it, that shouldn't be bad at all.

I think to make this work, Moho would need a little extension to mark some keyframes as "script-generated" - that way, a timeline script could remove any keys it created previously if you need to re-bake it.


As far as the Lua slowdown on MacOS, that wasn't related to playback. You're right that very little scripting happens during playback. Just enough to update the tool options area. (You may have noticed that if you have a tool that displays numerical values, like Layer Translation, that these get updated during playback.)

The problem was Lua garbage collection. I don't know why, but the garbagae collector seems to run much more slowly on Mac than on Windows. Making things faster for the Mac 5.1 version was a matter of holding back the garbage collector and not letting it run as aggressively. The result was smoother tool interaction on Mac OS - I didn't notice a difference on the Windows version.

if only the one you're tweking is "live", and when you're done you bake it

this sounds like the perfect compromise!
ty LM for listening to us!

About mac limitations/bugs
i posted some questions here :
http://www.lostmarble.com/forum/viewtop ... =7101#7101

Also i'd need more details on how locked bone are implemented. Is it done in lua and can i change this?
I mean , yes the lock GUI button is done in lua of course, but what about the IK solver...

The IK solver is acessible to Lua, but is written in the C++ portion of the program. You can't really change it since that would require a script to be run continuously as the animation plays, and as we've discussed recently, that isn't (yet) possible in Moho.