Wiggle bones (a jiggle bone implementation for 2.8)

Okay - doesn’t work on RC1 on Windows, either.
Let’s see if it’ll work with the actual release. Until then baking the bones works just fine.

do you have a new recent version?

in the first post there is a small update that addresses an error when disabling and re-enabling the plugin, however the larger issue with rendering is something I’m still trying to figure out.

I was poking around in the code a bit on the weekend. when an f12 render is initiated, it seems to trigger and additional frame change jiggle event (even if you’re rendering the frame you’re already on) but the output appears as if no jiggle is being applied. also I managed to get a crash when repeatedly attempting different things, although I can’t even seem to get a reliable cause for that.

does anyone with coding knowledge know of any obvious differences in render events that could be causing these issues?

1 Like

Thanks for the cool Add-on.
I got a trouble with “Bake Action” for Bones which has ‘Wiggle’ applied, thing is, it took me so long and even froze my computer sometimes especially if it’s about hair. Do you have any idea of this? (I’m using Blender 2.8 btw)
Thank you so much!

This is a great addon - not super -fast, but once it’s set up, it saves a lot of time animating secondary motion. Baking seems to be a bit of a PITA, but that could be my lack of knowledge.

For anyone who is having problems with this baking, what I did was separate the jiggle bones animation from the rest of the animation (in my case, I was using mocap data) by first opening the NLA editor with my armature selected, and clicking on the icon to “Push Down” the armature animation (without the jiggle bones active).

Next, go into Pose mode, select your jiggle bones (make sure it’s active) and search for and invoke the Bake Action command. Once the dialog is open, you can choose “selected bones only” and bake the scene. The new animation will be created as a new track in the NLA editor on top of your previous animation (I would “Push” that one down, too). Now, you can de-activate the Wiggle Bone option in the Scene panel, and render to your heart’s content. If you want to change settings, you’d probably want to delete the jiggle bone track (or mute it), change your settings and rebake the scene.

All in all, a bit of a PITA, but do-able.

Thanks for putting it out there :slight_smile:

1 Like

Hey JoeW, yeah ideally i’d love to have the add-on work for renders without baking, there’s just some nuance to how render contexts and frame change events that i’m missing. I’ll keep trying to see if i can find a work around (although baking is probably always going to be necessary for things like render farms).

In the mean time, i don’t know if it helps with your baking workflow at all, but two thoughts spring to mind:

  • You shouldn’t need to disable wiggle bones when pushing the base animation down into a strip (unless you were keying the variables of the wiggle bone, but even then those keyed values would likely get pushed down whether the wiggle effect itself was active or not)

  • Once you push the base animation down onto a strip, if you set the animation data (not the strip) blend mode from replace to additive before you bake the wiggle, it actually isolates the wiggle effect further to just the offsets from the base animation layer. So if you needed to make small tweaks to the base animation, you might even be able to get away without having to-rebake the wiggle layer)

Last, I’m curious to hear more details of your and Quang_Vo’s notes about the add-on feeling overall a bit slow. Since the original (and fantastic, I might add) ‘Jiggle Armature’ was updated for 2.8 shortly after I started this project, one of the reasons I kept working on this was I found jiggle armature would slow down in a few cases.

For example on a heavier armature like rigify, I found even adding a single jiggling bone would introduce substantial lag on my machine, so I tried to make my add-on ignore rig complexity as much as possible. If there are any other gotcha’s I’ve overlooked I’d be eager to look into them

Quang_Vo, when you mention slow baking on hair, have you created a large number of jiggle bones, or is it even in the simple case like a few bones behaving like a ponytail? Blender in general tends to not give much feedback when baking actions, and I find baking a large number of bones or a long animation timeline can take a while with or without any jiggle bones applied. Just trying to isolate where the lag is likely being introduced!

1 Like

Hi Shteeve,

