Plugins AnimationPoser

[rernat]

Yes, all of this are point I'm aware. Regarding external triggers, of course they can be used.. However it is easier to simply use them to select state, and leave the rest to the plugin to operate. This way you avoid combinatorial explosions of the amount of necessary triggers. In other words, the trigger is just used as a... trigger, I mean, as an initial firestarter, and the plugin does the rest.

Ok, that was what I tried too but got problems with that adressing. E.g. I want by trigger that the state of layer#3 in the running animation (lets say #1) changes. (to a state with a transition to the next animation which cant be reached other than external) How can I achiev that? An how must the transition been written in that state for changing all layers to Animation#2, State#1 ?

 

[rernat]

Maybe lets talk with a simple example.
Animation#1
Layer#1
3States with transitions beetween all 3 in/out but transitions to state 3 have zero possibility as state 3 shall only be reached via external trigger.
State#3 has an out transition to animation#2 + sync for layer#2 states.

Layer#2: 3 states with transitions in/out to each other.

Now Animation#1 is running (in layer#1 only states#1 and #2 switch into each other)

Now I want to switch by external trigger from Animation#1/Layer#1 (state#1 and #2 fluctuating) into Animation#1/Layer#1/State#3 to recieve a fluently transition to animation#2.
Via external trigger I can adress "switch state" but how does your plugin know which layer is meant to switch to this state?

In Idleposer I have several ways to achieve this. I may work with layer masks or I can adress the different idleposer-plugins by the external trigger.

 

[haremlife]

Ok, that was what I tried too but got problems with that adressing. E.g. I want by trigger that the state of layer#3 in the running animation (lets say #1) changes. (to a state with a transition to the next animation which cant be reached other than external) How can I achiev that? An how must the transition been written in that state for changing all layers to Animation#2, State#1 ?

Don't worry. The plugin is pretty broken. I'm working on it. Next version will be the first stable one.

 

[haremlife]

haremlife updated AnimationPoser with a new update entry:

First fully working version

Previous versions introduced a lot of features. However, the plugin was not fully working: instances with multiple animations usually led to unexpected issues, animations and layers sliders were always bugged, and crucial features had been accidentally removed by merges made by other contributors.

This version has deeply refactored transitions and has been tested with multiple complex animations in a single instance.

A core feature has returned as the new "Root State" checkbox. This makes...

Read the rest of this update entry...

 

[haremlife]

@rernat Now you can try it.

 

[cdgczta8]

@haremlife a couple of things I noticed with v3.3:
- As you asserted in your update, anchors aren't working properly
- InfiniteDuration + WaitForTrigger don't seem to exist anymore
- When do triggers (enter begin, enter end, leave begin, leave end) actually take place? It seems that enter end and leave begin happen at the same time?

 

[haremlife]

Hey @cdgczta8 . I thought infinite duration was unnecessary since you can just create a state that has no transitions. Like, instead of making State 1 that has infinite duration and a trigger that leads State 1 into State 2 through a transition, why not make a State 1' which has no transitions and State 1 which has a transition to State 2, and then a SwitchState trigger leading State 1 to State 1'?

Maybe it sounds like more work, but all you need is to hit "Add State" and done, you have the new transitionless state State 1' created from State 1.

You can also make an idle animation while the character waits for the trigger. This seems like the most interesting scenario.

Infinite durations were something that made sense in IdlePoser I think, but here they are redundant. This is in alignment with the "pattern over ui" philosophy: you can have less explicit features if these features can be reproduced by patterns.

But I care about whether that makes sense for you. Do you think this pattern does the trick, or should the "infinite duration" come back?

Regarding anchors and trigger, indeed they must be tested and bugs fixed. If you want to help me with that again, I'm thankful. But I think I can handle it easily in the next development round. The refactorings I did are making the code become extremely tamed. The thing that made me happier was being able to add the code for transforming the controllers positions in all states when the root state is captured. I was blindly guessing mathematical transformations. It was awesome when that shit worked

 

[Skrownerve]

