AnimationPoser

Plugins AnimationPoser

Okk so... Since google didn't help (and Unity much less), I had to create some "new" mathematics to solve this issue.

photo_2022-08-01_01-07-01.jpg

Rotation groups are lovely!



















With this, I have been finally able to work on @rernat 's animation the proper way. This is the result:


Is this what you were looking after @rernat ? If so, I'll release a tutorial showing how to accomplish this, as soon as the plugin is rebranded. It is very easy to accomplish this from the original animation, with very few clicks.












It is also VERY easy to make her rotate less or more than 180 degrees! Of course, it will look fine for < 180 degrees but not for very large angles > 180, since then the proper animation would be different. (But who turns around > 180 anyway)? You can see the entire process in the video below:


This is one of the most amazing features of the plugin when it comes to the low level stuff (keyframe animations)! It is so easy to stretch, rotate, etc, entire timelines.
 
Last edited:
This actually seems like a really relevant issue. I'm right now debugging why I can't make the @rernat 's turning around animation work. It works 100% fine, until I save and reload. It turns out, the controllers are simply rotating in the opposite direction (clockwise vs counterclockwise) after reloading. Which can only be because of the anchor slerp thing. Quaternion interpolation is not defined for 180 degrees... It has two possible "shortest path" solutions! This is more serious though because it happens for the "virtual anchors" in the timeline, rather than the physical anchors which you can control. I'm really curious about how this problem can be resolved. It's conceptually fascinating... And it is very worthwhile to solve, since the timeline virtual anchors is a extremely helpful feature.

From the 5% knowledge I havent forgot from high school, something like:

if w1-w2 = 1 or -1,
then w1=w1+0.0001 and w2=w2-0.0001

modifying both ends so that it still works when one of the w is upper bound or lower bound.

edit: nvm. your approach is 10000% more elegant than mine
 
@haremlife Thank you so much for all your effort.
I just gave it another shot and things have improved since I tried it out last time, great work!

But again, I wasn't able to run the animation I have created, so I'll ask a question, if you don't mind.
If you think it'll be answered by the upcoming tutorials, just ignore it!

So, for example let's say I have an animation named Standing. To keep the example easy let's assume we have a single layer named All.
This animation has a single state which is named Idle.

There is a second animation called Jump. Again single layer All to keep the example simple for now. Jump has three states: Init ->Jump -> Exit.

What I would like to achieve is that the character stays in Standing:All:Idle until I press a UIButton and then it should switch to Jump:All:Init.
In IdlePoser I use a trigger SwitchState where I tell it to switch to Init.

In AnimationPoser if I remember correctly, the idea is to define messages and then have triggers send messages to switch states.
So I defined a message with Source-state=Standing:All:Idle, Target-state=Jump:All:Init, Name=JumpMsg, String=jump.
Now I have set-up the UIButton trigger to Send message and entered jump into the text-area.

The result is nothing happens when I press the button. I assume the problem is that Standing:All:Idle has no defined transition to Jump:All:Init, right? The problem is, if I define a transition there the character won't wait for the button click but switch to the target state after a certain timeout. There is a Wait Infinite option in IdlePoser but AnimationPoser doesn't have such an option, right?

I would appreciate it a lot if you could help me with this.

And thanks again for the great work. It has become a huge plugin with great functionality.
 
Another enchancement I havent mentioned last time.

I suppose the message system transits the state almost instantly, but can there be a check box telling messages to transit states following the trasition time defined in the target.

Because there are cases where the end state of anim A is different from initial state of anim B, and I dont want the character act like electrocution.
 
@haremlife Thank you so much for all your effort.
I just gave it another shot and things have improved since I tried it out last time, great work!

But again, I wasn't able to run the animation I have created, so I'll ask a question, if you don't mind.
If you think it'll be answered by the upcoming tutorials, just ignore it!

So, for example let's say I have an animation named Standing. To keep the example easy let's assume we have a single layer named All.
This animation has a single state which is named Idle.