Thanks for the reply! In regards to why I didn’t use the updated Jiggle bones, I couldn’t get the script to load in the latest V2.8, and then happened to stumble across your post - so Wiggle Bones got the nod. I’m relatively new to Blender, but not 3D - so I was working on rigging and wondered how best to handle secondary motion. Some packages work well with soft-bodies, but I’ve always found dynamic bones to be easier to control and work with. I’ve used them in XSI and Lightwave, but the best implementation I’ve ever used was in Hash’s Animation:Master (yeah, I’m THAT old). There is also an amazingly fast and stable implementation in an Addon for Unity called Dynamic Bone (https://assetstore.unity.com/packages/tools/animation/dynamic-bone-16743). If it were me coding this, I’d be borrowing (cough) a lot from that implementation. I’ve used it on characters in Unity and barely noticed a performance hit - so anything that runs slower than 30FPS seems really slow (only Animation:Master and Unity have had very fast dynamic bones - even XSI’s were a bit sluggish).

My setup using Wiggle Bones is a Mixamo (very basic) skeleton that I added two wiggle bones to - very simple. I noticed a pretty good frame-rate hit right off the bat - about 20%. It seems to be fairly stable, although some of the movements on the rig seem to be either amplified or conversely, ignored by the physics. What I mean is that in a run, the jiggle can be excessive - and in a jump, barely noticeable.

I also have to wonder if playback frame-rate is causing odd behavior (I’ve seen this before). There almost needs to be a way of unhooking the actual playback rate from the designated rate so that the simulation is stable no matter what the playback rate - otherwise what might look like a nice simulation in the viewport, might end up too energetic when actually rendered …

Incidentally, I would happily pay for an addon that was fast, stable, and made setup and baking easy. Dynamic bones are crazy useful, and when they work well, indispensable. There are a number of features that the A:M bones had that I haven’t seen in anyone else’s implementation - and it’s too bad. If you want to see an example of AM’s bones, go to this page and scroll down to the third large video - the walk cycle: https://www.joewilliamsen.com/skill-building/ (actually, all of the animations with that character use AM’s dynamic bones - they rocked - and that was 15 years ago).

small update, i’ve managed to get the jiggle to show up in f12 renders/animations, however its a very bizarre and hacky feeling workaround, and i am noticing inconsistent crashing when attempting to render, so i’m going to try to look into it a bit more before sharing it out.

basically i’m forcing a frame change to the current frame (which triggers a jiggle calculation) when the ‘render_pre’ event triggers. then i’m disabling the jiggle effect because the render event itself calls its own frame change, but for some reason it breaks the jiggle effect (???). lastly, i’m re-enabling jiggle on the ‘render_post’ event. if that sounds convoluted, i definitely agree, and i think a lot of this comes down to my not fully understanding the voodoo behind the new dependancy graph in 2.8.

again if anyone has advice, it’s most welcome!

also a quick note JoeW, i am familiar with the unity dynamic bone addon and it was definitely an inspiration when i was writing this script. i need to do some testing to make sure i haven’t introduced any regressions in recent updates, as i don’t think i was noticing 20% performance hits originally - it was regularly maintaining close to 60fps with several wiggle bones active.

…aaaand confirmed, i checked an older version and there have been some pretty substantial performance drops recently, especially since i started on the collision code. the collision stuff should be bypassed if the collisions are turned off, but clearly something is up. thanks for catching this.

Why dont you guys bake the jiggle motion into every frame and then deactivate the jiggle bone?
Would be cool to have that option in the Jiggle, a bake button that pop up the bake option. I usually create the jiggle bake it to the same or new nla layer and no problems, renders and all.
At the end of the bake you set jiggle bone of. Thats what I do in my maya script(physics tools)

https://drive.google.com/open?id=1QIn45HgYbbRK3yveGjTaD2HuhEe1VhKp A gif with the workflow.
Non destructive way of working with your tool and very efficient. If you could and that buttons like I stated in the previous posts would be great to make the workflow faster and with less clicks.

2 Likes

thats also how i work :slight_smile:

i’m sure it’d be trivial to add a button for the bake operator to the jiggle panel if that helps people, i just didn’t want to get in the habit of making buttons that duplicate blender’s already existing functionality.

that said, i’m still hopeful for the casual user i can make unbaked jiggle work for f12 renders. like i said, it technically is now working in my test build, i just want to see i can learn more about the intermittent ‘segmentation fault 11’ crash i’m encountering on renders.

lastly, i was looking into some reports of slowness, and turns out my code didn’t get substantially slower, but that different test cases (obviously!) revealed some issues:

-rigify rig takes a noticeable hit with every additional bone enabled for jiggling. its a heavy rig with with lots of constraints and each time i update a bone’s transform, it forces the whole rig to re-evaluate (makes sense since there are so many dependancies) - so each jiggle bone is like adding a whole extra copy of the rig to evaluate every frame.

-armatures that have meshes skinned to them also slow down more than just the bones animating on their own. the armature modifier on the mesh is likely getting evaluated for each bone that is jiggling, so again there’s an expensive per-frame operation that scales with the number of jiggling bones.

for both cases, i’m going to need to think about ways to batch update multiple bones without triggering these expensive evaluations each time. the messy solution in the case of armature modifiers might be to disable the modifier until the bones have all had their jiggle positions set.

ideally there would be some way of suspending scene updates on property changes. maybe that is possible with the dependency graph, but like i mentioned earlier, still trying to wrap my head around it.

Its about making something readable and UI easy to learn. People are dumb. You need to show them the workflow. Also is not just duplicate the action but set it in a way that the user gives mode clicks. Like if I bake and then in the script I set the bone of it will same me 2 clicks. Its about teaching the workflow and save clicks. Blender is already a bad optimized program with to many extra clicks. Also blender have lot f amateur users so is good to start teaching them workflows

good point about turning off the dynamic jiggle effect after baking.
now i’m seeing a couple of things tied to bake button:

-jiggle currently has per bone and per scene toggles. jiggle is already tracking per object but doesn’t expose a toggle. this should exist so when you bake the jiggle, it disables dynamic jiggle only for the baked object, allowing other objects to remain dynamic if the user so chooses.

-when an object has had its dynamic jiggle disabled (ie through a bake), it should communicate this clearly in the bone jiggle panel so users don’t get confused and continue to try to adjust values and be confused why its not changing the effect.

2 Likes

Hello. This is a lovely plugin!
Is it possible to make it see the whole animation as a loop and accordingly pre-wiggle so that if you play the loop there is no hiccup because the first few frames have no wiggle in it?

1 Like

(Reposting this because it was unintentionally replying to another reply that wasn’t related. My bad.)

This script is sooo close to working for me. I’ve been wanting to use something like this for hair for a long time. But I’m running into one major roadblock, and it’s baking the wiggle bones into keyframes. I know that you are looking into ways to making normal renders work with this without baking, but that’s simply something I can’t take advantage of. I NEED to be able to bake into keyframes.

So, here’s the problem I run into when baking using the “Bake Action” command.:

Pre-Bake (Intended):

Post-Bake (Not Intended):

And here are the Bake Action settings I used:
blender_2019-07-28_19-01-43

And yeah, I made to to disable wiggle bones after baking to stop the live simulation from stacking on top of the existing posing.

I did try making a duplicate bone structure for this part of the hair and constraining through copy rotation to the hair bones that gets simulated. After baking (also enabling “clear constraints” in the Bake Action settings) for some reason the result still gets bugged away from the intended result seen in the pre-bake.

That is definitely unexpected behaviour! Is there a file you’d be ok with sharing that would help me isolate the problem?

I’ve also got an update on the way that tries to automate some of the baking steps for a more reliable result - although everything you’re doing sounds right!

edit: update is linked at top of thread!

1 Like

HairSimTest.blend (510.0 KB)

Alright, here’s the stripped down scene with the hair. Interestingly, if I were to append these assets into a fresh .blend file, baking works fine. I just don’t know why this particular blender scene is causing baking issues.

thanks for uploading that, its definitely showing the same issue for me in that file so i’ll dive into it a bit more to see if i can figure out whats happening! i’d been trying to replicate the issue on my own, and on its face should work, although like you said, it seems to be specific to that file.

i’m also going to push a quick fix to the baking operation that would fail to push the base animation to an nla track in some cases (although it doesn’t fix your issue)

1 Like

I’m not having much luck lately!

I tried to go through that demo file from DJTHED and I can’t seem to figure out what is triggering the issue. Copying and pasting all the objects into a new scene in the same file works fine, which seems to isolate the issue to some sort of scene setting itself, although it’s troubling that I don’t know what the problematic scene setting is! :frowning:

Likewise I’ve been trying to find ways to speed up performance on armatures with skinned meshes or lots of constraints that get re-evaluated over and over when updating multiple bones. No successes yet. But I’ll keep trying, and likewise if anyone is familiar with strategies for dealing with these types of issues your feedback is most welcome!

Edit:
I’ve tried a couple of things that seem promising that a speed up should in theory be possible if I can find the right approach.

I’ve tried unlinking the armature from the scene while doing bone updates, and indeed this prevents additional bone calculations from slowing things down, but the unlinking process itself causes a massive slowdown plus instability.

I also tried excluding the armature collection while updating bones, but the exclude operation has a fixed cost that is also pretty slow (but less instability). On the up side, I did see benefits when a bunch of bones are jiggle enabled.

Really hoping there is a way of suspending depsgraph evaluation that is more elegant

2 Likes

I’m not sure if this will help isolate the issue, but that particular .blend file was originally saved with Blender version 2.79 (or could even be earlier), not 2.8. It has since been converted, obviously. Perhaps some old default scene configurations carried over that confuses your script?

But I do guess in the mean time I’ll just make fresh .blend files and send the assets over to it. I’ll update you if I run into this issue again in the fresh file, though.

1 Like