Plugins AnimationPoser

[SuperKingAbobo]

@haremlife Amazing to see work continue on this. Thank you for your effort.

Are you still planning to include Control point states featured in the original Idleposer?

 

[haremlife]

@haremlife Amazing to see work continue on this. Thank you for your effort.

Are you still planning to include Control point states featured in the original Idleposer?

No.

The intermediary states have become entirely unnecessary because of the path-finding features of the plugin. Originally, in IdlePoser, there where those states (called intermediary) that never transitioned back to the state from which the character had just arrived, and you could chain them so that the character went from an initial point to a final point and then back, necessarily passing through all intermediate points. This had a major drawback that you could have a maximum of I think 4 intermediary states.

Now with path-finding you just send a message telling the character to what state he should go, and he goes there, treating all states in the chain that connect the initial to the final state as intermediaries. This intelligent behavior replaced the need for special states, and also removes the "4 states" limitation.

However, I know your question was about Control Points.

It is important for the plugin to have interoperability with Timeline. Timeline calculates the control points automatically to build the Bezier curves. So just setting up keyframes or a sequence of states should be enough information for the plugin to reproduce the results of Timeline with internal calculations.

I have written in the description of the plugin, in the section "What is coming?" about these future intended features of interoperability with Timeline. Besides states, you will have also keyframes in the transitions. It is POSSIBLE that, in the keyframe edition tab, the control points could become available for editing in the future. I talked to AcidBubbles and he seems to intend on making the control points explicit in the export/import files. But it is highly possible that no one will ever need this once control points are being internally calculated as well as in timeline.

The thing I'm sure about is that a special sort of state called a "control point" is an overkill. If the control points are ever editable, instead of just calculated internally, they will be editable in the keyframes tab.

Notice that there are NO keyframes or curve fitting / interpolation in place now. Implementing this will be part of the last chapter of the AnimationPoser saga, which is this Timeline interoperability. When Timeline import/export and curve fitting are in place, I will release AnimationPoser as an entirely rebranded plugin: VamAutomata 1.0.

It is possible that I can do the timeline import soon, but I probably need a lot of help with the curve fitting.

 

[rernat]

Now with path-finding you just send a message telling the character to what state he should go, and he goes there, treating all states in the chain that connect the initial to the final state as intermediaries. This intelligent behavior replaced the need for special states, and also removes the "4 states" limitation.

So the message feature is the same like "switch state"-Trigger feature in IdlePoser?
The 4Intermediate State Limitation of IdlePoser I bypassed by chaining main states directional.

 

[haremlife]

So the message feature is the same like "switch state"-Trigger feature in IdlePoser?
The 4Intermediate State Limitation of IdlePoser I bypassed by chaining main states directional.

If the character must go back, like, bounce between State A and State B with a bunch of intermediary states in the middle, then having to add unidirectional transitions in the middle ends up screwing things. This was one of the first things that fucked me when I tried to use IdlePoser for making animations, some years ago.

If I'm not mistaken, right now there is a SendMessage AND a SwitchState triggers exposed by the plugin. The SwitchState also works through the path-finding mechanism.

The difference in SendMessage is that the same message can be interpreted differently by the character depending on what state he is currently in. So the character receives the message and decides to what state it will go, instead of the trigger deciding it for him. That is extremely useful for some contexts. But the SwitchState trigger is still there.

Yet about the intermediate state thing, when the Timeline import is implemented, the transitions will be composed of keyframes, which will give yet another way to accomplish the "bouncing back between states" in an intuitive fashion: the intermediary states just become keyframes.

 

[Saint66]

Hi again, this version works much more stable, thank you.
It could need some more trigger options

Is there a way to tell it directly something like "play AnimX LayerY"?
I have made 2 simple animations with each have only 2 layers. First animation is a simple "sit down", second contains hands moving on legs/knees.
So if I start playback, my person sits down and then tickles her legs, so far so good. But how can I tell the plugin to go back to Anim1/Layer1? I mean without another transition back to this, instead manually or via trigger.

I only see some very basic stuff in a trigger for this plugin, like "play/pause", "enable" and"load animation".

Ah, and by the way: if you save an animation, its now saved in a subfolder (VAM\Saves\PluginData\AnimationPoser\Animations). But if you trigger "load animation", it doesnt find the file because its only looking in the root save folder (VAM\Saves\PluginData\AnimationPoser). So I had to copy the files manually to load any saved animation.

