Hello.
This is my first post, so I hope I don't break any etiquette rules. I've been trying to answer all my questions by perusing the forum, but this one has me stumped.
I am trying to create a library of character-specific Actions that I can call upon at random times and at random positions on screen. For example: I have an Action that makes my character hop three steps across screen and stop. I would like to be able to initiate that action at a later time (not a continuous cycle) and at a different place in the layer w/o having to calculate offsets for every translation/rotation involved, in order to make the hop appear to have transitioned seamlessly.
I've done a lot of searching through the forum, and come across several interesting discussions about creating walk-cycle animations. I think it was 7feet who created an offset option in his Universal Layer Tool, but it was designed for specific cases in which the very next task will be a repeat of the same action. I'm wondering whether anyone has scripted something that would actually allow for relative translations/rotations of all elements (bone rotation has a "snap-back" problem as well) within an Action. This would negate the need for most offsets, and allow Actions to repeat "locally" and "non-linearly" on an immediate basis. With a reasonable, pre-built library of Actions, one could literally animate an entire scene with a series of single clicks - like ordering off a menu. Ultimately what would really be needed to eliminate ANY offsets is to be able to mix absolute and relative positioning within an Action, as some translations/rotations wouldn't make sense if it didn't interpolate back a specific starting point. They could even eventually go negative - Yikes!!!
If anyone has figured this out, I would love to know. I might try to script it myself, but, seeing as how my entire software coding experience dates back to 1989 and consists of a 9 line PASCAL program which produced 2 numbers randomly racing each other across a screen, I consider my chances slim.
Thanks for getting through such a long post.
MK
Relative Translations
Moderators: Víctor Paredes, Belgarath, slowtiger
Welcome to the forum.
...
I assume you are actions over bone layer. For example a walk cycle action would create some angle and translation keyframes over the skeleton.
To make a incremental offset you need you need a script because you need to store the current value of some variable and increase it by a fix value each time.
You can use the a script to perform a offset once the action is done.
For example your skeleton is supposed to have a root bone (what define the whole skeleton position. If not then create a root bone and link all the root bones of the skeleton to it). Once you have a root bone you can script its position by a menu script. Maybe the bone to be offset should be selected before. The menu script could have a choose option window that let you select the amount of offset depending the action you have used.
I'm not script developer but for sure it is not difficult. I think that do this using AS tools is not possible.
I hope some one developer help us because it is an interesting feature.
Best
-G
...
I assume you are actions over bone layer. For example a walk cycle action would create some angle and translation keyframes over the skeleton.
To make a incremental offset you need you need a script because you need to store the current value of some variable and increase it by a fix value each time.
You can use the a script to perform a offset once the action is done.
For example your skeleton is supposed to have a root bone (what define the whole skeleton position. If not then create a root bone and link all the root bones of the skeleton to it). Once you have a root bone you can script its position by a menu script. Maybe the bone to be offset should be selected before. The menu script could have a choose option window that let you select the amount of offset depending the action you have used.
I'm not script developer but for sure it is not difficult. I think that do this using AS tools is not possible.
I hope some one developer help us because it is an interesting feature.
Best
-G
To get a clearer picture of what you want I will try to explain how it sounds to me... correct me if I have misunderstood.
Example:
Character has 4 actions:
Idle
Walk
Jump
run
On frame 1 and 20 the idle action is applied and then on frame 25 the walk action is applied and the character walks a specified distance determined by the action.
After the walk action is complete another idle action is applied then the jump action is applied and the character jumps from that location to what ever spot the jump length covers.
After the jump the idle action is applied again to make the character "stop" (instead of being in the position of the end of the last action). On frame say... 50 the idle action is applied again (you need those "double" keys to keep it in place) then on frame 55 the run action is applied and the character runs from that spot to... wherever.
This is pretty much how you described it I think. Just apply the actions one after the other. Each foward motion would be relative the location of the character.
------
The script
What the script needs to do then is evaluate the relative positions of the keys for the root bone or body bone or which ever bone controls forward motion.
The key to this is what Genete said; having one bone that controls forward motion rather than using the individual bones to create forward motion.
For example in the body rig I use the torso and hips are children of a "master hip" bone which is located vertically at the same location as the hips or pelvis. This allows for independent rotation of both the top and bottom halves of the body. Translating or rotating the master hip bone moves the whole body.
The script would need to check the master hip bone's location relative to its own last key frame when an action is applied. The translation forward in the action for say a walk or jump would use the master hip bone. This value would be "relative" and would be added (or subtracted) to or from the translation value from the last key frame.
Genete mentioned using variables to store bone location information. I've had trouble with that in the past. Sometimes those variables get "erased" while scrubbing through the time line or lose their values and you have to go to frame 0 to reset them. It would be best to get those values "on the fly".
Each action would be created starting at frame 1. It would have forward motion or translation. This forward motion would be always based on the master root bone or master hip bone in my example.
This would be a slick trick if it could be pulled off. I don't know exactly how it should be applied. Somehow the script would have to "know" when to change the translation of the master hip bone and when not to.
I know that in the script interface you can check to see if an action has been clicked. This way the script would only run if an action was clicked or applied.
Oh wait! Better idea! Don't apply actions at all with the action palette. The actions could be controlled by "bone switches". A bone would be named to match each action. On a key frame you would "nudge" or rotate a bone to activate an action. Then the master hip bone would be modified to offset the motion from the previous key frame based on there being a key for the "action bone" activator.
I know this might work because of the Papagayo dat import that uses actions instead of switch keys. Actions can be applied without even opening the action palette.
The only problem is if the key is there for the action bone... it will continuously place a reference to the action on that frame If you use an action reference this could be avoided by checking if one is there. Worry about that later.
Not making any promises... I have a lot on my plate at the moment... if I get a chance I will do some simple tests to see if any of this is even remotely possible. This would be a VERY complicated script.
-vern
Example:
Character has 4 actions:
Idle
Walk
Jump
run
On frame 1 and 20 the idle action is applied and then on frame 25 the walk action is applied and the character walks a specified distance determined by the action.
After the walk action is complete another idle action is applied then the jump action is applied and the character jumps from that location to what ever spot the jump length covers.
After the jump the idle action is applied again to make the character "stop" (instead of being in the position of the end of the last action). On frame say... 50 the idle action is applied again (you need those "double" keys to keep it in place) then on frame 55 the run action is applied and the character runs from that spot to... wherever.
This is pretty much how you described it I think. Just apply the actions one after the other. Each foward motion would be relative the location of the character.
------
The script
What the script needs to do then is evaluate the relative positions of the keys for the root bone or body bone or which ever bone controls forward motion.
The key to this is what Genete said; having one bone that controls forward motion rather than using the individual bones to create forward motion.
For example in the body rig I use the torso and hips are children of a "master hip" bone which is located vertically at the same location as the hips or pelvis. This allows for independent rotation of both the top and bottom halves of the body. Translating or rotating the master hip bone moves the whole body.
The script would need to check the master hip bone's location relative to its own last key frame when an action is applied. The translation forward in the action for say a walk or jump would use the master hip bone. This value would be "relative" and would be added (or subtracted) to or from the translation value from the last key frame.
Genete mentioned using variables to store bone location information. I've had trouble with that in the past. Sometimes those variables get "erased" while scrubbing through the time line or lose their values and you have to go to frame 0 to reset them. It would be best to get those values "on the fly".
Each action would be created starting at frame 1. It would have forward motion or translation. This forward motion would be always based on the master root bone or master hip bone in my example.
This would be a slick trick if it could be pulled off. I don't know exactly how it should be applied. Somehow the script would have to "know" when to change the translation of the master hip bone and when not to.
I know that in the script interface you can check to see if an action has been clicked. This way the script would only run if an action was clicked or applied.
Oh wait! Better idea! Don't apply actions at all with the action palette. The actions could be controlled by "bone switches". A bone would be named to match each action. On a key frame you would "nudge" or rotate a bone to activate an action. Then the master hip bone would be modified to offset the motion from the previous key frame based on there being a key for the "action bone" activator.
I know this might work because of the Papagayo dat import that uses actions instead of switch keys. Actions can be applied without even opening the action palette.
The only problem is if the key is there for the action bone... it will continuously place a reference to the action on that frame If you use an action reference this could be avoided by checking if one is there. Worry about that later.
Not making any promises... I have a lot on my plate at the moment... if I get a chance I will do some simple tests to see if any of this is even remotely possible. This would be a VERY complicated script.
-vern
Relative Translations
Hey y'all. Thanks for the replies. I'm sorry this is a delayed response, but I thought I would get an email notification of replies. I'll just check in often from now on.
I definitely think we are on the same page. I have been using Genete's "springy bone" setup for both X and Y translations and have root bones for different body quadrants as well as the entire character.
Vern,
Don't even think of burdening yourself with more work. I was just hoping someone might have dabbled with this, and produced some similar results.
I can't claim to completely follow your tentative epiphany about "bone switches" and an " 'action bone' activator". How is this more beneficial than your previous thought about a script checking to see if an Action has been clicked?
Also, as far as a "run-script" signal goes, I'd be happy triggering it manually. In fact, assuming scripts can somehow be embedded / triggered multiple times within an Action
, this would be a way (although laborious) to sporadically choose either a Relative or Absolute interpretation of ANY move making up the action.
For example, as an interface, I always imagined a tool similar to the "Bind Layer / Points" buttons. You would select this "Relative Interpretation" button before you translate / rotate a bone / layer / point, then verify it's implantation with the Space Bar. After verification the AS "state" would always default back to Absolute interpretation. Theoretically, an Action might contain an unlimited number of copies of a much smaller script -- one which only calculates offsets of translation / rotation values for the bone / layer / point movement you just recorded, based upon previous co-ordinates from the last keyframe that utilized translation / rotation values of that same bone / layer / point movement.
Even to me that sounds really complicated, but I think it's because I used the phrase "bone / layer / point" so much. Actually I think an implementation like this could make things simpler.
Other work-arounds would involve somehow making Parenting or Bone Constraints keyframeable. Or anything that would detach an object from control by a bone.
I got close to recycling a "Hop" action by stretching the entire Action over the course of the Control Bone's 360 degree rotation (hoping that would bring it back to 0 degrees), then I remembered that AS counts rotation cycles in continuous degrees
, and everything snapped back in reverse. However, this idea might still lead to an easier scripting solution (360 = 0) if not a perfect one.
I'll keep playing with the existing capabilities within the program, and see if it yields a more simple scripting solutions.
Like Genete once said, AS is a goldmine if you know where to dig.
Thanks for you're time,
MK
I definitely think we are on the same page. I have been using Genete's "springy bone" setup for both X and Y translations and have root bones for different body quadrants as well as the entire character.
Vern,
Don't even think of burdening yourself with more work. I was just hoping someone might have dabbled with this, and produced some similar results.
I can't claim to completely follow your tentative epiphany about "bone switches" and an " 'action bone' activator". How is this more beneficial than your previous thought about a script checking to see if an Action has been clicked?
Also, as far as a "run-script" signal goes, I'd be happy triggering it manually. In fact, assuming scripts can somehow be embedded / triggered multiple times within an Action
, this would be a way (although laborious) to sporadically choose either a Relative or Absolute interpretation of ANY move making up the action.For example, as an interface, I always imagined a tool similar to the "Bind Layer / Points" buttons. You would select this "Relative Interpretation" button before you translate / rotate a bone / layer / point, then verify it's implantation with the Space Bar. After verification the AS "state" would always default back to Absolute interpretation. Theoretically, an Action might contain an unlimited number of copies of a much smaller script -- one which only calculates offsets of translation / rotation values for the bone / layer / point movement you just recorded, based upon previous co-ordinates from the last keyframe that utilized translation / rotation values of that same bone / layer / point movement.
Even to me that sounds really complicated, but I think it's because I used the phrase "bone / layer / point" so much
. Actually I think an implementation like this could make things simpler.Other work-arounds would involve somehow making Parenting or Bone Constraints keyframeable. Or anything that would detach an object from control by a bone.
I got close to recycling a "Hop" action by stretching the entire Action over the course of the Control Bone's 360 degree rotation (hoping that would bring it back to 0 degrees), then I remembered that AS counts rotation cycles in continuous degrees
, and everything snapped back in reverse. However, this idea might still lead to an easier scripting solution (360 = 0) if not a perfect one.I'll keep playing with the existing capabilities within the program, and see if it yields a more simple scripting solutions.
Like Genete once said, AS is a goldmine if you know where to dig.
Thanks for you're time,
MK
It would be glad to see some samples of that springy bones...I definitely think we are on the same page. I have been using Genete's "springy bone" setup for both X and Y translations and have root bones for different body quadrants as well as the entire character.
Remember that mathematically speaking N times 360 is the same than 0 degrees. So internally in the script the projected result is consistent. Also that moho "imperfection" (counting rotation cycles in continuous degrees) allow make continuous turning for normal bones what is a normal behavior for a common use. In fact my springy bones don't care bout that. The angle value of the bone is not relevant in the current position it only is important for the back and forward history of the angle variation in time.then I remembered that AS counts rotation cycles in continuous degrees Confused, and everything snapped back in reverse
A lot of interesting things have happened during last months (Darthfurby's actions videos, DK's and others scale rotate technique, heyvern's and mine scripting of the full 3D rig... ) I hope you have not loose those threads.
... thoughtful minds like you are always welcome
OMG! I'm "being quoted"Like Genete once said, AS is a goldmine if you know where to dig.
-G
Genete,
Thanks for the offer to review my version of your "springy bones". They are really not any different than the examples you gave on your site, but mayble I'm missing the concept entirely. You can see the file and the render at:
http://mkregor.googlepages.com
It's a basic presentation of the problem. The chicken hops then does some other flapping around. Then, when I want him to hop again, he is forced back to the original co-ordinates -- as we all knew he would be. Sorry I have not be able to experiment lately. Real jobs have a habit of getting in the way. In fact, back I go.
Best
MK
Thanks for the offer to review my version of your "springy bones". They are really not any different than the examples you gave on your site, but mayble I'm missing the concept entirely. You can see the file and the render at:
http://mkregor.googlepages.com
It's a basic presentation of the problem. The chicken hops then does some other flapping around. Then, when I want him to hop again, he is forced back to the original co-ordinates -- as we all knew he would be. Sorry I have not be able to experiment lately. Real jobs have a habit of getting in the way. In fact, back I go.
Best
MK
You could make an action independent character with out scripting now that I think about it.
It would depend on the bone structure and how the actions are applied to the bones. Just make sure all the motion is done in separate actions for each motion.
For instance... the forward hop:
Imagine the character has TWO root bones. One for general overall translation and one for the actions.
When you create the hop action use the "inner" root bone to make it go forward. This translation will be relative the parent.
So you could translate the top level root bone and the action translates the lower level root bone relatively. When you apply the hop motion that inner root bone moves based on the location of the parent root bone.
The tricky part would be how the hop relates to other actions. the best bet would be to create all actions based on the inner root bone always starting at zero.
So now let's add a walk action. It would not move forward at all just walk in place. Use the top level root bone to move it forward. This would be tricky since each time you use the walk action you would have to animate the forward motion...
<sigh>
Not much of a solution is it?
Okay... this isn't rocket science. I bet a simple script could use master and slave bones exactly like my other scripts to "add" an action movement to a bone rather than start from zero.
It would be a specialized skeleton... the forward motion of one bone would always "add" or subtract its translation from the parent bone.
So in reality the forward motion of the inner bone wouldn't even be used since the script would "override" it anyway. The trick would to rename the bone when creating the actions then nameing it back so it's controlled by the script.
This IS a very very coooool idea. I never realized that the actions weren't cumulative... that should be a feature request... blending modes for actions!
When you apply an action you could say "add" or "replace" or whatever.
Oh lordy lordy... another fascinating challenge that is hard to ignore. I promise to only spend an hour on this.
-vern
It would depend on the bone structure and how the actions are applied to the bones. Just make sure all the motion is done in separate actions for each motion.
For instance... the forward hop:
Imagine the character has TWO root bones. One for general overall translation and one for the actions.
When you create the hop action use the "inner" root bone to make it go forward. This translation will be relative the parent.
So you could translate the top level root bone and the action translates the lower level root bone relatively. When you apply the hop motion that inner root bone moves based on the location of the parent root bone.
The tricky part would be how the hop relates to other actions. the best bet would be to create all actions based on the inner root bone always starting at zero.
So now let's add a walk action. It would not move forward at all just walk in place. Use the top level root bone to move it forward. This would be tricky since each time you use the walk action you would have to animate the forward motion...
<sigh>
Not much of a solution is it?
Okay... this isn't rocket science. I bet a simple script could use master and slave bones exactly like my other scripts to "add" an action movement to a bone rather than start from zero.
It would be a specialized skeleton... the forward motion of one bone would always "add" or subtract its translation from the parent bone.
So in reality the forward motion of the inner bone wouldn't even be used since the script would "override" it anyway. The trick would to rename the bone when creating the actions then nameing it back so it's controlled by the script.
This IS a very very coooool idea. I never realized that the actions weren't cumulative... that should be a feature request... blending modes for actions!
When you apply an action you could say "add" or "replace" or whatever.
Oh lordy lordy... another fascinating challenge that is hard to ignore. I promise to only spend an hour on this.
-vern
Ran into a snag in the first 5 minutes!
If you add the translation of one bone to another bone then you get a feedback loop. The bone keeps getting changed because its translation constantly changes and since a layer script continuously updates the bone jumps all over the place every time you touch the screen or a button.
The first time I ran the script the target bone shot off the screen into oblivion. I still can't find it.
Now you could put the "old" translation into a variable, but even that will change... I tried basing it on the key frame value... but if that changes the same problem happens.
The only option I haven't tried yet is what this is for anyway... actions. If you insert a copy of an action (this would only work with action "copies" not references), the translation value is separate from the main time line and the script would only run once, when an action is applied. When the key frame for a single bone is inserted into the main time line it would be modified at that moment and never again. But of course how would you make edits later...
This off course is a little more tricky because I don't have nearly as much experience with actions. I wanted to test the idea on a standard bone layer script before running into any weird things that happen when fooling with actions and scripts.
This one is trickier than I thought so I am putting it on the back burner for now. Since I did that new bone tool and learned about bone lists in scrolling text boxes I want to finish my copy/paste bone script.
-vern
If you add the translation of one bone to another bone then you get a feedback loop. The bone keeps getting changed because its translation constantly changes and since a layer script continuously updates the bone jumps all over the place every time you touch the screen or a button.
The first time I ran the script the target bone shot off the screen into oblivion. I still can't find it.
Now you could put the "old" translation into a variable, but even that will change... I tried basing it on the key frame value... but if that changes the same problem happens.
The only option I haven't tried yet is what this is for anyway... actions. If you insert a copy of an action (this would only work with action "copies" not references), the translation value is separate from the main time line and the script would only run once, when an action is applied. When the key frame for a single bone is inserted into the main time line it would be modified at that moment and never again. But of course how would you make edits later...
This off course is a little more tricky because I don't have nearly as much experience with actions. I wanted to test the idea on a standard bone layer script before running into any weird things that happen when fooling with actions and scripts.
This one is trickier than I thought so I am putting it on the back burner for now. Since I did that new bone tool and learned about bone lists in scrolling text boxes I want to finish my copy/paste bone script.
-vern
Of course.This one is trickier than I thought so I am putting it on the back burner for now. Since I did that new bone tool and learned about bone lists in scrolling text boxes I want to finish my copy/paste bone script.
I am continuing my foray into basic programming. So far, I can add two numbers in Python.
But, probably not LUA.