Plugins + Scripts MFPButtDriver: MultiFunPlayer drive Person hip/butt bone movement

[nb9527]

nb9527 submitted a new resource:

MFPButtDriver: MultiFunPlayer drive Person hip/butt bone movement - Receive WS/UDP data from MultiFunPlayer, drive Person hip/butt bone movement

MFP Butt Driver​

MultiFunPlayer 6-Axis Bone Driver for VAM



Receive data via WebSocket (WS) or UDP from MultiFunPlayer, and drive character bone movement inside VAM. Compatible with funscript playback in MultiFunPlayer / OpenFunscripter.

Who this plugin is for​

1. OSR hardware users: Existing OSR VAM drivers rely on physical motion capture, which often results in repetitive or overly extreme movement. Hundreds of...

Read more about this resource...

 

[nb9527]

nb9527 updated MFPButtDriver: MultiFunPlayer drive Person hip/butt bone movement with a new update entry:

V2 - Motion Calculation Rework, Spring Mode & UI Improvements

V2 Update


View attachment 610717

1. Reworked motion calculation logic. Previously rotation pivoted around the center of Controller A and B with symmetrical swing. Now Controller B serves as the fixed pivot, and Controller A moves along an arc around B.
2. Added six gain parameters and an adaptive gain mechanism to offset weakened motion caused by joint pulling effects.
3. Added new Spring mode. This brings 12 extra adjustable parameters...

Read the rest of this update entry...

 

[rokoc]

great work! Very cool plugin. managed to try a few funscripts with it and reduce the default settings for smaller movements. got some pretty convincing results. find it hard to compare to original video/funscript/vam to see how true it is but it looks good enough.

only big issue im having though is pitch seems to be replaced with roll and vice versa. hip is rolling left to right when it should be pitching up and down. pov from a seated position model straddling you while facing you. *edited to add: this only happens in one of my existing scenes. just tried it in a new scene leaving everything in default positions/rotations and it pitches fine

also the hip will at times very quickly move away about 1ft and returns quite sharpish noticed its at flat spots in the funscript, where there is no action.

 

[AlphaCentauri]

I don't know if this makes sense since I just saw this plugin... Could you use it to generate short animation sequences to build from? For example, if you had a video+funscript source that had motions that you liked, could you connect the funscript to the model with this plugin, then record that basic animation. Then the idea would be to use that basic animation of desired movement and supplement with animating other non-controlled body parts using other tools. I hope that makes sense.

 

[nb9527]

great work! Very cool plugin. managed to try a few funscripts with it and reduce the default settings for smaller movements. got some pretty convincing results. find it hard to compare to original video/funscript/vam to see how true it is but it looks good enough.

only big issue im having though is pitch seems to be replaced with roll and vice versa. hip is rolling left to right when it should be pitching up and down. pov from a seated position model straddling you while facing you. *edited to add: this only happens in one of my existing scenes. just tried it in a new scene leaving everything in default positions/rotations and it pitches fine

also the hip will at times very quickly move away about 1ft and returns quite sharpish noticed its at flat spots in the funscript, where there is no action.

Thanks for your detailed feedback!

In previous versions, I implemented a simulated spring motion mode. Starting from V3, referencing BusDriver, I switched to VaM's built-in Physics Link system. Motion restoration should be far more accurate now. I recommend enabling Auto Gain if you encounter excessive movement amplitude.

Regarding the Pitch/Roll axis swap issue you encountered:My suspicion is that older motion modes altered the initial transform state of your character atom and changed its base orientation, creating the illusion that Pitch and Roll are swapped. This perfectly explains why everything works correctly in a brand-new scene — the character pose is fully reset there.

This issue rarely occurs under the new Physics Link mode. However, it may still happen when using Force or Direct mode. As a workaround, you can reset your character’s pose inside VaM, or use the Reset Origin function built into the plugin to mitigate the problem.

As for the sudden hip jumping on flat funscript segments, could you please test and see if this artifact still exists on V3? I have optimised parts of the interpolation and solving logic in this release, so the issue may have been improved. I will continue tuning the solver based on your test results.

 

[nb9527]

I don't know if this makes sense since I just saw this plugin... Could you use it to generate short animation sequences to build from? For example, if you had a video+funscript source that had motions that you liked, could you connect the funscript to the model with this plugin, then record that basic animation. Then the idea would be to use that basic animation of desired movement and supplement with animating other non-controlled body parts using other tools. I hope that makes sense.

That’s an excellent workflow idea!