Cheers,
Saint

 

[haremlife]

I only see some very basic stuff in a trigger for this plugin, like "play/pause", "enable" and"load animation".

There is the SendMessage trigger. It can be used to do anything really. The trigger sends a message, the character interprets that message to mean any action you set up in the Messages tab. BTW, the "load animation" trigger should probably be removed. Transitioning to the target animation (via the SendMessage trigger) is the way to go.

Is there a way to tell it directly something like "play AnimX LayerY"?

Notice that you never play a layer, you just play an animation: every layer of that animation runs in parallel. "Playing an animation" is something that will happen instantly as soon as you are in any state of that animation (unless the animation is paused), so "play animation 1" = "go to a given state of animation 1".

Notice also that the "SwitchState" trigger actually did have to be removed. That's because merely telling the name of the state (triggers only accept strings!) doesn't specify the layer and animation: multiple layers, animations, etc, often have states with the same names (such as "State1").

To solve this, messages are used instead. If you want to create a trigger that switches the character to State 1 of Layer 1 in Animation 1, merely write a SendMessage trigger with a given message string (say, "Go"). Then, in the Messages tab, create a message receiver for "Go" with all states as sources and the State 1 in Layer 1 of Animation 1 as target. When the trigger is pressed, the character receives the message "Go" and goes to that state.

Something that should be implemented very soon is a simple checkbox in the Messages tab to add all states of all layers of all animations as sources, so that this step becomes trivial. This is the most common case: you just want the character to receive a message and go to a given state, regardless of where it is currently at. However, the Messages tab is also flexible enough to allow you to define different target states for the SAME message depending on where the character is currently at (specified by the list of source states), so that it can respond intelligently to commands. This is crucial for doing more impressive stuff, such as the demo I set up with @ReignMocap .

I have made 2 simple animations with each have only 2 layers. First animation is a simple "sit down", second contains hands moving on legs/knees.
So if I start playback, my person sits down and then tickles her legs, so far so good. But how can I tell the plugin to go back to Anim1/Layer1? I mean without another transition back to this, instead manually or via trigger.

Yes! Like said above, a SendMessage trigger can be used to switch to any state of the target animation (in your case, Anim1). Notice that you can select any state of any layer of Anim1 as the target state, and it will do the trick for you.

In the future, if you need something more specific, like arriving at a specific list of states for EACH layer of Anim1, then you can use the "sync layers" functionality of a transition, combined with the path-finding mechanism. Well, don't be scared at that, because it is an advanced solution for an advanced use-case (although people doing interesting animation stuff will soon find how incredibly handy that is).

Ah, and by the way: if you save an animation, its now saved in a subfolder (VAM\Saves\PluginData\AnimationPoser\Animations). But if you trigger "load animation", it doesnt find the file because its only looking in the root save folder (VAM\Saves\PluginData\AnimationPoser). So I had to copy the files manually to load any saved animation.

Weird, I had tested that. Gonna check it out.

 

[Saint66]

@haremlife Thx for the detailed answer, thumbs up! Gives a lot of insight.

And I already tried using the message tab for this purpose, but I could not save any message (there is no error when trying to save, but just no file is created).

Another QOL thing: can you add the suffix *.animpose automatically? Because if you forget to add it to the savename, plugin cannot find it

Another bug: if I save a scene with some animations, a "Play" trigger does not work after loading. I have to open plugins UI and have to click play once manually. After that, triggers for play/pause are accepted, but not before this manual step.
Edit: If I load a saved scene with any animation, I have to load the animation manually, its just not there

 

[haremlife]

@haremlife Thx for the detailed answer, thumbs up! Gives a lot of insight.

And I already tried using the message tab for this purpose, but I could not save any message (there is no error when trying to save, but just no file is created).

Another QOL thing: can you add the suffix *.animpose automatically? Because if you forget to add it to the savename, plugin cannot find it

Another bug: if I save a scene with some animations, a "Play" trigger does not work after loading. I have to open plugins UI and have to click play once manually. After that, triggers for play/pause are accepted, but not before this manual step.
Edit: If I load a saved scene with any animation, I have to load the animation manually, its just not there

