Plugins AnimationPoser

[fusrodah]

I'm working on the last issues because I'll relaunch it as "VamAutomata", which is a more appropriate name, and I want "VamAutomata" to start in a fresh blank page.

Like I mentioned before in this thread, right now we have a markov chain as the basic engine, with a lot of interesting stuff added on top (indirect transitions, syncs, messages, avoids) that makes it less "memory-less" and more "context-full". Right now you can already create a layer without controllers to use as a counter or a timer. But the state engine can probably be recast into a turing complete machine. For example, float and string storage in a state is very easily feasible, with not much ui fuss. I'll probably keep getting ideas about how to add very powerful capability with the least amount of explicit interface (which is what I have been doing for a while), because I don't want to include something like a tab for boolean logic scripting. Actually since boolean logic is based on on and off gates, it seems that much if not all of boolean logic can already be modeled by presence/absence of transitions or by controllerless layers with "true/false" states. The AND operation, for example, can be modeled by two layers, each with two states, that puts avoids on two middle states in a chain from a third layer. So the path in the third layer is only unblocked ("1" or "true") when both of these states are in the "true" state. In practice, things tend to get more semantic if you are talking about a specific application.

I understand how it works as a timer or boolean gates, what I dont understand is how it is working as counter right now. Doesnt seem like there are something that I can trigger +1 in poser.

When I discover this markov chain concept, I soon find out how scalable it is. If it is one or two level boolean check, VUML gets job done pretty well. If there are 3 or more it starts getting hard to maintain.

Same for string contentation: a string with 3 parameters I need 5 strings, string1+2=3, string3+4=5... Now if there is a string of 5 parameters, I need to remember "string6 is supposed to be 4th parameter", or re-assign the string order, which both of them are very unfriendly for expand.

With the chain I can contentate strings easily, just send values to state 4 and rest is takem care by the controllerless anim. Also because there is some latency in changing parameters, a time-based approach is really good to make sure I am sending correct updated values for triggers or storing values.

OK, lets stop for those concept talk right now. Acutally I am here asking questions for indirectly transition lol

I suppose indirect transition is triggerless right?
Now I have state 1 that connects to ONLY 0-prob transitions:
1<>2<>3<>4<>5
and
1<>6<>7<>8<>9

And two extra indirect transitions 5<>1<>9

So basically it is supposed to jump from 5 to 1 to 9, back and forth.

Here are my questions:

After the animation state 1 the animation stopped, didnt jump to 5 or 9.

If I manually switch 1-5 back and forth it looks fine, 1-9 also fine. But 5-1-9 or 9-1-5, it always stopped at 1.

I had a remedy solution by collapsing states 234 and 678 into keyframes, but this feel like last resort, since if this wont allow me to have a set of varying intermediate steps, making things like 1-2a-3c-4b-5.

Any ideas?

Extras:

I notice that sending message to switch transition-less states, they still went through transition time. I find that out when my character sometimes dont synchronize her foot steps with body movement (they have varying transition time, foot 0.5 and body 0.01).

A visual hint when path finding on non-playing tab, e.g. "path finding...DONT EDIT!" in red background and "You can edit now." in green background. It is countless that I have to trace out which wrong states I have edited on, especially when there are a lot intermediates.

 

[haremlife]

how it is working as counter right now

Layer with, say, 10 states... Any time it receives a message, it goes to the next. You will very rarely need to count past 10... You will basically never need to count to, say, 100. Lots can be improved so that counters are easier to implement... But right now, they are entirely possible, even if not practical.

After the animation state 1 the animation stopped, didnt jump to 5 or 9.

Probably another bug of 3.9. I wish I had some help with all the little bugs, because I'm focusing on a single one which is much difficult than the others.

 

[cdgczta8]

I'm getting a weird issue where as soon as I create the first state in a layer, I get an error message saying "invalid state selected". Sometimes state#1 seems to not save when I save a plugin instance as well.

 

[haremlife]

