How to get Bone Angle on a frame when bone is controled by a Smart Bone?

[mmmaarten]

Hi,

To my surprise it looks like the bone.fAnimAngle is not working when the bone's angle is controled by a smart bone.

As an alternative I see that setting the playhead to that frame and using fAngle to get the angle does return the real angle of that bone, also when controled by a smartbone, but that's far from ideal.
I need to deal with lots of frames and it's incredibly slow (talking seconds to minutes) when using this method instead of using fAnimAngle() which does this in a blink of an eye.

So I now have two questions:

1) I would expect fAnimAngle() to always return the angle of a bone at that frame. But it doesn't because it's controled by a smart bone action. Is this a bug or a 'feature'?
2) Let's say this is intended behaviour; how are we supposed to/can we retreive the real rotation of a bone, which is controled by a smart bone, without moving the playhead?

Thanks in advance!

[Rai López]

It's been a while since I don't deal with this kind of stuff, but I think fAngle, fPos, fScale (etc.) kind of properties should give you what you want, since, if I remember well, they are intended precisely to provide the very final state of objects, no matter if we are talking about bones, points, layers... while e.g. fAnimAngle, as you concluded, is just the value stored in a certain keyframe without further influences. That's why Transform Tool's (which code you could look at) toolbar's "Angle" field shows the final angle. Someone corrects me if I'm wrong or imprecise, but I hope it can somehow be of any help for now...

EDIT: OK, I just saw Sam's reply in the Discord channel... Well, at least it seems I was right

[mmmaarten]

It's been a while since I don't deal with this kind of stuff, but I think fAngle, fPos, fScale (etc.) kind of properties should give you what you want, since, if I remember well, they are intended precisely to provide the very final state of objects, no matter if we are talking about bones, points, layers... while e.g. fAnimAngle, as you concluded, is just the value stored in a certain keyframe without further influences. That's why Transform Tool's (which code you could look at) toolbar's "Angle" field shows the final angle. Someone corrects me if I'm wrong or imprecise, but I hope it can somehow be of any help for now...

EDIT: OK, I just saw Sam's reply in the Discord channel... Well, at least it seems I was right

Hi Rai, thanks for your response. I just responded to SimplSam on Discord too.

I was afraid of this as using fAngle means we need to move the playhead, making everything extremely slow while baking the keyframes in the script I wrote. Compared to literally a blink of an eye in getting and writing values when using fAnimAngle (so no moving of the playhead) was.

So I now added a checkbox to the dialog of the script which let the user pick the extremely slow, but safe, method (using fAngle) if they work with a bone controlled by a smart bone or controller bone. The setting is turned off by default to get the superfast baking by default. I think that's fine for 99% of use cases. And for the ones using it more advanced (like I did today, that's how I found out),like controlling the bone from a smart bone timeline, than it can also do the job, but you need to switch that setting on to get 'real angle' values.

Thanks again for your response and have a nice weekend!

[synthsin75]

If you're doing it not already, I seem to remember that baking keyframes from the end of the time range to the start is faster. Might be worth trying.

[mmmaarten]

If you're doing it not already, I seem to remember that baking keyframes from the end of the time range to the start is faster. Might be worth trying.

Hi Wes, thanks for the tip. I just tried it, but it didn't make a difference if I wrote the keyframes from start to finish or in reverse.
Writing in reverse also has an extra con, because the calculations are relative to previous frames and so I first need to calculate all values to memory to be able to write the keyframes from end to start. And although not that much, that takes up extra memory.

I'm pretty sure it's the moving of the playhead that is the bottleneck here, because it needs to calculate each and every element to build the scene and update it on screen. While fAnim values probably only calculate the local rotation of the element I need and don't need to update the view.

BTW just in case, because I'm not sure if you were talking about the same thing; what I call baking is my script writing keyframes on every frame

For the record to have an idea about the difference in speed; on my computer it takes 33 to 34 seconds to bake the test scene I'm using when using fAngle for 'just' 2000 frames, but it's instantly finished (basically 0.1 or what seconds) when using fAnimAngle.

[synthsin75]

Yeah, that's what I meant by "baking" too.

What are you using to calculate all the values? The smart bone angle?

If so, you might be able to jump into the action, get the relative rotation, and then calculate the controlled bone's angle at each frame yourself. Not sure.

[mmmaarten]

Yeah, that's what I meant by "baking" too.

What are you using to calculate all the values? The smart bone angle?

If so, you might be able to jump into the action, get the relative rotation, and then calculate the controlled bone's angle at each frame yourself. Not sure.

No just the fAngle.

The calculation starts with getting the angle of a bone. Getting that angle works fine with fAnimAngle, unless that bone is being controlled by a smart bone.
But if it's controlled by a smart bone action and what that smart bone(s) is unknown to the script.

We cannot assume there's a relationship from a bone to a smartbone action, because even if that would be possible to read, coming from the bone (which I doubt there is), it could be many relations, because it can be controlled by multiple smart bone actions at the same time.

So I honestly don't think at this point it's possible to calculate the bones' angle if it's controlled by a smart bone action, instead of using fAngle. Unless the script walks through ALL smart bone actions in the scene just to see if by any chance it's animating this bone and than we need to know exactly what smart bone action has priority and/or how to mix and match values etc. WHich is a pain and clearly a no go for me now, because way too much work, very inefficient and overly complex for that single use case where people use a smart bone action to control this bone instead of keyframing it.

It would be best IMO if Moho had a value in the bone API that just does this calculation for us to get the REAL angle of a bone at a frame without needing to move the playhead.
It needs to calculate the fAnimAngle at realtime too, so why not just add a boolean argument to get the REAL angle, where it also included the control bone / smart bone calculations? Moho internally already has all the calculations for this and knows exactly how it needs to be calculated, so why it's not able to (optionally) output this value is a mystery to me honestly. As IMO it's a pretty important dat to have in the api.

But if you have a better idea, I am all ears!

Thanks for thinking along!

[synthsin75]

Yeah, the API is largely only built to accommodate what the stock tools need, in kind of an ad hoc manner, rather than being more comprehensive.

[mmmaarten]

Yeah, the API is largely only built to accommodate what the stock tools need, in kind of an ad hoc manner, rather than being more comprehensive.

FYI Just added a feature request for this.