Some of these issues are weird, they don't seem to happen for me or @cdgczta8 .

Adding .animpose is definitely important. Maybe even a different extension for each kind of save. Also, the format of some save files is not ideal right now. These things should be improved immediately for future backward compatibility not to be broken. These issues are easy but not crucial for the plugin workings right now. I think I'll start adding a todo list at the github.

But the other issues don't happen to me for some reason. For example, animations do load on scene load. Which is very important for me because I tested the plugin on multi-character scenes that I had to reload multiple times.

I don't remember for sure if I tested saving and loading messages alone. But they do save and load with the plugin instance. Meaning they save and load on scene save/load, and also with the "save plugin instance" and "load plugin instance" buttons. Also you don't need to save the messages in order for them to work... Just add them, like transitions, etc. Saving and loading is for persistence.

Are you maybe using animations built with older versions of the plugin? If these problems persist we could investigate together.

 

[Saint66]

Some of these issues are weird, they don't seem to happen for me or @cdgczta8 .

Adding .animpose is definitely important. Maybe even a different extension for each kind of save. Also, the format of some save files is not ideal right now. These things should be improved immediately for future backward compatibility not to be broken. These issues are easy but not crucial for the plugin workings right now. I think I'll start adding a todo list at the github.

But the other issues don't happen to me for some reason. For example, animations do load on scene load. Which is very important for me because I tested the plugin on multi-character scenes that I had to reload multiple times.

I don't remember for sure if I tested saving and loading messages alone. But they do save and load with the plugin instance. Meaning they save and load on scene save/load, and also with the "save plugin instance" and "load plugin instance" buttons. Also you don't need to save the messages in order for them to work... Just add them, like transitions, etc. Saving and loading is for persistence.

Are you maybe using animations built with older versions of the plugin? If these problems persist we could investigate together.

yeah I come back to you if I find some more time, maybe sharing a vanilla example scene and investigating a little further. Thx for your attention!

 

[haremlife]

Some bugs were fixed, see the plugin description.

 

[fusrodah]

@haremlife bro, I can really feel that. I was doing pretty good without VAM, constantly running every other day, regular diet and sleeping cycles. I am still finding the life-fap balance right now, and I hope you can achieve this as well, especially when creating "stimulating" demo scenes.

I have been tweaking with this plugin recently and I love how this plugin organized in a way that makes switching states with different anchors back and forth very simple. One thing I dont like timeline is that the controls are not anchor-friendly and thus not reusable when you just switch root control a centimeter away. I was making my own editor with anchor support, but I am no coder and get overwhelmed by hundreds of atoms per character, you are saving my life here!

1. Is it possible to copy and paste states between animations by triggers? In particular, pasting values to root state, and update the transformations of all states in same layer.

e.g

layer1 root1 (60 0 0)
layer2 root1 (15 0 0) state2 (15 70 0)

copy layer1 root1 to layer2:
layer2 root1 (60 0 0) state2 (60 70 0)

I asked this because I want to develop animations based on different highheel settings. Right now I have to do a set of procedures to make it highheel compatible:

1. make foot pos and rot layer.
2. split layer into foot pos and foot rot layer.
3. foot rot layer sync with pos layer. (edit: sync state doesnt seem to be working. bug?)
4. duplicate foot rot layer and make highheel variance.

Repeat x anim variations based on x highheels, each layer with different roots.

But it seems a waste of duplicating states, if there are 20 anim layers with like 100 states, adding 1 extra highheel is duplicating 100 states!

If I can copy and paste the root, I can just prepare a list of different highheel rotations like:

state1 (15 0 0) state2 (30 0 0) state (60 0 0)

And copy whichever state I need, to which animation I need to play. Even better:
-a trigger to paste values to all roots or all states with equivalent name.
-a button to sync layers like sync states

2. If this is more complicated than I thought, perhaps a handy trigger function to capture the pose IRT for targeted states. This way I can "play" the highheel state, capture the value and paste to target roots. But this is only usable between subscene loadings, not usable when characters have animations that take on/off highheels.

Thank you for your effort again, I hope you can maintain life-fap balance as soon as possible!

 

[haremlife]

1. Is it possible to copy and paste states between animations by triggers? In particular, pasting values to root state, and update the transformations of all states in same layer.

