Plugins + Scripts multi force manager

[bqbq]

bqbq submitted a new resource:

multi force manager - force, multi force, force manager,

View attachment 534937

When you add individual force effects to each body part, the plugin list can get cluttered.
So I created a simpler plugin that makes management easier.


Of course, the functionality and UI behavior are pretty much directly adapted from the original Force plugin.

• dub

https://hub.virtamate.com/resources/force.25627/

Many thanks to dub...

Read more about this resource...

 

[TRSD]

Thank you for this. I have had the problem of a long list of force plugins before.
I've played around with the settings a bit and couldn't find a way to create a constant force. Only cycles. Would this be doable? I like to use forces for animating reactions so it's not pose-dependent like animating with controllers is.

 

[bqbq]

Thank you for this. I have had the problem of a long list of force plugins before.
I've played around with the settings a bit and couldn't find a way to create a constant force. Only cycles. Would this be doable? I like to use forces for animating reactions so it's not pose-dependent like animating with controllers is.

I’m having trouble understanding the difference between a constant force and a periodic force.
By ‘constant force,’ do you mean applying a single, one-off push rather than a repetitive motion, after which the body part returns to its original state?

 

[SlimerJSpud]

It seems like it's not possible to add the head or any other node twice. I'd like to have 2 different torque actions on the head on different axes with different periods. This makes motion look more random. I can do this with multiple instances of dub.force. Am I doing something wrong?

 

[bqbq]

So I made it support multiple instances.
I was considering designing it so that a single plugin could control one body part across multiple axes, but I’ll look into applying that after testing and review.

To keep the UI clean, I’d considered adding options like X+Y+Z, X+Z, X+Y, and Y+Z in the axis selection slot.

But since there are also reverse directions like −Z, −Y, and −X, the number of combinations gets large.

I need to think more about stability verification and how to represent all those combinations.

For now, I’ll use the plugin as it is in the scene I’m making.
I’m not sure I’ll improve it, but if I do, it will come in a later update.

It seems like it's not possible to add the head or any other node twice. I'd like to have 2 different torque actions on the head on different axes with different periods. This makes motion look more random. I can do this with multiple instances of dub.force. Am I doing something wrong?

 

[TRSD]

I’m having trouble understanding the difference between a constant force and a periodic force.
By ‘constant force,’ do you mean applying a single, one-off push rather than a repetitive motion, after which the body part returns to its original state?

Almost. Yes a single push/torque that keeps being applied with the set amount of force until you turn it off or adjust the force factor. It's like being able to control the muscle tension directly.
It's something I've learned about through BodyLanguage. It has randomized "constant force" to create idle movements. But it can't be adjusted or triggered on command which I'd like to do.

 

[SlimerJSpud]

So I made it support multiple instances.
I was considering designing it so that a single plugin could control one body part across multiple axes, but I’ll look into applying that after testing and review.

To keep the UI clean, I’d considered adding options like X+Y+Z, X+Z, X+Y, and Y+Z in the axis selection slot.

But since there are also reverse directions like −Z, −Y, and −X, the number of combinations gets large.

I need to think more about stability verification and how to represent all those combinations.

For now, I’ll use the plugin as it is in the scene I’m making.
I’m not sure I’ll improve it, but if I do, it will come in a later update.

What I do is apply force, usually torque, to the same body part, on different axes, and with different periods. Summing two axes would give them the same period.

 

[bqbq]

That happens when the axis vectors overlap. If you want the axes to move differently—for example, X-axis move → return → Y-axis move → return—you need to change how each axis operates. I know this because I’m testing it right now to see if it’s stable.

What I do is apply force, usually torque, to the same body part, on different axes, and with different periods. Summing two axes would give them the same period.

 

[bqbq]

What I do is apply force, usually torque, to the same body part, on different axes, and with different periods. Summing two axes would give them the same period.

I’ve tried repeatedly, and for now I think it’s not possible.

To avoid vector overlap, you’d need a process that restores the part exactly to its original position.
However, since the mini engine isn’t allowed, the system crashes as soon as the script is applied.
Even if that issue were fixed, during the rollback phase—when the body part returns to its position—the opposing axis forces would interfere, causing calculation errors and collisions.

It might work under certain conditions, but in most cases, problems would arise.

As a fallback, you could remove the mini engine and instead let VaM’s own environment handle returning the body part to its controller position.

But that introduces another issue: the return speed varies depending on the spring and damper values, creating many possible cases.
Even if you proceed with this approach, you’d have to manually set the timing before moving on to the next axis, which is cumbersome.

And if the timing isn’t exact, vector overlap will occur again, causing repeated diagonal movements regardless of whether it’s fast or slow.
There’s a reason why all the cycle-force plugins so far have restricted motion to a single axis.


This was a dumb attempt that didn’t need any warning from anyone.
The outcome was so predictable that even a beginner like me could see the problems.

 

[SlimerJSpud]

I’ve tried repeatedly, and for now I think it’s not possible.

To avoid vector overlap, you’d need a process that restores the part exactly to its original position.
However, since the mini engine isn’t allowed, the system crashes as soon as the script is applied.
Even if that issue were fixed, during the rollback phase—when the body part returns to its position—the opposing axis forces would interfere, causing calculation errors and collisions.

It might work under certain conditions, but in most cases, problems would arise.

As a fallback, you could remove the mini engine and instead let VaM’s own environment handle returning the body part to its controller position.

But that introduces another issue: the return speed varies depending on the spring and damper values, creating many possible cases.
Even if you proceed with this approach, you’d have to manually set the timing before moving on to the next axis, which is cumbersome.

And if the timing isn’t exact, vector overlap will occur again, causing repeated diagonal movements regardless of whether it’s fast or slow.
There’s a reason why all the cycle-force plugins so far have restricted motion to a single axis.


This was a dumb attempt that didn’t need any warning from anyone.
The outcome was so predictable that even a beginner like me could see the problems.

OK, thanks for checking. When I do this, I usually have a pose preset that sets everybody in the right positions, then a toggle that starts/stops the action.