Bone Constrains - position control bone.
is this an X and Y coordinate, or offset, or a scale factor?
Can't find info on it in the help file. The tutorial only showed Angle constraints and angle control bone, but I can't get the position control
bone to work.
Does anything from the Library demonstrate Position Control Bones?
What are the two numbers for Position Control Bone
Moderators: Víctor Paredes, Belgarath, slowtiger
I just put up part 2 of my "All About Bones" tutorial series at www.lowrestv.com that covers most of the constraints (all except dynamics).
Yes you got it right the first time: The two boxes are X and Y. The boxes are "percentages" of the controlling target bone. 1 = 100%, 0.5 = 50% etc.
Keep in mind that bone parenting makes a big impact on this. If you have a bone that is NOT parented to any bone and another bone that is a child of a bone constrained to an UNPARENTED bone, the two values in the constraints can become "reversed"; X will be Y, Y will be X. This can cause confusion trying to figure out how that constraint works.
The way I get around that is to make sure that both bones involved in constraints have the same parent child relationship. This may mean adding an "extra" bone.
For example if I have an unparented bone constrained to a bone that is a child of another bone, the constraint won't work properly so I create an extra bone, make the constrained bone a child of this "extra" bone and then the constraint works as it should.
p.s. This is the main reason my complex head rig needs to have over 200 bones. I would say a huge majority of those bones are used just to "reverse" position constraint X Y coordinates.
-vern
Yes you got it right the first time: The two boxes are X and Y. The boxes are "percentages" of the controlling target bone. 1 = 100%, 0.5 = 50% etc.
Keep in mind that bone parenting makes a big impact on this. If you have a bone that is NOT parented to any bone and another bone that is a child of a bone constrained to an UNPARENTED bone, the two values in the constraints can become "reversed"; X will be Y, Y will be X. This can cause confusion trying to figure out how that constraint works.
The way I get around that is to make sure that both bones involved in constraints have the same parent child relationship. This may mean adding an "extra" bone.
For example if I have an unparented bone constrained to a bone that is a child of another bone, the constraint won't work properly so I create an extra bone, make the constrained bone a child of this "extra" bone and then the constraint works as it should.
p.s. This is the main reason my complex head rig needs to have over 200 bones. I would say a huge majority of those bones are used just to "reverse" position constraint X Y coordinates.
-vern
Tracking position of a finger bone
A very basic use of a Position Control Bone works for me as advertised. I can have bone #2 follow the translations of bone #1, and the tracking can be scaled up or down independently on the X and Y axis.
What I'd like is to have a bone could track the position of a child bone in another skeleton. For example, the tip of a bone.
If an arm, hand skeleton which holds a wand is moved, I'd like to have a bone which tracks the x,y of the tip of the wand, with some offset and maybe some scaling.
Unfortunately, it so far looks like a position constrained bone can only read the position of an explicity moved bone, as opposed to the net position of a child bone which moves based upon the rotations of parent bones.
But there has got to be a trick. It seems to common a task...
What I'd like is to have a bone could track the position of a child bone in another skeleton. For example, the tip of a bone.
If an arm, hand skeleton which holds a wand is moved, I'd like to have a bone which tracks the x,y of the tip of the wand, with some offset and maybe some scaling.
Unfortunately, it so far looks like a position constrained bone can only read the position of an explicity moved bone, as opposed to the net position of a child bone which moves based upon the rotations of parent bones.
But there has got to be a trick. It seems to common a task...
There is no trick to do this... only scripting.
Here's the problem:
Translation of a bone is relative to THE PARENT BONE. If a child bone is set to "0,0" in the translation it will be at the base of the parent bone. The start or base of the parent bone is 0, 0. When the parent moves the child will maintain that 0, 0 position. So a constraint does not work with a child bone if the parent rotates and changes its position.
A while back a member of the forum wrote a script to calculate the "absolute" position of a child bone so it could be used for constraints. I have since then used that initial code to create scripts that can convert all forms of motion to any other type of motion. Rotation to translation... scale to position etc etc. I use this in my head rig a lot.
The absolute position script will calculate ALL of the movement up the chain of bones to find the "absolute" positioning (including changes of position caused by rotation of the parent). What the script does is use bone names with extensions to "match" the movement from one of these child bones to another matching bone with an extension. I then use THAT bone as the target for a constraint to many other bones if needed. The script is a "one to one" relationship without scaling so I use that "extra" bone as the constraint target.
Currently scripting is the only way to do this with a position control constraint to a child bone.
-vern
Here's the problem:
Translation of a bone is relative to THE PARENT BONE. If a child bone is set to "0,0" in the translation it will be at the base of the parent bone. The start or base of the parent bone is 0, 0. When the parent moves the child will maintain that 0, 0 position. So a constraint does not work with a child bone if the parent rotates and changes its position.
A while back a member of the forum wrote a script to calculate the "absolute" position of a child bone so it could be used for constraints. I have since then used that initial code to create scripts that can convert all forms of motion to any other type of motion. Rotation to translation... scale to position etc etc. I use this in my head rig a lot.
The absolute position script will calculate ALL of the movement up the chain of bones to find the "absolute" positioning (including changes of position caused by rotation of the parent). What the script does is use bone names with extensions to "match" the movement from one of these child bones to another matching bone with an extension. I then use THAT bone as the target for a constraint to many other bones if needed. The script is a "one to one" relationship without scaling so I use that "extra" bone as the constraint target.
Currently scripting is the only way to do this with a position control constraint to a child bone.
-vern
Thanks for the explanation, now I can stop my wild Fraken-bone rig quest. I haven't done much of anything with scripts yet.heyvern wrote:There is no trick to do this... only scripting.
Here's the problem:
Translation of a bone is relative to THE PARENT BONE. If a child bone is set to "0,0" in the translation it will be at the base of the parent bone. The start or base of the parent bone is 0, 0. When the parent moves the child will maintain that 0, 0 position. So a constraint does not work with a child bone if the parent rotates and changes its position.
A while back a member of the forum wrote a script to calculate the "absolute" position of a child bone so it could be used for constraints. I have since then used that initial code to create scripts that can convert all forms of motion to any other type of motion. Rotation to translation... scale to position etc etc. I use this in my head rig a lot.
The absolute position script will calculate ALL of the movement up the chain of bones to find the "absolute" positioning (including changes of position caused by rotation of the parent). What the script does is use bone names with extensions to "match" the movement from one of these child bones to another matching bone with an extension. I then use THAT bone as the target for a constraint to many other bones if needed. The script is a "one to one" relationship without scaling so I use that "extra" bone as the constraint target.
Currently scripting is the only way to do this with a position control constraint to a child bone.
-vern
Wouldn't it be neat...
If AS allowed script writers to inspect and modify internal variable related to a given bone or shape? Kind of like in Visual Basic. Then the script writers here could do anything.
I have requested that. Hopefully it might show up in a future version. Keep my fingers crossed.rogermate wrote: Wouldn't it be neat...
If AS allowed script writers to inspect and modify internal variable related to a given bone or shape? Kind of like in Visual Basic. Then the script writers here could do anything.
The problem is if they do that too much of that Smith Micro can't sell upgrades!
If you desperately need this functionality it isn't as hard as it sounds. Scripts aren't as scary as they appear if you are just USING them and not writing your own. It does require my layer script but that's just checking a box and choosing a file. I have to finish converting my scripts to AS 6 first.
-vern
In case other noobs are in the same boat as me, I found a possible workaround at this post on the forum for the
particular case of converting some types of rotation to position. It won't work in all cases but it helped me.
They certainly must understand the concept by having Lua in the first place, but hopefully they won't incorrectly perceive that they'd lose business just because some third parties might develop new features. Fact is only a fraction of a user base tends to install third party extensions, and the app just improves as functionality migrates to the core app.
Hopefully SmithMicro won't hold Mike back from really building AS into a market segment. But if they hold back, it certainly wouldn't be the first time that "Corporate/Committee think" got in the way of a product's success. My favorite story is how the business unit heading up MiniComputer sales at IBM forced the much smaller (at the time) PC unit to hamstring their second model of the IBM PC so that it wouldn't compete with their bigger IBM machines. Sure enough, IBM lost their dominance of the PC market and IBM "compatibles", not held back by myopic corporate dogs, took over.
Boy, back in the day, I used to have to walk 5 miles to school. And it was uphill, both ways.
particular case of converting some types of rotation to position. It won't work in all cases but it helped me.
Obviously, the success of Photoshop because they opened an extensive API to third parties, as duplicated by so many other commercial applications, shows that your smily emoticon was appropriate. Just wanting to underscore the point that ultimately its in Smith Micro's best interest to have as much enhancement to their product line as possible.heyvern wrote: The problem is if they do that too much of that Smith Micro can't sell upgrades!
If you desperately need this functionality it isn't as hard as it sounds. Scripts aren't as scary as they appear if you are just USING them and not writing your own. It does require my layer script but that's just checking a box and choosing a file. I have to finish converting my scripts to AS 6 first.
-vern
They certainly must understand the concept by having Lua in the first place, but hopefully they won't incorrectly perceive that they'd lose business just because some third parties might develop new features. Fact is only a fraction of a user base tends to install third party extensions, and the app just improves as functionality migrates to the core app.
Hopefully SmithMicro won't hold Mike back from really building AS into a market segment. But if they hold back, it certainly wouldn't be the first time that "Corporate/Committee think" got in the way of a product's success. My favorite story is how the business unit heading up MiniComputer sales at IBM forced the much smaller (at the time) PC unit to hamstring their second model of the IBM PC so that it wouldn't compete with their bigger IBM machines. Sure enough, IBM lost their dominance of the PC market and IBM "compatibles", not held back by myopic corporate dogs, took over.
Boy, back in the day, I used to have to walk 5 miles to school. And it was uphill, both ways.