There are some things I don’t understand in your example. But you didn’t mention the root state mechanism, and it sounds like it could help you to know about that.

The root state is the way to handle reusability using the plugin: you choose any state of a layer as the root state, clicking the checkbox in the states tab. Then, if you translate or rotate the controller in that state, and capture, then the same translation and rotation will be applied for every other state of the layer, effectively translating/rotating the entire layer.

Now if you want to have multiple translated/rotated versions of the same layer or animation, you just need to save, load and then reposition the root states.

You will still be duplicating states, although the workflow is easier. But this is what I don’t understand in your example, since having the controllers translated based on, say, foot position is exactly why there are anchors. All positions are relative to the anchors, so why making the foot position as the anchor doesn’t work?

 

[fusrodah]

There are some things I don’t understand in your example. But you didn’t mention the root state mechanism, and it sounds like it could help you to know about that.

The root state is the way to handle reusability using the plugin: you choose any state of a layer as the root state, clicking the checkbox in the states tab. Then, if you translate or rotate the controller in that state, and capture, then the same translation and rotation will be applied for every other state of the layer, effectively translating/rotating the entire layer.

Now if you want to have multiple translated/rotated versions of the same layer or animation, you just need to save, load and then reposition the root states.

You will still be duplicating states, although the workflow is easier. But this is what I don’t understand in your example, since having the controllers translated based on, say, foot position is exactly why there are anchors. All positions are relative to the anchors, so why making the foot position as the anchor doesn’t work?

Yeah, thats how i am doing currently, make an animation first, save/load to create duplicate, manually edit the root state (by the way loading anim doesnt work like loading layers that create new copies, it seems overwriting the existing anim).

But if there is an automated process on copy-paste state, handling highheel variance anim would be more efficient, just like how message works right now, instead of transform from source state to target state, you copy values from source state to target root state.

If no I can still cope with the current methodology right now, still 100 times easier than my old approach.

I am not quite sure what part you dont understand. Do you mean why I split foot pos and rot layer?

Here is why: If I include pos and rot in the same layer, the rotated root state also affects the direction of translation. For example:

if root state is rotated 45 x degree, then
state t(0 0 1) r(0 0 0) change to
state t(0 0.707 0.707) r(45 0 0)

Which is not what I want in most highheel animation. For example I am walking and the foot is moving 1 unit forward, I dont want highheel become 0.707 forward and 0.707 upward from the floor.

Thats why I need to split the foot rotation into new layer, which makes precise control in situation it need to.

 

[haremlife]

Yeah, thats how i am doing currently, make an animation first, save/load to create duplicate, manually edit the root state (by the way loading anim doesnt work like loading layers that create new copies, it seems overwriting the existing anim).

But if there is an automated process on copy-paste state, handling highheel variance anim would be more efficient, just like how message works right now, instead of transform from source state to target state, you copy values from source state to target root state.

If no I can still cope with the current methodology right now, still 100 times easier than my old approach.

I am not quite sure what part you dont understand. Do you mean why I split foot pos and rot layer?

Here is why: If I include pos and rot in the same layer, the rotated root state also affects the direction of translation. For example:

if root state is rotated 45 x degree, then
state t(0 0 1) r(0 0 0) change to
state t(0 0.707 0.707) r(45 0 0)

Which is not what I want in most highheel animation. For example I am walking and the foot is moving 1 unit forward, I dont want highheel become 0.707 forward and 0.707 upward from the floor.

Thats why I need to split the foot rotation into new layer, which makes precise control in situation it need to.

But why don't you just use the anchor system? If you need the positions of all controllers to be relative to the foot height, that's exactly what the anchoring system does. You could even create an invisible "empty" atom and use it as an anchor, adding AnimationPoser to it to capture multiple positions, and those positions could even be anchored to the person root atom. This way the entire animation would be anchored to something the position of which you can easily control. With this empty atom, you wouldn't need to worry about the rotation issue. And you could switch the states (positions) of the empty atom via the SendMessage trigger.

 

[fusrodah]

But why don't you just use the anchor system? If you need the positions of all controllers to be relative to the foot height, that's exactly what the anchoring system does. You could even create an invisible "empty" atom and use it as an anchor, adding AnimationPoser to it to capture multiple positions, and those positions could even be anchored to the person root atom. This way the entire animation would be anchored to something the position of which you can easily control. With this empty atom, you wouldn't need to worry about the rotation issue. And you could switch the states (positions) of the empty atom via the SendMessage trigger.