I'm getting a weird issue where as soon as I create the first state in a layer, I get an error message saying "invalid state selected". Sometimes state#1 seems to not save when I save a plugin instance as well.

Does that happen with the latest github code?

 

[cdgczta8]

Does that happen with the latest github code?

Yeah it does as of about 4 hours ago. I started playing around with the code and it doesn't seem to be an issue with saving but with loading. I can try to post or send something for you to see it yourself. But essentially what seems to happen is that during loading, if you have states 1, 2, 3 and 4, states 2, 3 and 4 are fine but state 1 is overwritten with control/morph captures from state 4.

 

[fusrodah]

Hi, is it possible to have message system switching role atom in runtime?

I am anchoring the hand into, say, role [Main_chara]'s lGlute. Now, what [Main_chara] role is referred to, affects which girl's lGlute I am grabbing at.

While the role atom can be switched easily on UI, it has to be switched manually. If there are 3 girls 3 guys in a scene and each girl/guy has anchor touching others, you need 3x3 9 animation sets, each anchored to proper 2p situations like girl#2 guy#3 or girl#1guy#2 combo in runtime.

And that's just for 2p. For 4p, say 3girl1guy, the guy has 3!=6 situations if girls can be switched freely.

What I think better is an add on function in message system. Something like sending message of role1girl2, it would switch role#1's person atom to girl#2. The anchor system would then referring to the right person.

This would being down x animation sets into x messages.

 

[haremlife]

Hi, is it possible to have message system switching role atom in runtime?

I am anchoring the hand into, say, role [Main_chara]'s lGlute. Now, what [Main_chara] role is referred to, affects which girl's lGlute I am grabbing at.

While the role atom can be switched easily on UI, it has to be switched manually. If there are 3 girls 3 guys in a scene and each girl/guy has anchor touching others, you need 3x3 9 animation sets, each anchored to proper 2p situations like girl#2 guy#3 or girl#1guy#2 combo in runtime.

And that's just for 2p. For 4p, say 3girl1guy, the guy has 3!=6 situations if girls can be switched freely.

What I think better is an add on function in message system. Something like sending message of role1girl2, it would switch role#1's person atom to girl#2. The anchor system would then referring to the right person.

This would being down x animation sets into x messages.

Yes I’d like the anchor system to work without recapture as it does now. This is half of what you asked.

The other half, I guess would work through a “switch role” option in the messages tab. Source role, target role and done.

 

[fusrodah]

Yes I’d like the anchor system to work without recapture as it does now. This is half of what you asked.

The other half, I guess would work through a “switch role” option in the messages tab. Source role, target role and done.

Thank you for your reply.

Found two bugs in the non-playing tab, perhaps related to @cdgczta8 said in above post:

1. If you move the control without capturing, next time re-visit the same state via non-playing tab pathfinding, the state went to the moved position as if you have captured.

e.g. root 0 0 0 state 1 0 0

You accidentally move state into 2 0 0, without capture, go to root, then go to state, state would stay at the non-captured 2 0 0 position.

The wrong position corrects when you play the animation.

2. changing root transformation doesnt update other states, e.g. root 0 0 0 state 1 0 0, when root is changed to 0 1 0, state 1 doesnt change to 1 1 0.

Again, can be corrected by playing the animation once.

EDIT:

Question about sending messages from role system. If the target role has multiple anim poser plugin, which plugin it is sending?

Normally this isn't a problem, but I figure out I need multiple plugin for individual control, say my lHand groping action is animated on plugin#1, then it is applicable no matter I am standing, sitting or whatever on plugin#0, as long as the lHand anim isnt playing there.

Sending messages via trigger is okay though, but I want to know more via transition method, since it gives more precise control on when to send message and when not.

 

[haremlife]

1. If you move the control without capturing, next time re-visit the same state via non-playing tab pathfinding, the state went to the moved position as if you have captured.

That one is fixed in the github latest I believe.

 

