Rasheed's scripts
Moderators: Víctor Paredes, Belgarath, slowtiger
Okay..
There is a bone called Bone_B.
Bone_B is a child of Bone_A.
Now we have Bone_B.tmp. Bone_B.tmp follows along happily with Bone_B.
Now we create Bone_C as a child of Bone_B.tmp and offset it away from Bone_B.tmp
Bone_C will have a different translation/rotation. It is further away from the rotation axis.
But we now need to create another bone called Bone_C.tmp in order to get that translation for a constraint.
Bone_C could be a child of Bone_B or Bone_B.tmp. It doesn't matter. I'm just trying to cut down on the number of bones. We already "know" that Bone_B.tmp is "following" Bone_B. If it has a child could that child "automatically" get the same "treatment"?
If a bone has a slave, or is a slave would there be a way to "cascade" the translation script down to the children so that constraints could pick up that translation? Or by adding a Bone_C.tmp bone AS A CHILD of Bone_B.tmp it keys the translation offset without that extra bone?
I will try to do a demo video of this in Flash.
-vern
There is a bone called Bone_B.
Bone_B is a child of Bone_A.
Now we have Bone_B.tmp. Bone_B.tmp follows along happily with Bone_B.
Now we create Bone_C as a child of Bone_B.tmp and offset it away from Bone_B.tmp
Bone_C will have a different translation/rotation. It is further away from the rotation axis.
But we now need to create another bone called Bone_C.tmp in order to get that translation for a constraint.
Bone_C could be a child of Bone_B or Bone_B.tmp. It doesn't matter. I'm just trying to cut down on the number of bones. We already "know" that Bone_B.tmp is "following" Bone_B. If it has a child could that child "automatically" get the same "treatment"?
If a bone has a slave, or is a slave would there be a way to "cascade" the translation script down to the children so that constraints could pick up that translation? Or by adding a Bone_C.tmp bone AS A CHILD of Bone_B.tmp it keys the translation offset without that extra bone?
I will try to do a demo video of this in Flash.
-vern
Vern, I think this was already possible in the current version of the script.
Bone_A <- Bone_B <- Bone_C (<- means child of)
(offset Bone_C from Bone_B with bone translation in frame zero)
Create Bone_B.tmp to follow Bone_B with bone translation only
Create Bone_C.tmp to follow Bone_C with bone translation only
Bones Bone_B.tmp and Bone_C.tmp will now give you a bone translation for whatever you do with Bone_A, Bone_B and Bone_C in frame one and higher.
@Genete: Don't worry, the TransRotate script is a very specialized script.
Bone_A <- Bone_B <- Bone_C (<- means child of)
(offset Bone_C from Bone_B with bone translation in frame zero)
Create Bone_B.tmp to follow Bone_B with bone translation only
Create Bone_C.tmp to follow Bone_C with bone translation only
Bones Bone_B.tmp and Bone_C.tmp will now give you a bone translation for whatever you do with Bone_A, Bone_B and Bone_C in frame one and higher.
@Genete: Don't worry, the TransRotate script is a very specialized script.
Thanks Rasheed... This seems to be hard to explain. 
If Bone_C and Bone_B are children of a bone that is a "slave" or a tmp bone I was hoping to avoid creating those extra bones for the children.
Bone_A <- Bone_B
Create Bone_B.tmp which matches Bone_B
Now you would do this:
Bone_A <- Bone_B = Bone_B.tmp <- Bone_C
(Bone_C at this time can't be used for a constraint. You still need yet another Bone_C.tmp)
I would like Bone_C to act as IF it had a Bone_C.tmp without having to create it.
Instead of going through looking for the .tmp bones specifically. Could it just assume that any child of a slave bone is keyed like a "tmp" bone?
For instance, a "tmp" bone is not parented to anything. It's translation is keyed from the master bone.
If a "tmp" bone had a child the child would translate based on the parent which is translated by the master bone. But the child bone still needs a matching tmp bone.
Would there be a way to treat the child of a tmp bone the same way as its parent without creating a tmp bone for it?
My head is spinning... I really need to do an illustration.
-vern
If Bone_C and Bone_B are children of a bone that is a "slave" or a tmp bone I was hoping to avoid creating those extra bones for the children.
Bone_A <- Bone_B
Create Bone_B.tmp which matches Bone_B
Now you would do this:
Bone_A <- Bone_B = Bone_B.tmp <- Bone_C
(Bone_C at this time can't be used for a constraint. You still need yet another Bone_C.tmp)
I would like Bone_C to act as IF it had a Bone_C.tmp without having to create it.
Instead of going through looking for the .tmp bones specifically. Could it just assume that any child of a slave bone is keyed like a "tmp" bone?
For instance, a "tmp" bone is not parented to anything. It's translation is keyed from the master bone.
If a "tmp" bone had a child the child would translate based on the parent which is translated by the master bone. But the child bone still needs a matching tmp bone.
Would there be a way to treat the child of a tmp bone the same way as its parent without creating a tmp bone for it?
My head is spinning... I really need to do an illustration.
-vern
At this moment, I'm testing the combination FlipByBones and TransRotate. It seems I should work bone position constraints into both scripts, because I want use a TransRotated bone as a constraint control bone for a the FlipByBones control bone
a) TransRotate gives bone-translated bone_C.tmp.
b) Use position constrain on bone Layer_1.ctrl (control bone for FlipByBones) by bone bone_C.tmp.
So bone_C drives bone_C.tmp, and bone_C.tmp drives Layer_1.ctrl, which in turn drive the z depth of layer Layer_1.
To solve your problem as well, both scripts need to take Bone Constraints into account (to be more specific, the position constraint from another bone).
BTW I have changed the nomenclature of the FllipByBones a llittle. Layer.ctrl controls the z depth of layer "Layer" and Layer.flip is still the boundary bone.
a) TransRotate gives bone-translated bone_C.tmp.
b) Use position constrain on bone Layer_1.ctrl (control bone for FlipByBones) by bone bone_C.tmp.
So bone_C drives bone_C.tmp, and bone_C.tmp drives Layer_1.ctrl, which in turn drive the z depth of layer Layer_1.
To solve your problem as well, both scripts need to take Bone Constraints into account (to be more specific, the position constraint from another bone).
BTW I have changed the nomenclature of the FllipByBones a llittle. Layer.ctrl controls the z depth of layer "Layer" and Layer.flip is still the boundary bone.
I'm reaching the limits of the scripting interface of layer scripts. I can hack around that, but that would take considerable time.
The problem is in the FlipByBones script:
The FlipByBones scripts tries to sense if a control bone (with extension .ctrl) has crossed a boundary bone (with extension .flip), horizontally (left to right).
In order to know if a boundary has been crossed in the current frame, I need to know the position of the control bone and boundary bone in the current frame. I then compare that to their positions in the previous frame (one frame before the current frame). If the sign of has changed between the current frame, and one frame before, the control bone has crossed the boundary bone.
In order to know what z coordinate to use for the layer that is controlled by the script, I have to compare the values of in the current frame and frame one, and the current frame and the one frame earlier than the current frame. If the product is less than zero, the z coordinate of the controlled layer should be minus its value in frame one, otherwise, the same value as in frame one.
I hope that is clear.
Now, in order to take into account possible parent bones and control parent bones (which you set in the Bone Constraints menu), I have to transform the position vectors of the control and boundary bones in the current frame, one frame before, and in frame one. The transformation matrices depend on the parent bone and the control parent bone (using the fMovedMatrix value of the parent bone, and of the control parent bone).
To do that in the current frame is straightforward, however doing it in another frame than the current frame proves to be very tricky.
All would be fairly easy if one could set the frame number in a layer script. but while moho:SetCurFrame is available in menu scripts, it is certainly not available in layer scripts. The transformation matrices (fMovedMatrix) for parent bones and control parent bones (translation constraint) can only be applied in the current frame. Since you cannot change the frame number in layer scripts, you need to calculate the transformations manually from the parent bone's angle, position and scale key values. You then use fRestMatrix, and some math formulas I haven't written at this moment, to transform the position vectors of the control and boundary bones. This is the hack I will be using if everything else fails.
Because you cannot assume that these key values of the parent and control parent bones are in the same frames, they should be estimated by linear interpolation. The estimated values for angle, position and scale of the parent bone in a certain frame then should be used to transform their child's position vector into a "real" vector (relative to the layer, instead of the parent bone). And if a parent bone has a parent of its own, this grandparent bone has to be taken into account as well (and if that grandparent has a parent, and so on).
This needs to be done for both the control and boundary bones, in the current frame, the frame before that, and in frame one.
That is some serious calculus...
I think the best solution is to write a tool script, because you then can (hopefully) use moho:SetCurFrame to simplify the script.
The problem is in the FlipByBones script:
The FlipByBones scripts tries to sense if a control bone (with extension .ctrl) has crossed a boundary bone (with extension .flip), horizontally (left to right).
In order to know if a boundary has been crossed in the current frame, I need to know the position of the control bone and boundary bone in the current frame. I then compare that to their positions in the previous frame (one frame before the current frame). If the sign of
Code: Select all
x coordinate control bone minus x coordinate boundary boneIn order to know what z coordinate to use for the layer that is controlled by the script, I have to compare the values of
Code: Select all
dx(frame) = [x coordinate control bone](frame) - [x coordinate boundary bone](frame)Code: Select all
( dx(current frame) - dx(current frame - 1) ) * ( dx(current frame) - dx(frame one) )I hope that is clear.
Now, in order to take into account possible parent bones and control parent bones (which you set in the Bone Constraints menu), I have to transform the position vectors of the control and boundary bones in the current frame, one frame before, and in frame one. The transformation matrices depend on the parent bone and the control parent bone (using the fMovedMatrix value of the parent bone, and of the control parent bone).
To do that in the current frame is straightforward, however doing it in another frame than the current frame proves to be very tricky.
All would be fairly easy if one could set the frame number in a layer script. but while moho:SetCurFrame is available in menu scripts, it is certainly not available in layer scripts. The transformation matrices (fMovedMatrix) for parent bones and control parent bones (translation constraint) can only be applied in the current frame. Since you cannot change the frame number in layer scripts, you need to calculate the transformations manually from the parent bone's angle, position and scale key values. You then use fRestMatrix, and some math formulas I haven't written at this moment, to transform the position vectors of the control and boundary bones. This is the hack I will be using if everything else fails.
Because you cannot assume that these key values of the parent and control parent bones are in the same frames, they should be estimated by linear interpolation. The estimated values for angle, position and scale of the parent bone in a certain frame then should be used to transform their child's position vector into a "real" vector (relative to the layer, instead of the parent bone). And if a parent bone has a parent of its own, this grandparent bone has to be taken into account as well (and if that grandparent has a parent, and so on).
This needs to be done for both the control and boundary bones, in the current frame, the frame before that, and in frame one.
That is some serious calculus...
I think the best solution is to write a tool script, because you then can (hopefully) use moho:SetCurFrame to simplify the script.
Rasheed,
I think the script works great without constraints.
Since I only need constraints specifically for ONE BONE in my face rig (one bone flips both sides simultaneously) would there be a way to "hard code" that situation... just for that one unique situation (my face rig)?
The bones to flip the layers in my rig could easily be root bones without children or parents, the only thing I need is to be able to control that flipping with a constraint (since they translate from the transrotate script), otherwise the user of the rig would have to key the layer flips individually by moving a bone at a specific frame on each turn (which could also be a solution for version 1 of this rig).
-vern
I think the script works great without constraints.
Since I only need constraints specifically for ONE BONE in my face rig (one bone flips both sides simultaneously) would there be a way to "hard code" that situation... just for that one unique situation (my face rig)?
The bones to flip the layers in my rig could easily be root bones without children or parents, the only thing I need is to be able to control that flipping with a constraint (since they translate from the transrotate script), otherwise the user of the rig would have to key the layer flips individually by moving a bone at a specific frame on each turn (which could also be a solution for version 1 of this rig).
-vern
I'm starting to think that I'm taking a wrong approach here and am assuming things I have no proof of. According to the scripts that are available, fMovedMatrix is only used to align child bones with their parents. There is no mention of control parents (parents through bone constraint).
Now I'm not so sure how you should align bones with their control parents. I assumed that fMovedMatrix should be doing the trick, but now I'm not so sure anymore. There is no code available to guide me, and I think this is a bit outside what the script is supposed to do. The Lua scripting interface was never meant for such trickery.
This means I actually have no clue how to calculate the "real" position of bone that is constraint by another bone. I already know that simply reading the fPos value doesn't give you that "real" position. Translating the control parent bone seems to be added (after scaling) to the control child bone's fPos (adding the constraint vector to the child bone's position vector). This means that if the control parent bone has a parent bone and it is at an angle with that parent bone, moving the control parent bone will not translate into a movement in the same direction in the control child bone.
Perhaps I should go back to basis, and figure out how to do this.
Bone Constraints can sometimes be very confusing and, at times, frustrating.
Now I'm not so sure how you should align bones with their control parents. I assumed that fMovedMatrix should be doing the trick, but now I'm not so sure anymore. There is no code available to guide me, and I think this is a bit outside what the script is supposed to do. The Lua scripting interface was never meant for such trickery.
This means I actually have no clue how to calculate the "real" position of bone that is constraint by another bone. I already know that simply reading the fPos value doesn't give you that "real" position. Translating the control parent bone seems to be added (after scaling) to the control child bone's fPos (adding the constraint vector to the child bone's position vector). This means that if the control parent bone has a parent bone and it is at an angle with that parent bone, moving the control parent bone will not translate into a movement in the same direction in the control child bone.
Perhaps I should go back to basis, and figure out how to do this.
Bone Constraints can sometimes be very confusing and, at times, frustrating.
I found that section about constraints in the LUA reference but man! Not much there. Pretty basic stuff.
I was able to change constraints pretty easily with LUA. I figured out how to change bone IDs, constraint values etc. But you're right, you would have to read that constraint value, the bone ID and then calculate that on the position of the bone... makes my head spin... must be why I lost my hair years ago.
I am going to try and figure out some way to make this easier on my end as well. Maybe I do need a special bone for head turns. At least all the keys are on one bone layer. Easier than tracking down keys on another layer.
Do all the head turning then go back and key the ear layers with a bone. It isn't that much extra effort (whistling through the grave yard )
This is version 1.0 of the rig for me. So there is much room for improvement. Who knows, e-frontier might already be working on a new version of AS that has a bunch of new things in it.
-vern
I was able to change constraints pretty easily with LUA. I figured out how to change bone IDs, constraint values etc. But you're right, you would have to read that constraint value, the bone ID and then calculate that on the position of the bone... makes my head spin... must be why I lost my hair years ago.
I am going to try and figure out some way to make this easier on my end as well. Maybe I do need a special bone for head turns. At least all the keys are on one bone layer. Easier than tracking down keys on another layer.
Do all the head turning then go back and key the ear layers with a bone. It isn't that much extra effort (whistling through the grave yard
)This is version 1.0 of the rig for me. So there is much room for improvement. Who knows, e-frontier might already be working on a new version of AS that has a bunch of new things in it.
-vern
-
Víctor Paredes
- Site Admin
- Posts: 5648
- Joined: Wed Jan 26, 2005 12:18 am
- Location: Barcelona/Chile
- Contact:
ok, here is my first attempt to flipbybones. thanks rasheed, the script is excellent (thanks to genete too, he explained me how to work with it... i couldn't understand it in english)
Last edited by Víctor Paredes on Mon Feb 05, 2007 5:13 am, edited 6 times in total.
-
Víctor Paredes
- Site Admin
- Posts: 5648
- Joined: Wed Jan 26, 2005 12:18 am
- Location: Barcelona/Chile
- Contact:
thanks you both. this scripts is better than i imagined, i'm now even more convinced that AS really really needs animated layer order.
genete, the file is made just using vectors, here you have:
http://www.freewebs.com/tazatriste/mohos/gato5.anme
genete, the file is made just using vectors, here you have:
http://www.freewebs.com/tazatriste/mohos/gato5.anme