OK I tried to anchor the root animation. When I animate the anchor, the root does rotate but remaining state stays the same.

While I can anchor all states like the root, it doesnt work if the foot was anchored by another atom already, e.g. anchor to foot stride atom when walking, or anchor to hand when someone grab her foot.

In this case the foot stride atom or someone's hand can be anchored by foot rx atom, hierarchy would look like this:

-0 locator (move character)
--1 height (highheel)
---2 foot rx (highheel)
----3 foot stride (step forward)
-----4 foot state

or

----3 hand (grab her foot)
-----4 foot state

This works but seems complicating the hierarachy, especially when there are no visualized branch in VAM UI, showing which atom parented by which. I found this approach very tedious to scale up.

Is there an alternative to force update the transformation of same layer after the root state is animated? This way I dont have to care about how the main state messed up with other anchors, as long as the root state is properly anchored by highheel atom, I can fire a message to update main state transformation.

 

[haremlife]

OK I tried to anchor the root animation. When I animate the anchor, the root does rotate but remaining state stays the same.

Probably this is happening simply because the remaining states are still anchored to the person root.

I know, very inconvenient. This is like this since IdlePoser, although maybe MacGruber added a button to switch the anchors of all states at once in a more recent version of his plugin.

While I can anchor all states like the root, it doesnt work if the foot was anchored by another atom already

Do you mean that anchoring to the foot control breaks if the foot control itself is anchored? That is very unexpected.

Is there an alternative to force update the transformation of same layer after the root state is animated?

While we could go this route, probably the solution should lie within the anchor system.

 

[fusrodah]

Probably this is happening simply because the remaining states are still anchored to the person root.

I know, very inconvenient. This is like this since IdlePoser, although maybe MacGruber added a button to switch the anchors of all states at once in a more recent version of his plugin.

Well, I guess I have to dirty edit the .animpose file to change all foot anchors lol

Do you mean that anchoring to the foot control breaks if the foot control itself is anchored? That is very unexpected.

Nevermind, turns out I connected the wrong anchor.

While we could go this route, probably the solution should lie within the anchor system.

Anchor editing, especially anchors with higher-level anchor, for all states is quite error-prone imo. Evem with proper semantics I keep making mistakes.

I want to keep hierachy simpler. If there is a message firing route this would help.

Thank you for your prompt reply.

 

[haremlife]

Nevermind, turns out I connected the wrong anchor.

Does that mean it is working now? I don't quite grasp the higher-level anchor thing. If the controllers are anchored to, say, the foot controller, then not only other anchors, but whatever in the scene (physics, etc) affects the position of the foot controller, the controllers are translated/rotated according to the updated position of the foot controller.

But, like I said, an empty atom which you can control through multiple states could be better for you since it is not affected by the physics of joints for example.

 

[fusrodah]

Does that mean it is working now? I don't quite grasp the higher-level anchor thing. If the controllers are anchored to, say, the foot controller, then not only other anchors, but whatever in the scene (physics, etc) affects the position of the foot controller, the controllers are translated/rotated according to the updated position of the foot controller.

But, like I said, an empty atom which you can control through multiple states could be better for you since it is not affected by the physics of joints for example.

Yeah it kinda works now, thanks.

That higher level anchor thing relates to how I organise anchor order like what i said in the previous post (locator-height-foot rx etc). I am finding a good way to name those atoms so i dont get lost after a one or two week break.

For the sake of gameplay, sometimes I need 10 items shuffled into like 20 random places.

Because I cant find a convenient way to record atom transformation values and "paste" it to another atom other than NodeAlign plugin, I need rx ry rz and tx ty tz animations to control non-person atoms.

Since each t animation need 3 atoms, if i want to control the atom in a directions i need 4 atoms in total. 7 in a plane and 10 in a 3d space.

Each r animation need 4 atoms (controller and 0 120 240 states). If the said atom requires control on translation and rotation, it takes 22 atoms! I find this method way too complicated and have to stop working on that.

Right now I can rely on this plugin to achieve a certain degree of precision. For example I want to walk into a random place, i can break it into 10 states of tx and anchor 10 tz states, giving 100 positions on xz plane.