[haremlife]

Question about sending messages from role system. If the target role has multiple anim poser plugin, which plugin it is sending?

No idea, but I discourage using multiple plugin instances. It is not hard to load a given layer (like the lhand layer in your example) for every animation.

 

[trashnet]

Finally this a very complex, but full of potential plugin, and after lot of trials and errors, I think I have more or less understood the mechanism, and I share some comments if it can be useful @haremlife :

The navigation from animation to animation is the best part of the plugin:
++ You can decide to go to the "animation walking" from the "animation sit" or "sleep" and the plugin will pick automatically the good state transition for getting up from the chair or the bed. And, with this mechanism, you cannot teleport from the seat to the bed without walking, because if no transition is done, you simply cannot go to animation "sleep" from "sit". So you don't have to care about "if... then ... else...", everything is natural.
-- BUT why can't I simply call an animation from an UIbutton? messages and roles are far too much pain to simply do what one can do from the plugin interface... That makes the final use of the plugin almost impossible with external triggers... You should be able to trigger an animation without specific state (in this case the plugin decides the possibility or not and the transition) OR to force a specific state (without caring about the possibility).
-- That is also a problem when you edit the states, you cannot switch to another state to which the transition is not already written... this is good when playing but no for editing + some states could be used aside from any transitions (which can be done with 0% transition chance, but makes things unecessary complex for an already complex plugin)

The "avoid" option is very good and easy to use:
When the person is sitting with a lollipop and already something else in the mouth, she cannot switch to the state with the lollipop in the mouth.

The term animation is totally avoidable:
I tried a lot of animations, and finally that's too much pain to define everything as a state, things are already too complex here. So using a simple state that call a segment or a specific timeline animation, which can switch automatically and randomely, is much more efficient. At the end I removed all the nodes from animation poser, using only the state transition machine.

anyway and again, thanks for this plugin.

 

[haremlife]

BUT why can't I simply call an animation from an UIbutton

The animation switch you described with path finding is actually fairly new, it didn't exist before, so the only option would be to have a "SwitchState", but then it would be complicated to tell the trigger which layer and animation is the target state in, since triggers go with a single string.

I guess a "SwitchAnimation" trigger doesn't cost anything. The only thing is that this animation switch path finding can become very tricky when there are multiple possible paths between two animations. The path finding looks for any path between any layer of the source animation and any layer of the target animation. So something very unexpected can happen. So if users start relying more and more on the "SwitchAnimation" instead of the "SendMessage" trigger, they might come here complaining about a lot of hard-to-understand and hard-to-replicate issues, that are actually just the path finding. The SendMessage trigger gives a lot more control, so this means people will get less confused.

Look at this issue at github: https://github.com/haremlife/AnimationPoser/issues/16 . When this enhancement is implemented, it will mean that, for every animation, you just need to implement one message. For example, say you have a "standing" animation. Then you create a message called "standing", with "standing" as the message string, and pick a target state. Now the SendMessage trigger already works if you just say "standing". It is a little bit of an overhead, but then you have the added benefit of picking a target state (or leaving the first one as a default). Unless that's a minus for you... specially if your animations are not fully connected. You mentioned both possibilities in your comment, but didn't definitively say which one is absolutely better.

"That is also a problem when you edit the states, you cannot switch to another state to which the transition is not already written"

That is actually surely a bug. Maybe fixed in the latest github release.

"So using a simple state that call a segment or a specific timeline animation, which can switch automatically and randomely, is much more efficient."

Are you aware that you can actually import the timeline animation? This makes a lot of difference if you want to reuse the setup in another scene or another person atom. And it makes a lot of difference if you need to reposition or morph the animations.

 

[trashnet]

The animation switch you described with path finding is actually fairly new, it didn't exist before, so the only option would be to have a "SwitchState", but then it would be complicated to tell the trigger which layer and animation is the target state in, since triggers go with a single string.

