Get child bone "real" position after parent bone r

[Rasheed]

I have added a description to the zip archive TransRotate.zip

[Genete]

You could argue that you should look for any parent, grandparent, up to the root bone, but that would involve a lot of extra checking, and what if one of those bones is dynamically linked to an unrelated bone. I think it is best to check if there are any bone position, bone angle or bone scale keys at that frame, so for all bones in the bone layer.

Is that possible? Bones dynamicaly linked???? :shock::shock:
If so PLEASE let me know!!!!

For heyvern's request, please let me give you (Rasheed) some ideas:

(I will explain to you in natural language and you translate to lua, ok? )

1) The script should not be embebed should be used by menu.
2) The master bone is rotated thru time. Slave bone don't move.
3) Once you are ready you run the script via menu, select the master bone (slave name bust be defined before or in the same option window), the desired begin and end keyframes and press run.
4) The script should do following:
For each keyframe read the master bone value. If there is a keyframe for this bone, then put a keyframe in the slabe bone with the proper values. Also it can copy, if you want, the kind of movement of the master bone keyframe (step, smooth, linear, etc.)

In this way you avoid that useless amount of keyframes and help the animator on the tedious task of click on every keyframe.

Hope it helps. Forgive me if it represents a 180º turn in the script concept, but I think it is the right way.

Regards
Genete.

[Rasheed]

That could be another solution, Genete. Of course, if you have 100+ bones, clicking the bones becomes a huge task if you do it via a menu script.

In the current version of the layer script, bone keys for all the slave bones are automatically set in the timeline if there is any bone key in the timeline in the current frame. There is no need to set all the keys by hand anymore.

You can still set all the keys of the slave bones, if you change the script's first line into:

Code: Select all

recordAll = true

There is a good reason for that, because when you remove the script, the arced motions by the bone rotation are replaced by linear motions of the bone translation if you don't create the inbetweens for the slave bones.

About that dynamically linked. What I meant to write is "linked by bone constraints", which is a form of dynamic linking. For instance, create two bone rigs:

Code: Select all

root1 <- child1
root2 <- child2