While this is good for an atom, what if there are 10 items in 20 random positions? Each atom have to load the plugin with 20 repeat states and messages, creating 200 states and 200 messages in total.

This is achievable but i feel like it impacts the performance.What if i have a NodeAlign-like plugin for non-person atoms, I can animate one atom only with 20 states and 20 messages, and 10 triggers to let 10 items align with that. Do you have any insight on this?

 

[haremlife]

Yeah it kinda works now, thanks.

That higher level anchor thing relates to how I organise anchor order like what i said in the previous post (locator-height-foot rx etc). I am finding a good way to name those atoms so i dont get lost after a one or two week break.

For the sake of gameplay, sometimes I need 10 items shuffled into like 20 random places.

Because I cant find a convenient way to record atom transformation values and "paste" it to another atom other than NodeAlign plugin, I need rx ry rz and tx ty tz animations to control non-person atoms.

Since each t animation need 3 atoms, if i want to control the atom in a directions i need 4 atoms in total. 7 in a plane and 10 in a 3d space.

Each r animation need 4 atoms (controller and 0 120 240 states). If the said atom requires control on translation and rotation, it takes 22 atoms! I find this method way too complicated and have to stop working on that.

Right now I can rely on this plugin to achieve a certain degree of precision. For example I want to walk into a random place, i can break it into 10 states of tx and anchor 10 tz states, giving 100 positions on xz plane.

While this is good for an atom, what if there are 10 items in 20 random positions? Each atom have to load the plugin with 20 repeat states and messages, creating 200 states and 200 messages in total.

This is achievable but i feel like it impacts the performance.What if i have a NodeAlign-like plugin for non-person atoms, I can animate one atom only with 20 states and 20 messages, and 10 triggers to let 10 items align with that. Do you have any insight on this?