There is a second animation called Jump. Again single layer All to keep the example simple for now. Jump has three states: Init ->Jump -> Exit.

What I would like to achieve is that the character stays in Standing:All:Idle until I press a UIButton and then it should switch to Jump:All:Init.
In IdlePoser I use a trigger SwitchState where I tell it to switch to Init.

In AnimationPoser if I remember correctly, the idea is to define messages and then have triggers send messages to switch states.
So I defined a message with Source-state=Standing:All:Idle, Target-state=Jump:All:Init, Name=JumpMsg, String=jump.
Now I have set-up the UIButton trigger to Send message and entered jump into the text-area.

The result is nothing happens when I press the button. I assume the problem is that Standing:All:Idle has no defined transition to Jump:All:Init, right? The problem is, if I define a transition there the character won't wait for the button click but switch to the target state after a certain timeout. There is a Wait Infinite option in IdlePoser but AnimationPoser doesn't have such an option, right?

I would appreciate it a lot if you could help me with this.

And thanks again for the great work. It has become a huge plugin with great functionality.

Well, that's a bug from 3.8. I'm releasing 3.9 in the following minutes. You can probably save now the plugin instance and load it after downloading 3.9, and then it should work. Please report if the bug persists in 3.9.

So, just some things about the plugin. The messages work even if there is no transition. In this case, the plugin automatically creates a "blend transition" between the current position of the controllers and the target. This transition takes 0.1s. So it is very abrupt.

Ideally, you don't want that, but you want rather to setup a transition (where you can control transition time, ease in and out, etc) or even an entire path of states going to the new animation. So, you setup transitions. Now, you don't want those transitions to take place while the message is not sent. So you just set the transition probability to zero! When receiving a message to go to a state, the plugin will cross zero-probability transitions. They are used then to make the distinction between paths (that will be crossed when receiving messages) and random markov-chain sampling. This way you have complete control over everything. This is described in the wiki here: https://github.com/haremlife/AnimationPoser/wiki/0-Probability-Transitions

0-probability transitions are also used by indirect transitions. So, messages enable you to cross 0-probability transition paths. Indirect transitions work exactly like messages, except that the indirect transitions are randomly sampled. This enables you to have even more control over the interaction between the random sampling and the state graph: https://github.com/haremlife/AnimationPoser/wiki/Indirect-Transitions
 
Another enchancement I havent mentioned last time.

I suppose the message system transits the state almost instantly, but can there be a check box telling messages to transit states following the trasition time defined in the target.

Because there are cases where the end state of anim A is different from initial state of anim B, and I dont want the character act like electrocution.

So this is what I just described above. What you are looking at is a blend transition between controller positions too far apart. The blend transitions are very fast so this is very abrupt, especially for different animations far apart.

That's what you use paths for. Create a path of 0-probability transitions between two states or two animations, so that the message can tell the character to start going through that path instead of just jumping to the target: https://github.com/haremlife/AnimationPoser/wiki/0-Probability-Transitions
 
Well, that's a bug from 3.8. I'm releasing 3.9 in the following minutes. You can probably save now the plugin instance and load it after downloading 3.9, and then it should work. Please report if the bug persists in 3.9.

So, just some things about the plugin. The messages work even if there is no transition. In this case, the plugin automatically creates a "blend transition" between the current position of the controllers and the target. This transition takes 0.1s. So it is very abrupt.

Ideally, you don't want that, but you want rather to setup a transition (where you can control transition time, ease in and out, etc) or even an entire path of states going to the new animation. So, you setup transitions. Now, you don't want those transitions to take place while the message is not sent. So you just set the transition probability to zero! When receiving a message to go to a state, the plugin will cross zero-probability transitions. They are used then to make the distinction between paths (that will be crossed when receiving messages) and random markov-chain sampling. This way you have complete control over everything. This is described in the wiki here: https://github.com/haremlife/AnimationPoser/wiki/0-Probability-Transitions