In V3, I’ve added media player control and script-related capabilities. This shift made me realize MultiFunPlayer is no longer mandatory. MFP outputs smoothed T-Code designed for physical hardware like OSR toys, which isn’t ideal for native VaM scene building.

This is exactly why I’m developing FunSequencer as my next project. It will load funscripts directly, remove MFP as the middleman, support clip trimming, and work seamlessly with Timeline and MacGruber’s plugins.

One small difference in my vision: I plan to keep driving animations live from the raw funscript data in FunSequencer, rather than baking and recording static animations. This way, the same funscript file can simultaneously drive motion inside VaM and send data to control OSR hardware at the same time.

 

[AlphaCentauri]

That’s an excellent workflow idea!

In V3, I’ve added media player control and script-related capabilities. This shift made me realize MultiFunPlayer is no longer mandatory. MFP outputs smoothed T-Code designed for physical hardware like OSR toys, which isn’t ideal for native VaM scene building.

This is exactly why I’m developing FunSequencer as my next project. It will load funscripts directly, remove MFP as the middleman, support clip trimming, and work seamlessly with Timeline and MacGruber’s plugins.

One small difference in my vision: I plan to keep driving animations live from the raw funscript data in FunSequencer, rather than baking and recording static animations. This way, the same funscript file can simultaneously drive motion inside VaM and send data to control OSR hardware at the same time.

Sounds good - the less middleware you have to do the better. I'll be messing around with both approaches for sure.

 

[rokoc]

I don't know if this makes sense since I just saw this plugin... Could you use it to generate short animation sequences to build from? For example, if you had a video+funscript source that had motions that you liked, could you connect the funscript to the model with this plugin, then record that basic animation. Then the idea would be to use that basic animation of desired movement and supplement with animating other non-controlled body parts using other tools. I hope that makes sense.

funnily enough this was my first thought and to answer your question yes!

I've just tested recording in the timeline plugin while a funscript was playing and it works. im looking at best settings to reduce the number of keyframes now.

Thanks for your detailed feedback!

In previous versions, I implemented a simulated spring motion mode. Starting from V3, referencing BusDriver, I switched to VaM's built-in Physics Link system. Motion restoration should be far more accurate now. I recommend enabling Auto Gain if you encounter excessive movement amplitude.

Regarding the Pitch/Roll axis swap issue you encountered:My suspicion is that older motion modes altered the initial transform state of your character atom and changed its base orientation, creating the illusion that Pitch and Roll are swapped. This perfectly explains why everything works correctly in a brand-new scene — the character pose is fully reset there.

This issue rarely occurs under the new Physics Link mode. However, it may still happen when using Force or Direct mode. As a workaround, you can reset your character’s pose inside VaM, or use the Reset Origin function built into the plugin to mitigate the problem.

As for the sudden hip jumping on flat funscript segments, could you please test and see if this artifact still exists on V3? I have optimised parts of the interpolation and solving logic in this release, so the issue may have been improved. I will continue tuning the solver based on your test results.

the orientation thing wasnt that big a deal i had an idea it was something like that

as for hip jump you say v3 but i only see v2 which ive just tested it on and still have the jumping hip. happens at these points I have arrowed. first one animation comes to rest then a big Jerk at the arrow, hip returns then second arrow when the animation gets going again. originally thought it was mfp's return to home feature where if its idle it returns to center but sadly it wasn't that. watching the axis values in mfp when the controllers are jerking shows no change in the values.

 

[rokoc]

oh regarding the hip jumping, is it the plugin returning it to its "rest pose" ? i see it does something every second enabling debug. if i pause the script playback in mfp and just click on mfp script preview to advance to a specific time the controllers move correctly but then snap back to the rest pose i assume ?

 

[nb9527]

oh regarding the hip jumping, is it the plugin returning it to its "rest pose" ? i see it does something every second enabling debug. if i pause the script playback in mfp and just click on mfp script preview to advance to a specific time the controllers move correctly but then snap back to the rest pose i assume ?

Thanks for the observation! The plugin does not actively pull everything back to a fixed rest pose by design.

This snap effect is a side effect of V2’s custom spring solver. During long static periods, floating-point calculation errors accumulate gradually. Even if you jump to a position via MFP’s preview, persistent drift causes the hip to snap back shortly after.

I have tested V2 and V3 on a matching funscript. The snapping issue exists on V2 and disappears on V3.I uploaded V3 for review a few hours ago, and it will be public within hours after approval.V3 adopts VaM native Physics Link with static sleep functionality to resolve this drift problem. It would be great if you can verify this after V3 is released.