This is like 1000x more difficult to follow than quantum mechanics for me. Perhaps we can chat in the inbox, with some screenshots and it would make more sense. However it would be good if other people could read the conversation since this goes out of the scope of what I personally intend to do with the plugin in the near future (because I'm just trying to deliver on what I promised before, and that is hard enough already, although it is 99% there now). That being said, copying and pasting controller positions is a basic feature that virt-a-mate lacks, and I have always been vocal about this, so I tend to be in your side here. Since we can't copy and paste controller positions, I have created the save and load and the root state translation/rotation features. So what I still don't get is why these features do not suffice. For example, copying and pasting a controller position can be achieved exactly if you simply save and load a layer with a state with that controller position, anchored to the world atom, or, if the anchor is anything else, you can load the relative position.

 

[fusrodah]

This is like 1000x more difficult to follow than quantum mechanics for me. Perhaps we can chat in the inbox, with some screenshots and it would make more sense. However it would be good if other people could read the conversation since this goes out of the scope of what I personally intend to do with the plugin in the near future (because I'm just trying to deliver on what I promised before, and that is hard enough already, although it is 99% there now). That being said, copying and pasting controller positions is a basic feature that virt-a-mate lacks, and I have always been vocal about this, so I tend to be in your side here. Since we can't copy and paste controller positions, I have created the save and load and the root state translation/rotation features. So what I still don't get is why these features do not suffice. For example, copying and pasting a controller position can be achieved exactly if you simply save and load a layer with a state with that controller position, anchored to the world atom, or, if the anchor is anything else, you can load the relative position.

Yes, now you mentioned that, I can S/L animations after I added AnimationPoser plugin to restore the position.
But the problem is this is not a triggerable process.

I created a very simple scene that demonstrates how 2 cubes shuffle from 4 positions.

It utilizes @JayJayWon 's actrandomizer, actgrouper and VUML. Each cube is anchored by _tx atoms has tx anim, and cube itself plays tz anim.
There are 2 messages per animations, bringing a total of 2cube x2anim x2message =8 messages. While this is achievable in low atom numbers and states, the numbers scales up fast. If there are 20 items, there are 20x2x2 =80 messages, and if there are 10 states per tx, ty and tz anim, its 20x3x10 =600 messages!

Now, if there is a NodeAlign plugin on each item (20 plugins in total), the animations and message firing can all be done on a dummy atom, and message can be kept at 3x10 =30 messages only, plus 20 random actions to tell each item to align the node. If the plugin is lightweight in performance (can only target empty atom type which reduces searching time), it would make a huge difference.

The best alternative that's not performance impacting is using @wgsoup move control's plugin. However only position control is triggerable, rotation is still mystically hard to manage in VAM.

 

[haremlife]

Yes, now you mentioned that, I can S/L animations after I added AnimationPoser plugin to restore the position.
But the problem is this is not a triggerable process.

I created a very simple scene that demonstrates how 2 cubes shuffle from 4 positions.

It utilizes @JayJayWon 's actrandomizer, actgrouper and VUML. Each cube is anchored by _tx atoms has tx anim, and cube itself plays tz anim.
There are 2 messages per animations, bringing a total of 2cube x2anim x2message =8 messages. While this is achievable in low atom numbers and states, the numbers scales up fast. If there are 20 items, there are 20x2x2 =80 messages, and if there are 10 states per tx, ty and tz anim, its 20x3x10 =600 messages!

Now, if there is a NodeAlign plugin on each item (20 plugins in total), the animations and message firing can all be done on a dummy atom, and message can be kept at 3x10 =30 messages only, plus 20 random actions to tell each item to align the node. If the plugin is lightweight in performance (can only target empty atom type which reduces searching time), it would make a huge difference.

The best alternative that's not performance impacting is using @wgsoup move control's plugin. However only position control is triggerable, rotation is still mystically hard to manage in VAM.

Saving and loading is not a triggerable process, but it is about set up: you set up the animations you need and switch between them via trigger when the scene plays. If the animations (positions and rotations) can't be known in advance, then you are at some level or other talking about dynamically generating the animations THEMSELVES in runtime, which is not exactly what the plugin is intended to do. While this plugin would be the best suited for that, and I always wanted that to work out (for example, characters avoiding collisions with other characters), this gets things into an unknown realm where a huge number of new features could become necessary in order for things to work out. That can be a very suiting thing for the VamAutomata plugin, which will be the new page of AnimationPoser development, but now it is very important to have the plugin clean from bugs, VamTimeline integration, basic curves, and community adoption.

I couldn't download the scene yet, maybe it makes more sense when I do.

 

[sardarm]

After a long wait, I'm glad you succeeded.

During the test, I found that the sync state of the new version could not work.

And the trigger of message is very strange. I can't find the transition time in the message page .

Take care of yourself and wait for your reply

 

[haremlife]

After a long wait, I'm glad you succeeded.

During the test, I found that the sync state of the new version could not work.

And the trigger of message is very strange. I can't find the transition time in the message page .

Take care of yourself and wait for your reply

There were some bugs fixed since the latest version. You can download the Custom folder at github and move it to your .var. But a new release is coming soon. I'll take a look at the sync. (UPDATE: confirmed sync is not working. Working on the fix. This is such an amazing feature when used properly! It many times replaces the need for multiple animations.).

About message. The message only needs to inform the target state. There is no "message transition" anymore. Just a target state. Then the plugin will FIND a PATH connecting the current state and the target state.

Say, there is State 1, State 2 and State 3, with transitions between State 1 and 2, and State 2 and 3, but NO transition between State 1 and 3. Then, if the plugin is in State 1, and a message arrives, telling it to go to State 3, it will follow the transition 1->2, and then follow the transition 2->3. If you want a direct path, that is only taken by messages, you can add a direct transition between the States 1 and 3, with 0 transition probability, and use the transition settings to specify duration, etc. Then that transition will only take place when a message tells it to go from 1 to 3. It is very neat

If there is NO path between State 1 and State 3, what happens is a "blend transition", which is a direct transition taking a default amount of time (I think 0.1s).

All that behavior also happens when you switch the state in the slider at the top of the plugin.

This is important so that scenes don't explode when states are very far apart. By keeping planned and carefully crafted paths between states, and always walking through those paths, you can move between states far away without characters colliding. Think about states where the character is in the bedroom, and states where the character is in the kitchen. If those state groups are always connected by a path that goes through the door, then the character never clashes with the walls when you switch states. You also don't need to add that intermediary path more than once: if any "kitchen" state is connected to any state that is connected to that path leading to the bedroom, then it will always use that path to get to the bedroom, with extremely minimal setup.

Hope that makes sense

 

[Saint66]

Would it be possible to add a random offset to transition duration?