0-probability transitions are also used by indirect transitions. So, messages enable you to cross 0-probability transition paths. Indirect transitions work exactly like messages, except that the indirect transitions are randomly sampled. This enables you to have even more control over the interaction between the random sampling and the state graph: https://github.com/haremlife/AnimationPoser/wiki/Indirect-Transitions
Thx a lot for the detailed reply!!!
 
So this is what I just described above. What you are looking at is a blend transition between controller positions too far apart. The blend transitions are very fast so this is very abrupt, especially for different animations far apart.

That's what you use paths for. Create a path of 0-probability transitions between two states or two animations, so that the message can tell the character to start going through that path instead of just jumping to the target: https://github.com/haremlife/AnimationPoser/wiki/0-Probability-Transitions

Thank you. I see 0-prob as an approach, but again, it feels like scaling up the transitions fast.

If there are 5 end states, it needs 5x4 0-prob transitions to get smooth transitions, whereas 5 messages with 4 end source states and a check box of "follow target transition time" gets the job done.

Last time you told me to have an intermediate state to scale down transition number, I can transit 5 end states into an intermediate state, followed by 5 0-prob transitions to target start states, defined by messages.

Problem is, this intermediate state have to "remember" the last state transformation, so this approach doesnt work unless i use NodeAlign to predefine the transformation.

I mean the default transition time is putting there for a reason. It could save a huge amount of editing time when used properly.
 
If there are 5 end states, it needs 5x4 0-prob transitions to get smooth transitions, whereas 5 messages with 4 end source states and a check box of "follow target transition time" gets the job done.

No no no! That's where the path finding mechanism comes in. You do not need a direct transition between the source state and the target. You just need there to be any PATH. This way you usually just need to setup 5 transitions (one for each end state), because there are already transitions between the possible source states. Actually, many times you just need to set up one transition, to connect a group of (interconnected) source states with a group of (interconnected) target states.

I mean, the main magic of the plugin is how this mechanism allows you to do a lot with as few states/transitions as possible. For example, if there is a house with 15 rooms, and you want the character to have animations that play in each one of these rooms, and you want the character to be able to walk from one room to another, then instead of having to set up 15 x 14 x 2 = 420 walking animations, which would be absurd, you only need to set up 15 walking animations connecting each of the rooms with a center point in the middle of the house, reverse those animations by rotation to get the walking back, and then the character will automatically know how to walk between any pair of rooms.

This is exactly why this plugin makes it possible to do stuff that is absolutely impossible in practice with other plugins.
 
Last edited:
I mean the default transition time is putting there for a reason. It could save a huge amount of editing time when used properly.

I guess you could instead just adjust the blend transition time in the options tab? If you want something very cut to the point. But take into consideration the mechanism I described above.
 
No no no! That's where the path finding mechanism comes in. You do not need a direct transition between the source state and the target. You just need there to be any PATH. This way you usually just need to setup 5 transitions (one for each end state), because there are already transitions between the possible source states. Actually, many times you just need to set up one transition, to connect a group of (interconnected) source states with a group of (interconnected) target states.

I mean, the main magic of the plugin is how this mechanism allows you to do a lot with as few states/transitions as possible. For example, if there is a house with 15 rooms, and you want the character to have animations that play in each one of these rooms, and you want the character to be able to walk from one room to another, then instead of having to set up 15 x 14 x 2 = 420 walking animations, which would be absurd, you only need to set up 15 walking animations connecting each of the rooms with a center point in the middle of the house, reverse those animations by rotation to get the walking back, and then the character will automatically know how to walk between any pair of rooms.

This is exactly why this plugin makes it possible to do stuff that is absolutely impossible in practice with other plugins.

I dont quite understand. lets say there are 5 animations A-E with states 1-5, and I want to connected them smoothly.

So how to connect from C5 to A1?

Now, if I create an intermediate state called F1, making it into C5-F1-A1 chain, this F1 state still need A5-E5 as INs and A1-E1 as OUTs to complete the chain.