Hey @cdgczta8 . I thought infinite duration was unnecessary since you can just create a state that has no transitions. Like, instead of making State 1 that has infinite duration and a trigger that leads State 1 into State 2 through a transition, why not make a State 1' which has no transitions and State 1 which has a transition to State 2, and then a SwitchState trigger leading State 1 to State 1'?

Maybe it sounds like more work, but all you need is to hit "Add State" and done, you have the new transitionless state State 1' created from State 1.

You can also make an idle animation while the character waits for the trigger. This seems like the most interesting scenario.

Infinite durations were something that made sense in IdlePoser I think, but here they are redundant. This is in alignment with the "pattern over ui" philosophy: you can have less explicit features if these features can be reproduced by patterns.

But I care about whether that makes sense for you. Do you think this pattern does the trick, or should the "infinite duration" come back?

Regarding anchors and trigger, indeed they must be tested and bugs fixed. If you want to help me with that again, I'm thankful. But I think I can handle it easily in the next development round. The refactorings I did are making the code become extremely tamed. The thing that made me happier was being able to add the code for transforming the controllers positions in all states when the root state is captured. I was blindly guessing mathematical transformations. It was awesome when that shit worked

I know I'm not them but I think this approach makes sense if it works fine. Documentation and examples and stuff will be very helpful, I know they're in the works. Thanks for keeping up with this!

 

[cdgczta8]

@haremlife my use case is InfiniteDuration/WaitForTrigger. I want to have a valid transition but want to wait on an external trigger to begin the transition. The thing I find odd about SwitchState is: how do I specify which layer the switchstate trigger is attempting to change? E.g. if I have Layer1 with State1/State2 and Layer 2 with State3/State4, can I just send a "SwitchState" trigger with "State3" and it'll work every time? What if I have layers with overlapping state names? Does it change the state for every layer with that name or is there a way to specify the layer in my SwitchState trigger? I'm just a bit confused.

Additionally, I fixed anchors! Check your github and please test! I tried it in a small scene and it worked but a test suite would be ideal.

 

[haremlife]

@haremlife my use case is InfiniteDuration/WaitForTrigger. I want to have a valid transition but want to wait on an external trigger to begin the transition. The thing I find odd about SwitchState is: how do I specify which layer the switchstate trigger is attempting to change? E.g. if I have Layer1 with State1/State2 and Layer 2 with State3/State4, can I just send a "SwitchState" trigger with "State3" and it'll work every time? What if I have layers with overlapping state names? Does it change the state for every layer with that name or is there a way to specify the layer in my SwitchState trigger? I'm just a bit confused.

Additionally, I fixed anchors! Check your github and please test! I tried it in a small scene and it worked but a test suite would be ideal.

You got a good point. Switch State needs to specify the layer in general. If it works now, it probably works through the current layer. This could work for your use case. But it is of course not reliable in terms of UX. Well, that is going to be part of the trigger testing/development which is coming soon.

Right now I'm working on multi-atom sync, which is a hugely transformative feature for animation, but also quite complex.

I'll definitely check the github code for the next version to be released.

 

[cdgczta8]

You got a good point. Switch State needs to specify the layer in general. If it works now, it probably works through the current layer. This could work for your use case. But it is of course not reliable in terms of UX. Well, that is going to be part of the trigger testing/development which is coming soon.

Right now I'm working on multi-atom sync, which is a hugely transformative feature for animation, but also quite complex.

I'll definitely check the github code for the next version to be released.

Yes! In testing my update to the anchor fix, I pulled in your update to multi-atom sync. I haven't tried it yet but the UI looks nice!

I'm going to try to fix triggers now too. I may get that done before you get a chance to work on it. Will add it to the current PR if I fix it and I'll make sure to add in the fix for switchstate.

 

[haremlife]

Yes! In testing my update to the anchor fix, I pulled in your update to multi-atom sync. I haven't tried it yet but the UI looks nice!

I'm going to try to fix triggers now too. I may get that done before you get a chance to work on it. Will add it to the current PR if I fix it and I'll make sure to add in the fix for switchstate.