Now perform a bone constraint of child1, to be linked to the movements of child2. If you translate child2, child1 will move as well (depending on the factors set in the bone constraint of child1.

[heyvern]

There is also the big problem of visual feedback.

My use of this script absolutely requires I see the bones moving while I am animating. A menu script wouldn't do that.

The script in its current state is nearly 99% perfect for me. It does what it's suppose to and when I render or rotate bones they move. I like it. I may tweak it on my own for my "special needs" when I get a chance.

-vern

[Genete]

You (both) are absolutely rigth and I beg your pardon for not downloading this (last modified) amazing script before I post the previous post.
In the actual staus of the script it works perfectly and it can be used for many animations issues.

Thanks Rasheed! and pardon again...

[Genete]

Even more... The trick of the IK plus is absolutely needed!!!
It can be applied to vegetation (trees, flowers, ....)


WOW Rasheed! VERY INTERESTING!!!!

[heyvern]

Yes! Rasheed this is amazing.

I have been wasting too much time just rotating bones and watching in amazement as other constrained bones translate across the screen.

Sometimes there is smiling and drooling involved.

-vern

[Rasheed]

I think three kind of actions are essential for scripting:

1. initialization action - to do something when the script is started
2. actions started by the user (user interactivity)
3. background actions (without any user involvement, and always running)

Here are the types of scripts and what they can offer (most important is printed in bold):

• menu script - initialization action
• tool script - initialization action*, user interactivity
• layer script - initialization action, user interactivity**, background actions
• utility script - initialization action

In the case of a menu script, there is no real-time user interactivity possible when the script is not running. If the script is finished, its involvement with the user stops.

Although background actions seems a cool idea, it does put some strain on the computer's processor. Background actions should preferably be small scripts, otherwise they slow down performance. Doing background actions in layer scripts has the advantage that layer scripts are called only if another frame is selected. Nevertheless, layer scripts should be as small as possible.

Notes
* In principle, the initialization action of a tool should only be running when the tool is selected. This is not enforced, and it is possible to let a tool script do initialization when AS is started. However, I don't think that would be a good programming practice for tool scripts.
** Although you can do some user interaction, it is hard and cumbersome to program into a layer script.

[Rasheed]

I've added an option to record only keys of each slave bone if its master bone has bone keys (angle, translation or scale). If that is not the case, there will be no Selected Bone Translation key for that slave bone in the timeline (except for frame zero, of course).

Next, I created an utility script, you can put in the [moho dir]/scripts/utility folder**. Now you can activate the TransRotate functionality in a layer script as follows (provided you've installed the utility script):

Code: Select all

function LayerScript(moho)

    RB_TransRotate:SetTransRotate(moho,true,true,true,false)
    
end

There are five parameters for this function:

1. moho - the current moho object
2. active - if true, TransRotate is active
3. recordIfMasterBoneChanged - if true, the bone translation keys of the slave bones will only be recorded in the timeline if there is a key in the current frame for the master bones' bone angle, bone translation, or bone scale
4. recordIfAnyBoneChanged - if true, the bone translation keys of the slave bones will only be recorded in the timeline if any bone in the bone layer has a key in the current frame for its bone angle, bone translation, or bone scale
5. recordAllFrames - if true, the bone translation keys of the slave bones will recorded in all frames the script encounters

You must specify the first (moho) parameter, but the other parameters are optional. Parameters that are not specified are deemed to be false.

I hope this will simplify your layer scripts significantly and allow you to add more functionality to existing layer scripts much more easily.

** Note:
The location of the utility folder for the different operating systems:

For Anime Studio Pro for Windows:
C:\Program Files\Anime Studio Pro\scripts\utility\

For Mac OS X:
/Applications/Anime Studio Pro/scripts/utility/

For Linux:
depends where you installed Anime Studio Pro. If it is in your home directory, then:
~/Anime Studio Pro/scripts/utility/

[Rasheed]

I just had a wonderful idea to further perfect the script.

Why not write it so, that it is an utility script someone else can call in his or her own layer script? Furthermore, you should be able to set the factors for bone angle, bone translation and bone scale between master and slave bones.

Code: Select all

SetTransRotate(setName, active, masterBone, slaveBone, angleOffset, angleFactor, xFactor, yFactor, scaleFactor)

• setName is the name of the dyna-binding set
• active flags if the set is either on (true value) or off (false value)
• The parameter masterBone could be either a bone number or a bone name, as could the slaveBone. In the case of a bone name, you could also use wildcard characters, to apply your own naming scheme globally, applied to all named bones in the layer.

  Code: Select all

  local mBonePat = "*"
  local sBonePat = "*\".tmp\""
  SetTransRotate[mBonePat, sBonePat, false, 1, 1, false)

  would then tell the utility script to do what the TransRotate script does at the moment (slave bones are called after their master bones, with ".tmp" attached to it, leave out angle rotation, move same amount in x and y directions, and leave out scaling).
• The angleOffset would be the difference in angle between the master and slave bone
• The angleFactor would scale the relative¹ angle of the master bone to the relative¹ angle of the slave bone. If it has a false value, then leave out angle rotation.
• The xFactor and yFactor would scale the relative¹ position of the master bone to the relative¹ position of the slave bone. If there is a false value supplied as a parameter for that feature, that feature will not be active.
• The xScale would scale the scale of the master bone to the scale of the slave bone. If it is a false value, there will be no bone scaling.

¹Note: Relative to the value in frame zero, but absolute to the value in the bone layer, as seen on the screen.

This would mean that a script writer could create his/her own bone naming conventions, or even work with anonymous bones, using several dyna-binding sets, tell those to the animator, who can then use those conventions to speed up the animation process.

The next step would be to write tool scripts that allow the animator to write his or her own naming conventions. Save those to disk, or load or merge an existing file of dyna-binding sets from disk.

If this toolbox has been written, you can do so much more than what you can do with Bone Constraints at the moment. You could have Bone Constraints relationships all over the place, and in any way you wanted.

If this proves to be useful, I surely hope something similar will be incorporated in the next version of Anime Studio.

[Genete]

If this proves to be useful, I surely hope something similar will be incorporated in the next version of Anime Studio.

I hope that e-Frontier's people and LM have their ears pointing to this amazing ideas.

I have a sugeestion: You have commented several times that you want to post a new therad to better exaplain some of the scripts due to the original therads are a little messy. Well you MUST post a new one called "Rasheed's scripts" then stick all your wonderful code there and every update or new adition will be always in a clean first post. Like macton or fazek did previously. Perhaps LM decide to put it sticky...

Best, Genete.

[Rasheed]

OK, I'll do that. Thanks for the advice, Genete!

[chucky]

I would like to switch parent to child, any ideas?
I'm using Mike Green's excellent script 'mg_bone_parent_master.lua' script

Is it possible to reverse control?

[capricorn33]

Hey Chucky, looks real cool.

I couldn't find that script anywhere at first... all the links on the forum seem to be dead.
But I found Mike Green's own site after a little digging.

http://mikegreen.name/Lscripts.html

Just as a tip for anyone who wants to look into this one...

cheers