Again, the intermediate transformation affects the smoothness of anim transition, unless I can make the intermediate F1 state into controllerless.

I guess you could instead just adjust the blend transition time in the options tab? If you want something very cut to the point. But take into consideration the mechanism I described above.

Sadly speaking there is no default transition probability in options tab, connecting and editing 10 values at transition tab isnt friendly and I cant even rely on dirty editing on notepad.

EDIT: I am able to make intermediate state controllerless, sounds like I can tackle the transition smoothness problem, but I need some test on this.
 
Last edited:
I dont quite understand. lets say there are 5 animations A-E with states 1-5, and I want to connected them smoothly.

So how to connect from C5 to A1?

Now, if I create an intermediate state called F1, making it into C5-F1-A1 chain, this F1 state still need 5 in and 5 outs to complete the chain.

Again, the intermediate transformation affects the smoothness of anim transition.

Yeah... But that's 10, not 5x4 = 20 transitions right? And only 5 demand you more than one click, because for the other 5 you just need to click "IN" in the transition list.

If you had 20 animations, then by having a "chooser state" you would only need the in and out transition for each animation (40 transitions in total), instead of 20x19 = 380 transitions! See how that starts to make a huge difference?

Now notice that this is the absolute worst case scenario: the scenario where you need each of the 5 animations to be able to transition into each of the other ones. This is the most demanding need you could possibly have. Usually, you will be fine if animation A goes through, say animation C, in order to get to animation D. Notice that it won't stay in animation C, it will just pass through as quickly as possible. So usually what you can do is connect animation A to animation B, animation B to C, C to D, D to E and E to A. Now you have 6 transitions instead of 10. But the messages work: any animation can go into any animation smoothly.

Of course, you can have something in between. If you only connect each animation to the next, then the patterns in the paths for receiving messages become very obvious to the eyes of the player. But if you make A transition into C and E, B transition into A and C, C transition into D, D transition into B and C, E into B, then it doesn't look as obvious, it seems "random" or "natural", and you already have a path between each possible pair of animations. Now you only used 8 transitions. And, in this case, you don't have any intermediate state messing up the smoothness of the transitions: every transition is 100% defined by you individually, between a single source and a single target.

When you only have 5 animations, there is not a huge difference between these numbers. For example, it would seem very reasonable to setup one transition for each animation (5 total) or even two for each animation (10 total). 5 is the absolute lower theoretical minimum, and too low in practice, and 10 could be considered too much (although, again, the work is almost the same as setting up 5, because you just check the "IN" boxes) but you can also have numbers in between as I showed.

Now think about more animations. For example, for 20 animations, you seldom need ANY of the 20 to be able to directly transition to ANY of the 20. Usually having animation 1 being able to transition to, I don't know, 4, 8, 12, 17, animation 2 to transition to 3, 8, 14, 18, and so on, is enough to have all the realism you need. In mathematics, this is called a "sparse graph". It it by far the most common necessary graph in practice.

Have you heard about the theory that each pair of people in the world is connected by 6 or 7 in a chain of friends? Well, the world has 6 billion people (like states) and therefore 6 billion X billion possible friendships (like transitions), but you can get from anyone to anyone by a small chain of 6 or 7. This here is the same thing. Even if the number of animations was huge, like thousands of animations, you could still set up things such that you can get from any animation to any animation through a very short path in a sparse graph of animations.
 
Last edited:
Yeah... But that's 10, not 5x4 = 20 transitions right? And only 5 demand you more than one click, because for the other 5 you just need to click "IN" in the transition list.

If you had 20 animations, then by having a "chooser state" you would only need the in and out transition for each animation (40 transitions in total), instead of 20x19 = 380 transitions! See how that starts to make a huge difference?

Now notice that this is the absolute worst case scenario: the scenario where you need each of the 5 animations to be able to transition into each of the other ones. This is the most demanding need you could possibly have. Usually, you will be fine if animation A goes through, say animation C, in order to get to animation D. Notice that it won't stay in animation C, it will just pass through as quickly as possible. So usually what you can do is connect animation A to animation B, animation B to C, C to D, D to E and E to A. Now you have 6 transitions instead of 10. But the messages work: any animation can go into any animation smoothly.