Multi-atom sync doesn't work yet. But yes, the UI was revamped so that things fit more properly and also tabs can be added, such as the Roles tab. The roles concept is quite nice, because you can, say, make a Shakespeare's play animation, and then load a new scene, add characters and assign roles, and the animation will still work.

If you can fix triggers, that's amazing. Keep in mind that you need the switch state trigger to specify animation and layer somehow. In the end, I think the "switch layer" trigger should definitely be removed, the "switch animation" might be removed and the "switch state" trigger should have more information. I am facing a similar problem right now with multi-character syncs, and I think I'll introduce state ids. If the ids are unique, then states can be identified more properly, without changing when name changes and without having to specify animation and layer. However, for triggers, the interface for using ids would be poor.

I am thinking about the best solution, and it seems that both issues would be resolved by a sort of "messages" system. There could be a "messages" tab, and, when the plugin instance receives a message, there is a bunch of options about what it is going to do with it. This seems actually quite a good idea because, albeit adding a new tab, the animations would then become untangled, with the plugin instance being entirely responsible for the evolution of the corresponding person atom's animation. In other words, without a messaging system, if you want to change the animation logic of a single person in a multi-character animation, you have to go through multiple atoms, because all of them affect that particular person through "switch state" triggers and syncs. With messaging, the other atoms AND triggers would only have a message string, and then the plugin instance on a particular character has all the configuration about what happens when that message is received. It exposes an interface.

Well, I'm thinking as I write and this solution seems to be the solution I was looking for. With this, character syncs and triggers will work through the same system (the messaging system), and this will remove a lot of the technical, conceptual and user interface issues faced by syncs and triggers. So you should probably wait for the next commits, where I'll put this system in place.

 

[cdgczta8]

Multi-atom sync doesn't work yet. But yes, the UI was revamped so that things fit more properly and also tabs can be added, such as the Roles tab. The roles concept is quite nice, because you can, say, make a Shakespeare's play animation, and then load a new scene, add characters and assign roles, and the animation will still work.

If you can fix triggers, that's amazing. Keep in mind that you need the switch state trigger to specify animation and layer somehow. In the end, I think the "switch layer" trigger should definitely be removed, the "switch animation" might be removed and the "switch state" trigger should have more information. I am facing a similar problem right now with multi-character syncs, and I think I'll introduce state ids. If the ids are unique, then states can be identified more properly, without changing when name changes and without having to specify animation and layer. However, for triggers, the interface for using ids would be poor.

I am thinking about the best solution, and it seems that both issues would be resolved by a sort of "messages" system. There could be a "messages" tab, and, when the plugin instance receives a message, there is a bunch of options about what it is going to do with it. This seems actually quite a good idea because, albeit adding a new tab, the animations would then become untangled, with the plugin instance being entirely responsible for the evolution of the corresponding person atom's animation. In other words, without a messaging system, if you want to change the animation logic of a single person in a multi-character animation, you have to go through multiple atoms, because all of them affect that particular person through "switch state" triggers and syncs. With messaging, the other atoms AND triggers would only have a message string, and then the plugin instance on a particular character has all the configuration about what happens when that message is received. It exposes an interface.

Well, I'm thinking as I write and this solution seems to be the solution I was looking for. With this, character syncs and triggers will work through the same system (the messaging system), and this will remove a lot of the technical, conceptual and user interface issues faced by syncs and triggers. So you should probably wait for the next commits, where I'll put this system in place.

Got it. Yeah that sounds good. For now, I did edit trigger timing but didn't touch SwitchState. Fixed the following issue:
- Animation goes from state A to B and back where A and B have 5 second duration
- ActionsOnEnterEnd (A) was triggered at the exact same time as ActionsOnEnterBegin (A) despite the two events being separated by 5 seconds
- Now these two event triggers are separated by the duration of the state

One thing I did notice was a bit of a drop in performance with the anchor fix as now there's some position updating to try every time through UpdateLayer. Maybe you can help optimize.

 