I guess a "SwitchAnimation" trigger doesn't cost anything. The only thing is that this animation switch path finding can become very tricky when there are multiple possible paths between two animations. The path finding looks for any path between any layer of the source animation and any layer of the target animation. So something very unexpected can happen. So if users start relying more and more on the "SwitchAnimation" instead of the "SendMessage" trigger, they might come here complaining about a lot of hard-to-understand and hard-to-replicate issues, that are actually just the path finding. The SendMessage trigger gives a lot more control, so this means people will get less confused.

Look at this issue at github: https://github.com/haremlife/AnimationPoser/issues/16 . When this enhancement is implemented, it will mean that, for every animation, you just need to implement one message. For example, say you have a "standing" animation. Then you create a message called "standing", with "standing" as the message string, and pick a target state. Now the SendMessage trigger already works if you just say "standing". It is a little bit of an overhead, but then you have the added benefit of picking a target state (or leaving the first one as a default). Unless that's a minus for you... specially if your animations are not fully connected. You mentioned both possibilities in your comment, but didn't definitively say which one is absolutely better.

Thanks for your detailed answer! I agree (and I'm using it) about the send message thing, and I understand that it gives "more" control.
Still, simple switches are rapidely taking too much time to configure messages in each animation and state + it becomes easy to forget some messages or to make a mistake in one, and finally it can be also a source of headaches and bugs... Another bug that appears with sendmessage, is when you change a state or layer name, it does not change in the sendmessage configuration, another headache avoidable with the proposed method.
This simplification could give also easily more diversity (you could use the defined and multiple random transitions for one state to another animation, while now a message defines only one specific state as a target).
So I prefer the simplest way without sendmessage.
But ok I was only reasonning with one main layer. So maybe there's no simple solution with this layer thing, though it works quite well in the plugin interface when you switch manually to another animation (and the trigger could do the same thing people are already experiencing while using the plugin).

A suggestion about your comment in github, rather than add all states, you could have the choice either to include or exclude the selected states.

"That is also a problem when you edit the states, you cannot switch to another state to which the transition is not already written"

That is actually surely a bug. Maybe fixed in the latest github release.

"So using a simple state that call a segment or a specific timeline animation, which can switch automatically and randomely, is much more efficient."

Are you aware that you can actually import the timeline animation? This makes a lot of difference if you want to reuse the setup in another scene or another person atom. And it makes a lot of difference if you need to reposition or morph the animations.

I'm using the latest github version.
About the timeline import, I didn't tried, and I certainly should as there are many excellent things in your plugin.
Though, after lot of time to understand the basics, I'm now keeping timeline in parallel as it works very well together. Maybe later I will use more a combination of timeline and animationposer for nodes. Though my experience until now is that I can do animations with animationposer, everything works, but it's too long while I obtain more fluid and complex animations with simplicity in timeline.

2 last suggestions :
- it will be useful to have make a button to copy a state to another animation, let's say for a transition state, and you want to keep all the state triggers, configuration, etc...
- in the screen animation play, a debug option which displays what is happening : the current state, the chosen transition, etc... normally it appears above, but with the layer thing we cannot see which state is selected.

Thanks

 

[haremlife]

Still, simple switches are rapidely taking too much time to configure messages in each animation and state + it becomes easy to forget some messages or to make a mistake in one, and finally it can be also a source of headaches and bugs

If things are working properly, you would just need to create one message for each animation, with the animation name as the message string, and choose a target state. You do this once for each animation, and never worry about that again.

I think focusing on this and on the bugs you mentioned right after will be less error-prone, because the switch animation thing can bring much more bugs or false alarms than that. It seems easy at the first glance, but actually there are much more questions and potential issues. When you tell the plugin to switch to a given animation, not even the target layer is specified, so the plugin might find a path to a state in a layer that you didn't intend it to, and that might be very hard to debug if you are not me and you didn't think about this and don't know what you are looking for.

This simplification could give also easily more diversity (you could use the defined and multiple random transitions for one state to another animation, while now a message defines only one specific state as a target).

Yes... I get that... But it seems overly specific if you think about it. When switching to an animation, without specifying a target state, it can only get to the surface states. So... A surface state is a state with a transition to another animation, so you can think of it as being in a "surface" of the graph that composes the states of a given layer of the animation. Although "switch animation" triggers could be used to arrive at different states of the target animation depending on the current state with minimal setup, these states look to me much more accidental targets than intended targets, because "surface states" are often states that some way or another are a first step towards moving to another animation; in other words, they are "transitional", so they are rarely good target states. It is hard to imagine a situation where someone specifically intends such and such surface state to be a conditional target, and therefore benefits from the "switch animation" trigger's ability to move to different states based on the current animation... It seems a very specific case. Much more often, you do want the trigger to lead to a different target state depending on the current state, >>which is why many different messages can share the same message string, but different sources and targets<<. The difference is that you are then not limited to the surface states.

Since right now you are mostly using the plugin to trigger Timeline animations, it seems that your animations have only one state or very few states, and only one layer. So these things are not noticeable for you. Btw, you should probably have only one animation. Essentially you are using animations as if they were states. You only need different animations when you have different combinations of controllers for each layer! For example, if you want a given character action to have the head and arms moving independently, and then another action to have the head and arms moving together predictably, only then you need different animations. For every other case you just need one animation, and you can do everything with a state chain. This is your case since you said you are just using the plugin as a state machine. A state machine is one animation, one layer. Multiple layers are for multiple parallel-running state machines, and multiple animations are for when you need to change the state-machine-to-controller relation.

 

[haremlife]

while I obtain more fluid and complex animations with simplicity in timeline.

Timeline is intended for doing the keyframe animations, and animationposer is intended for stringing them together in more complex patterns that can be saved, reloaded, transposed, rotated and stretched. In other words timeline creates the timelines for some "actions" (walking, kissing, etc) and animationposer can be used to build an automaton, a robot that randomly walks paths composed of those actions and can also be controller with messages, cooperate and interact with other characters, etc.

This all would be true if there was only one layer and one animation. Just add all controllers to the layer and do all that above. The layers/animations thing is useful when you need independent movements for different parts of the body, different morphs, etc, and the goal of this is to create interest and realism. A 2 minute animation in timeline repeats itself after, well, 2 minutes. Now one 2 minute animation for one set of controllers and another 35 second animation for another set of controller only repeats itself after 7 minutes. With added randomness pertaining to a specific layer, it might take say half an hour for things to start looking like deja-vu. Notice that this is different from randomized clips: having *intra-layer* randomness means the difference between "randomly switching deterministic and predictable animations" and "playing random animations". So in simple terms, it is simpler to create a 2 minute animation in timeline, but in animationposer you can create a 3-hour animation with the time it would take you to create two or three 2 minute animations in timeline.

So there are these two sides of the plugin, the macro and the micro... But for the maximum benefit you should use timeline together with animationposer, because animationposer doesn't have a powerful keyframe editing tool (although it has the capacity to turn keyframes into states, which allows you to manipulate keyframes with in-game objects serving as anchors and thus stretch/morph the timeline). So timeline is used to create the transitions between states in a given layer, animationposer to organize the markov-chain of states which is a layer, to run layers together (with intra-layer randomness), to compartmentalize all of that inside a switchable animation, to automate, find paths, organize messages, roles, sync multiple characters, allow them to avoid collisions, to morph, translate and rotate animations, to anchor animations, and to save and load the entire robot behavior or reuse only parts of it.

 

[trashnet]

...
Since right now you are mostly using the plugin to trigger Timeline animations, it seems that your animations have only one state or very few states, and only one layer. So these things are not noticeable for you. Btw, you should probably have only one animation.
...

You are right. After a first full scene working only with animationposer (which follows more or less your description of the correct use), I started to "oversimplify" and remove states. And certainly at the end I could use only one animation and multiple states, though it's also a practical way to classify states by location. In the seat animation I call various states which happen on the seat.

I found another advantage of this (mis)use of the plugin with the definition of a layer called "message" in each animation. So I have multiple states in the layer "body" (control of the person), and only one in the layer "message". Then rather than to specify all the states of "body" to transit to another animation, I just specify the one state of the layer "message". That works, and that solves the question about the selection of multiple states in the "sendmessage" panel (easier to maintain when adding states, even if it's a few).

And ok with you about the possibility to reuse and realize more complex combinations of animations, I will certainly try it harder later

 

[fusrodah]

No idea, but I discourage using multiple plugin instances. It is not hard to load a given layer (like the lhand layer in your example) for every animation.

I see the reason of having only one instance after I read your discussion above, but there is a challenge I am facing with.

Technically speaking, loading a given layer is okay, as long as there is no layer that (has the same control) is competing the controller. And I am doing that.

But it is not a matter of easy or hard loading the layer. What eats up editing time is the subsequent procedure.

For example, if you want a character's limb to have some generic movement regardless of what main animation is playing, you have two options:

1. Having four layers, lHand/rHand/lFoot/rFoot, relying on sync and avoids. So for example, a girl in a lay down animation, both hands supoorting on the floor, gesture depend on how head moves:
-For every transitions on head, you need sync, e.g. telling plugin to go laydown_lHand_01, when laydown_head_01 is arrived.

Now when your lHand is grabbing:
- You have to place avoids on laydown_lHand_XX, and a message from laydown_lHand_XX, to generic_lHand_grabbing.

When you finish grabbing:
- lift the avoids

This basically requires each animation to split into extra 1-4 layers, extra 1-4 sets of sync and extra 1-4 sets of avoids.

I have the experience of extra layers and sync part in an animation. The back and forth capturing a few individual layer, editing transition time waiting time prob, adding syncs is...really demanding.

AND you have to wait for the pathfinding to stop. Or else you spend double or even triple time fixing that mysterious intermediate state that you cannot properly recall after you have worked for 6-9 hours non-stop. At the end you cant find where it breaks your animations, you have to reload a save, losing your effort even more...sigh

If this is being done on only one master layer, the editing procedure would be a big step closer to timeline (another step is the lack of keyframe graphic UI, but that's not what I am going to discuss here).

Which, I think is possible in option 2.

2. Another approach is related to what you mentioned in multi layer enhancement, but instead of having a overidding order inside the layer, you have the order for inter-layer as well.

This is saving up a lot of workload, technically speaking you can have a master layer (with every controller there) doing basic pose setup, overidded by individual lHand rHand layer etc.

And this is why I am using multiple instances here. Maybe this is not intended, but overidding can be achieved to a certain degree.

 

[haremlife]

This basically requires each animation to split into extra 1-4 layers, extra 1-4 sets of sync and extra 1-4 sets of avoids.

Well, the reason to have multiple animations is exactly for when the layers must cooperate vs act independently. Don’t let the name “animation” fool you. You are doing thing the hard way: before syncs and avoids existed, “animations“ were created to solve this issue. This might sound counter intuitive, but you can have multiple actions that transition between different “animations” when you need the controllers to sync vs run independently. Instead of syncs and avoids, just transition to the other animation when you need to change the dependence relationship between the controllers.

In other words, your might even have it so that your real “actions” (sets of states that are connected with each other) each span the same two animations, so that there are multiple disconnected pieces of the graph each of which has both states in one animation and in the other. Switching “actions” is then more semantically meaningful than switching animations.

Whether “animations” align with your actions or not is just a matter of whether your controller dependencies align with the semantic actions or not.

 

[haremlife]

use of the plugin with the definition of a layer called "message" in each animation. So I have multiple states in the layer "body" (control of the person), and only one in the layer "message". Then rather than to specify all the states of "body" to transit to another animation, I just specify the one state of the layer "message"

That pattern is genius I hope to make that enhancement in the messages tab though, so that this extra layer becomes unnecessary.

 

[haremlife]

AND you have to wait for the pathfinding to stop.

Another necessary enhancement is to add a checkbox to disable the path finding, similar to the one that disables blending when switching states.

 

[haremlife]

This is saving up a lot of workload, technically speaking you can have a master layer (with every controller there) doing basic pose setup, overidded by individual lHand rHand layer etc.

That’s really interesting… Like I said animations were created for that, but this could be a separate mechanism, which could be more intuitive. Could you explain a little better how it would work? Because you want that other layer to sometimes override, sometimes don’t, right?

 

[fusrodah]

Well, the reason to have multiple animations is exactly for when the layers must cooperate vs act independently. Don’t let the name “animation” fool you. You are doing thing the hard way: before syncs and avoids existed, “animations“ were created to solve this issue. This might sound counter intuitive, but you can have multiple actions that transition between different “animations” when you need the controllers to sync vs run independently. Instead of syncs and avoids, just transition to the other animation when you need to change the dependence relationship between the controllers.

In other words, your might even have it so that your real “actions” (sets of states that are connected with each other) each span the same two animations, so that there are multiple disconnected pieces of the graph each of which has both states in one animation and in the other. Switching “actions” is then more semantically meaningful than switching animations.

Whether “animations” align with your actions or not is just a matter of whether your controller dependencies align with the semantic actions or not.

I think this is a trade-off, syncs and avoids vs animations with different controller dependencies, which can be a lot, if we talk about limbs there are 2^4=16 combos already, now if you want some arbitrary layer like head-lHand or chest-arm-hand, this number can be huge.

That’s really interesting… Like I said animations were created for that, but this could be a separate mechanism, which could be more intuitive. Could you explain a little better how it would work? Because you want that other layer to sometimes override, sometimes don’t, right?

Lets say you have a master layer with all controller there, with overridding order of 0, the basic order.

You create a few state for walking, connect them as you wish, make avoids if needed, e.g. if you hit a wall you avoid all walking states. No more syncs editing means saving up a lot of time.

Now suppose you are picking up a rose, you create a new layer call lHand, with overridding order of 1.

This would override the action of, say swinging lHand in the master layer, while rest of the controllers keep working as normal.

What we need is an overriding message, and then we have a walking guy picking up a rose. Another overriding message from picking up a rose back to generic walking action.

Next when we made a guy squatting, we dont even need extra messages, sending the overriding message we created for walking, we now have a squatting guy picking up a rose.

What an overriding message is composed of? An overriding order, target layer and an arrival state. -1 means never override, order of 2 always override order of 1, sort of that.

Technically speaking, the plugin sorts out overriding order per controller, handles the in-out states of the highest, neglecting any I/O in lower order. If there are same order for a controller (which shouldnt be expected, but in case of error), then it goes for alphabetical order of layer name, pop out an error message or so.

Whenever there is a change in highest order in the middle of transition, say, we are in transition of walk_01 to walk_02, and receive a message of shifting lHand layer overriding order from -1 to 1, where the arrival state is lHand_picking_01.

Now we wait for arrival of walk_02, use the lHand controller in walk_02 as source, and lHand_picking_01 as target.

Reverse is similar, say its next state is lHand_holding_02, and overriding order is going from 1 to -1, we use lHand_holding_02 as source, and the lHand controller in walking action as target.

Arrival state only applies as target state when the overriding condition matches, using as an entering state of that layer.

Basically, a layer with low overriding order works like a controllerless layer. You can still send messages, place/lift avoids, triggering things, etc. Just it is not used in animation and working behind the scene.

I believe this would streamline the process a lot, it is also very friendly for any editing reversal. The master layer work like editing process in timeline, but you can always create a new layer fine-tuning the action, experimenting on new anchors etc. Anytime you dont feel satisfied for the arbitary layer you created, you can simply place an -1 on it to work later on, without destroying the original animation.

 

[haremlife]

I think this is a trade-off, syncs and avoids vs animations with different controller dependencies, which can be a lot, if we talk about limbs there are 2^4=16 combos already, now if you want some arbitrary layer like head-lHand or chest-arm-hand, this number can be huge.



Lets say you have a master layer with all controller there, with overridding order of 0, the basic order.

You create a few state for walking, connect them as you wish, make avoids if needed, e.g. if you hit a wall you avoid all walking states. No more syncs editing means saving up a lot of time.

Now suppose you are picking up a rose, you create a new layer call lHand, with overridding order of 1.

This would override the action of, say swinging lHand in the master layer, while rest of the controllers keep working as normal.

What we need is an overriding message, and then we have a walking guy picking up a rose. Another overriding message from picking up a rose back to generic walking action.

Next when we made a guy squatting, we dont even need extra messages, sending the overriding message we created for walking, we now have a squatting guy picking up a rose.

What an overriding message is composed of? An overriding order, target layer and an arrival state. -1 means never override, order of 2 always override order of 1, sort of that.

Technically speaking, the plugin sorts out overriding order per controller, handles the in-out states of the highest, neglecting any I/O in lower order. If there are same order for a controller (which shouldnt be expected, but in case of error), then it goes for alphabetical order of layer name, pop out an error message or so.

Whenever there is a change in highest order in the middle of transition, say, we are in transition of walk_01 to walk_02, and receive a message of shifting lHand layer overriding order from -1 to 1, where the arrival state is lHand_picking_01.

Now we wait for arrival of walk_02, use the lHand controller in walk_02 as source, and lHand_picking_01 as target.

Reverse is similar, say its next state is lHand_holding_02, and overriding order is going from 1 to -1, we use lHand_holding_02 as source, and the lHand controller in walking action as target.

Arrival state only applies as target state when the overriding condition matches, using as an entering state of that layer.

Basically, a layer with low overriding order works like a controllerless layer. You can still send messages, place/lift avoids, triggering things, etc. Just it is not used in animation and working behind the scene.

I believe this would streamline the process a lot, it is also very friendly for any editing reversal. The master layer work like editing process in timeline, but you can always create a new layer fine-tuning the action, experimenting on new anchors etc. Anytime you dont feel satisfied for the arbitary layer you created, you can simply place an -1 on it to work later on, without destroying the original animation.

From a "product" perspective I have some things I'd like to discuss for the implementation, because I think you can accomplish the same with less complexity, but the basic idea makes sense. However it is unlikely that I myself am going to make new features for the plugin soon. If you want to develop that feature I'm here to help you get started.

 

[fusrodah]

From a "product" perspective I have some things I'd like to discuss for the implementation, because I think you can accomplish the same with less complexity, but the basic idea makes sense. However it is unlikely that I myself am going to make new features for the plugin soon. If you want to develop that feature I'm here to help you get started.

I can understand, I see the plans on github. What do I need to get started though, my coding knowledge is kinda limited (just MEL)?

 

[haremlife]

I can understand, I see the plans on github. What do I need to get started though, my coding knowledge is kinda limited (just MEL)?

Oh, I thought you might be a coder like a lot of people here. C# might be pretty scary for someone used with only a purpose-specific scripting language like MEL.

Well like I always say to people here... Lots of people come and tell me I should release the tutorials and so on... But they don't see I'm very limited in terms of what I can do, given that I don't even make money from virt-a-mate... They should ask the plugin developers they support on patreon: "why don't you help with animationposer, which is something that can be so transformative to the virt-a-mate ecossystem?". Initially I never imagined I could do anything at all without the help of virt-a-mate sponsored plugin developers. I think people should incentivize them to help with animationposer.

That being said, let's see how things go. I feel swamped right now under the currently reported bugs at github (and here), so it seems like a lot of work to have things working smoothly until the next version. But the feature you asked is probably not difficult.