Of course, you can have something in between. If you only connect each animation to the next, then the patterns in the paths for receiving messages become very obvious to the eyes of the player. But if you make A transition into C and E, B transition into A and C, C transition into D, D transition into B and C, E into B, then it doesn't look as obvious, it seems "random" or "natural", and you already have a path between each possible pair of animations. Now you only used 8 transitions. And, in this case, you don't have any intermediate state messing up the smoothness of the transitions: every transition is 100% defined by you individually, between a single source and a single target.

When you only have 5 animations, there is not a huge difference between these numbers. For example, it would seem very reasonable to setup one transition for each animation (5 total) or even two for each animation (10 total). 5 is the absolute lower theoretical minimum, and too low in practice, and 10 could be considered too much (although, again, the work is almost the same as setting up 5, because you just check the "IN" boxes) but you can also have numbers in between as I showed.

Now think about more animations. For example, for 20 animations, you seldom need ANY of the 20 to be able to directly transition to ANY of the 20. Usually having animation 1 being able to transition to, I don't know, 4, 8, 12, 17, animation 2 to transition to 3, 8, 14, 18, and so on, is enough to have all the realism you need. In mathematics, this is called a "sparse graph". It it by far the most common necessary graph in practice.

Have you heard about the theory that each pair of people in the world is connected by 6 or 7 in a chain of friends? Well, the world has 6 billion people (like states) and therefore 6 billion X billion possible friendships (like transitions), but you can get from anyone to anyone by a small chain of 6 or 7. This here is the same thing. Even if the number of animations was huge, like thousands of animations, you could still set up things such that you can get from any animation to any animation through a very short path in a sparse graph of animations.

Oh, your example of people connection by chain of 6 definitely hits the point!

Yes I am having a problem that my anim looks
predictive, even when I was creating a few variations at each node. That was when I havent discover your plugin, and have to rely on huge number of atoms to achieve the limited randomless. I soon ditched my old approach, move on to your plugin and still trying to figure out how to make actions customizable, looks lively (random) enough.

I am working on walk-turn around-sitdown anim, your explanation definitely helps a lot!
 
Oh, your example of people connection by chain of 6 definitely hits the point!

Yes I am having a problem that my anim looks
predictive, even when I was creating a few variations at each node. That was when I havent discover your plugin, and have to rely on huge number of atoms to achieve the limited randomless. I soon ditched my old approach, move on to your plugin and still trying to figure out how to make actions customizable, looks lively (random) enough.

I am working on walk-turn around-sitdown anim, your explanation definitely helps a lot!

Good to hear that!

By using multiple fully-connected state groups, random transitions, ease in/out, transition noises, random state durations, keyframe bezier-curve interpolated timelines, multiple layers, multiple animations, smooth transition paths, indirect transitions, etc etc, you can make things look really, really lively. There just comes a point where the player cannot keep track of all that and it just looks alive.
 
I am trying 3.9 and it seems that the initial state is going to a random place. Have you implemented the new maths on that slerp thing on this build?

This is strange. The root node is anchored by world, never controlled by other scripts other than messages. I am on the non-playing tab, have auto transitions unchecked, cant even reset the atom to zero state at moving tab.
 
Last edited:
I am trying 3.9 and it seems that the initial state is going to a random place. Have you implemented the new maths on that slerp thing on this build?

This is strange. The root node is anchored by world, never controlled by other scripts other than messages. I am on the non-playing tab, have auto transitions unchecked, cant even reset the atom to zero state at moving tab.

Weird. Maybe if you can share the .animpose file for a minimal setup to reproduce the issue.
 
Ha! I did some basic optimization in the IO and now I can import huge mocaps like VamTimbo's Idle Movements.
 