[haremlife]

Got it. Yeah that sounds good. For now, I did edit trigger timing but didn't touch SwitchState. Fixed the following issue:
- Animation goes from state A to B and back where A and B have 5 second duration
- ActionsOnEnterEnd (A) was triggered at the exact same time as ActionsOnEnterBegin (A) despite the two events being separated by 5 seconds
- Now these two event triggers are separated by the duration of the state

One thing I did notice was a bit of a drop in performance with the anchor fix as now there's some position updating to try every time through UpdateLayer. Maybe you can help optimize.

I am almost done with the multi-character sync. This feature is huge. After this feature, the only big feature remaining will be importing from Timeline. But, in other words, all big features for the plugin as a self-contained entity will be done. This will probably happen today. Then, the next step will be working on the first stable release, which is also going to be taken care of pretty soon. I'll check your solution for anchors and triggers. I'll add some sliders for default options, for animation speed, merge layers, etc.

I gotta say, the results are going to be astounding. I'm pretty excited to finally have my vision materializing. Thanks for supporting the development that early on. With the messaging system, your style of scene with multiple triggers is going to be pretty enhanced. And I'm hopeful the community will get pretty impressed after the first video demo.

 

[haremlife]

haremlife updated AnimationPoser with a new update entry:

UI Revamp, Roles and Messages!

In this update the first thing I did was change a lot in the UI design to make it less crowded.

Now, I added roles and a messaging system. Messages can be used to make multiple characters sync, which can be used for them to coordinate with each other or to react to each other. Roles can be used to easily reassign the messages in multi-character animation setups.

All of this is better explained in the plugin description (read the "UPDATE" section), which I'm going to update in the next few...

Read the rest of this update entry...

 

[haremlife]

@cdgczta8 I just commited a SendMessage trigger. It is in github but will only come here in the next release.

This replaces "SwitchState", "SwitchAnimation" triggers. You create a trigger with a message string and, in the Messages tab, you add a message handler for that string. This message handler is basically a transition. It has a list of source states, and a target state. The transition will happen if the message is received when the layer is in one of the source states. So, SwitchState to a target state is implemented by adding all states as source states, and the desired target state as a target. SwitchAnimation is implemented by choosing a state which is in another animation. The overhead is worth it because then the transition can be properly adjusted (transition duration, ease in and out, etc).

About anchors, I tried testing them and they work. What exactly was not working when you tested it? In the pull request, it doesn't seem like anything is changing in terms of anchors. Could you explain it a little better?

 

[cdgczta8]

@cdgczta8 I just commited a SendMessage trigger. It is in github but will only come here in the next release.

This replaces "SwitchState", "SwitchAnimation" triggers. You create a trigger with a message string and, in the Messages tab, you add a message handler for that string. This message handler is basically a transition. It has a list of source states, and a target state. The transition will happen if the message is received when the layer is in one of the source states. So, SwitchState to a target state is implemented by adding all states as source states, and the desired target state as a target. SwitchAnimation is implemented by choosing a state which is in another animation. The overhead is worth it because then the transition can be properly adjusted (transition duration, ease in and out, etc).

About anchors, I tried testing them and they work. What exactly was not working when you tested it? In the pull request, it doesn't seem like anything is changing in terms of anchors. Could you explain it a little better?

The anchor issue was happening because states were not updated unless a transition was in progress. This was fixed by adjusting the if/else logic in UpdateLayer to update the state no matter what.

The trigger timing issue was caused by selecting a transition as soon as the previous one ends instead of keeping myTransition = null until myClock >= myDuration. Again this was solved by editing UpdateLayer.

 

[haremlife]

haremlife updated AnimationPoser with a new update entry:

All the initially intended plugin features have been implemented now

This update adds a myriad of smaller features, which improve user experience a LOT!

-Added a SendMessage trigger.
-Made control controllers default to world anchor
-Macro time slider to slow down / speed up entire animation/layer
-Better morph sliders
-Settings for default values
-Random noise slider to transition tab
-Improved slider transition between states
-Added merge layers functionality

