I can't make "bone.fAngle" to work if run from another layer

[Rai López]

Hi, I assumed this would work flawlessly since I think at some point it worked to me in the past, but turns out I'm in trouble now making "fAngle" (or similar) work from a different layer even I can access bone's layer's skeleton without problems in different ways. I was about to report it as a bug, but with these things one is never totally sure about if it's really a know limitation or even if you could be missing something obvious... So I've prepared a very simple moho file and two embedded scripts (with some extra info/comments) to show the problem. Here is what you'll get while playing:



As you can see, the left red bone rotated directly by the script attached to the BONE layer works as expected (not even requiring an "UpdateBoneMatrix()"), but the right one or green simply don't make the vectors move no matter what... I did't even try things like "UpdateCurFrame()" because, as you'll probably know, it would mean open a can of bugs/errors if run from an embedded script... And, well, the download link rl_fAngle_tester_20220812-0011.zip

Any reason it could not work? As long as you can access the skeleton you should be able to make this simple thing to do its job, isn't? But maybe I'm colliding here with how order of things are calculated under the hood and there is technical reasons why bones moved by "fAngle", "fPos", etc. from a child layer's embedded script are not able to pass its motion to vectors? Well, thanks in advance for your time and any throwed light!

[Rai López]

Hmmm... I've just found that, for some reason, if I simply duplicate the child vector layer at least one of them start to react to the green bone as expected. Well, it's funny to say the least... See ya:



So it kinda confirms to me that some kind of bug is taking place here. I'll continue investigating and will report as soon as (I hope) I totally grasp it all. The possible good news is it might be somehow evitable by, for example, adding more than one child layers? Or whatever it's really the trigger that it's making it somehow work...


EDIT: It seems only child vector layers placed above the one containing the script will get their vectors moving accordingly to this fBones, IOW the embedded script's container has to be at the bottom of the group. Well, good to know... unfortunately, for the script I'm working on, I need it placed precisely above all () in order to make Motion Blur work, but good to know...

[synthsin75]

EDIT: It seems only child vector layers placed above the one containing the script will get their vectors moving accordingly to this fBones, IOW the embedded script's container has to be at the bottom of the group. Well, good to know... unfortunately, for the script I'm working on, I need it placed precisely above all () in order to make Motion Blur work, but good to know...

That makes sense. Since Moho evaluates the bone layer first, the layerscript there is evaluated before Moho evaluates the vector layer the bone manipulates. From a vector layer, the layerscript is changing something in the previously evaluated bone layer that can't then act upon the already evaluated vector layer (where the layerscript is evaluated). But any layer above the embedded vector layer can both change the bone layer AND any vector layers evaluated after the embedded layer.

For motion blur, couldn't you just reverse the order that you're offsetting the layers' motion? IOW, just have the layer script start with the topmost layer and offset every other layer accordingly?

[hayasidist]

if you bind layer to the bone in the Child case that works... (ofc, in the test set-up, the red shape goes whizzing round too but ...)

[Rai López]

Thank you, Wes! It started to make some sense to me after the lasts findings about children stacking order, but you totally ended ordering and giving all the sense in my head. I guess at first I kinda expected to get the same behavior as long as you were able to access Skeleton, but you can access Skeletons from anywhere nowadays, so it's logical at some point things can start to react differently depending on several factors... Now its clear I have to think on another approach for getting this part of the script to work and I'm still mulling over it, if it were not for the Motion Blur conflict it'd be as easy as run it from the bottom of the group (as, indeed, it was at first until I discover such MB issue), but it seem it will have to be something more convoluted. Anyway, talking about motion blur...

For motion blur, couldn't you just reverse the order that you're offsetting the layers' motion? IOW, just have the layer script start with the topmost layer and offset every other layer accordingly?

I'm not totally sure if I understood it correctly, do you mean ensure the embedded script makes motion changes over siblings in strict order from top to bottom? Well, I'm not sure if that would solve the problem (althought maybe probably?), but doubt I could implement that in this case since it has to do with masters & slaves relationships and not a linear/ordered application of changes. It hurts my mind simply try to imagine a way to make it work the way you say, but I'll take into account in case I needed to rewrite it or something (but it has been very hard to get here so I hope not ).

if you bind layer to the bone in the Child case that works...

Yeah, I'm not totally sure why that works, I guess because layer binding resulting motion is somehow applied before or something... but I need all the other binding modes anyway.

Well, time now to continue thinking about all this and maybe try-out some other possibilities that has been passing through my mind along the day and see, at least before trying to apply deeper changes... Thanks, as usually, to both!