Weird. Maybe if you can share the .animpose file for a minimal setup to reproduce the issue.
The even more strange thing is, the exported file has correct values, whether it is the .json scene or .animpose. But the loaded scene always messed up.

Now I have to gamble on which plugin/atom is the culprit and keep reloading.

EDIT: finally reproduce the issue.

- make anim 1 with single state, call it root 1.
- make anim 2 with state 1 and 2, connect them.
- make anim 3 with state 1 and 2, connect them.
- save the file as instance.

1. The plugin goes through a list of states and starts at last state listed in .animpose file (anim 3 state 2), then jumping back to the initial state listed.

2. I created a trigger that sets anim speed at 0 when the location is distanced apart from the character. This is used for loco movement since I want to create a fixed-pace movement regardless of how location states are far apart. That's the reason of freezing my scene file.

3. As a hot fix, I can re-save the root state as the last state in the plugin, but feels like this is unfriendly for adding new locations, probably causing explosions if your last state is saved at a shopping mall 100m apart.

I attached the file for reference. They are supposed to be instance files, but the website dont allow to upload them as .animpose extension.
 

Attachments

  • test220801-3.txt
    20.9 KB · Views: 0
  • test220801-2.txt
    18.3 KB · Views: 0
  • test220801-1.txt
    20.9 KB · Views: 0
Last edited:
What is missing here is a video guide so that everyone can understand how it works
 
The even more strange thing is, the exported file has correct values, whether it is the .json scene or .animpose. But the loaded scene always messed up.

Now I have to gamble on which plugin/atom is the culprit and keep reloading.

EDIT: finally reproduce the issue.

- make anim 1 with single state, call it root 1.
- make anim 2 with state 1 and 2, connect them.
- make anim 3 with state 1 and 2, connect them.
- save the file as instance.

1. The plugin goes through a list of states and starts at last state listed in .animpose file (anim 3 state 2), then jumping back to the initial state listed.

2. I created a trigger that sets anim speed at 0 when the location is distanced apart from the character. This is used for loco movement since I want to create a fixed-pace movement regardless of how location states are far apart. That's the reason of freezing my scene file.

3. As a hot fix, I can re-save the root state as the last state in the plugin, but feels like this is unfriendly for adding new locations, probably causing explosions if your last state is saved at a shopping mall 100m apart.

I attached the file for reference. They are supposed to be instance files, but the website dont allow to upload them as .animpose extension.

Wait, but this only happens once, when loading right?

If so I know about that… It’s in the stuff that I plan to fix on v3.10.
 
What is missing here is a video guide so that everyone can understand how it works

Yes for sure. I’m kind of avoiding the video tutorials for now because I’m about to rebrand the plugin to a new name, so I’m just working on some last bugs and small features before. The plan was to rebrand and release the tutorials sunday last week, but I decided to implement the timelines instead… Which is a big thing. So releasing two weeks after planned but with the entire package is good news.
 
Well, I have something to work on for 3.10:


After these bugs are fixed, I can finally focus on the actual fun stuff: scenes, demos, tutorials...
 
Wait, but this only happens once, when loading right?

If so I know about that… It’s in the stuff that I plan to fix on v3.10.

Yep I can wait for that.
I have spent two hours tracing out the bug, but glad that it will be fixed.

Well, I have something to work on for 3.10:


After these bugs are fixed, I can finally focus on the actual fun stuff: scenes, demos, tutorials...

Oh my gosh, I have read a few post there, never figured out multiple messages can have the same string!

I was wondering how to target different states in an anim with multiple layers, this ends my trouble!

I can make my character crossing her legs and touching her thigh easier, thanks!
 
I have spent two hours tracing out the bug, but glad that it will be fixed.

For sure! I forgot to tell you, if you hadn't said that about the 180 degree flickering, I think I would have never figured out why the timeline virtual anchoring system was messed up. You've helped immensely in something that is so crucial for the plugin on a macro perspective. The stuff with rernat's turning around animation is amazing. I think the only thing missing now is a mirrowing system.
 
Back
Top Bottom