Read the rest of this update entry...

 

[haremlife]

haremlife updated AnimationPoser with a new update entry:

All the initially intended plugin features have been implemented now

>>>There was a versioning issue posting this update. If you downloaded it in the last half an hour, please download again the proper version I'm uploading now.

This update adds a myriad of smaller features, which improve user experience a LOT!

-Added a SendMessage trigger.
-Made control controllers default to world anchor
-Macro time slider to slow down / speed up entire animation/layer
-Better morph sliders
-Settings for default values
-Random noise slider to transition tab
-Improved...

Read the rest of this update entry...

 

[haremlife]

@cdgczta8 Thanks a lot for the contribution in this one! I got what you were saying. The pull request could be merged with no fixes. Excellent job!

 

[cdgczta8]

@cdgczta8 Thanks a lot for the contribution in this one! I got what you were saying. The pull request could be merged with no fixes. Excellent job!

Awesome! Will this be in v3.5 or v3.6?

 

[haremlife]

It was already released in v3.5!

 

[cdgczta8]

It was already released in v3.5!

Awesome! Haven't had a chance to try it out yet.

 

[iLikeSoup]

I finally have had some time to devote to 'getting-to-know' this plugin. I never used IdlePoser before so I dug into the available resources on how to use that which led me to understand the approach, or concept of this plugin, and with the wiki, it kind of came together enough to put a playtest together.

After that playtest, I do see potential for this plugin and I have a project in mind to make use of this plugin's Markov-chain functionality. Project you say? Markov-chain functionality you say? Well, let me ask you a question. What would you say is the next best greatest viewing related activity besides pole-dance? That's right, cheerleading!

**Cue flashback and somber music**

One unforgettable day, Coach said to me, "Johnny! You got too much jerky to do a proper herkie, there's no way you'll ever make the team! Get lost and for the last time, stop sneaking around the girl's locker room!"

It was if someone ripped my heart and dreams from me in one fell swoop

**Flashback fades...**

Sorry about that, bitter-sweet memories are tough to let go.

I do have a question:

How do I set the probability of a state to be chosen to play? In other words, how do I weight each state against the other states?

In my playtest, I have 1 animation, 1 layer with 8 states. 4 of the states I want to be chosen only 3-5% of the time. I tried using the 'State' tabs 'Default Transition Probability' slider with no success. Or, is it the Transition tab's 'Relative Transition Probability' slider (which also didn't seem to make a difference)? I'm not certain I understand the definition and use of these two sliders...maybe there is a different setting? I'm hopeful and almost certain this is an ignorant user issue

 

[haremlife]

Hey @iLikeSoup ! Sorry for the late response. Still a little bit in a hurry.

Quick response: if you want for that a state A to be visited only 5% of the time from neighboring states (which means, states that have a transition going into A), make sure that all transitions going into A have a 5% chance only of being picked.

In other words, there are no "state weights", only transition weights.

HOWEVER, there are state default transition probabilities. All newly created transitions that go INTO state A have a transition probability that is equal to the default transition probability of A.

So, if you create states A, B, C and D, and the default transition probability of A is 0.05, and the default transition probabilities of B, C and D are 0.95, and then add transitions, then state A will be always be chosen less than AROUND 5% of the time.

Now, I say "around" because these are not actual probabilities, but rather what is called unnormalized probabilities, or, more simply, they are weights. This is a technical distinction which should not impact UX: the plugin is to be played with, not calculated to achieve precise probability outcomes, after all. The only thing to take in mind is that having a "probability 1" doesn't mean it will be picked 100% of the time: if two transitions going out of a state have "probability" one, they will each be picked 50% of the time.

I'm being extensive for clarification, but this is very simple in practice. Set up default state probabilities according to the weights you'd like, then add transitions, and it should work fine. If something isn't working as expected, please report and if you are able to, give me a step-by-step to reproduce the issue. This will help very much. Thanks for trying the plugin out!