Rigging With Shrinkwrap: Working around cyclic dependencies

Support Animation and Rigging
#1

I’m trying to work out how to use the Shrinkwrap constraint in a rig, but have come up against cyclic dependencies I haven’t been able to sidestep.

As a test example, I’d like to make an eye rig like the BBB Rabbit Rig, and have the control bones (on Layer 6 of the Rabbit armature) shrinkwrap to the eyeball object. As the eye is also being deformed by the same armature, just giving the bones a Shrinkwrap constraint causes a cyclic dependency. Using a duplicate eyeball object with a Copy Location constraint on the eyeball also causes a cyclic dependency.

I’m hoping to eventually constrain control bones to a lowpoly ‘skull,’ too. Is there a way to get around this, am I missing a workaround somewhere? Or, is Shrinkwrap just useless for rigging like this, at the moment?

#2

Interesting… :slight_smile:

I didn’t realize the shrinkwrap modifier was available for bones. But after fiddling with it, I can’t think of any use for it… even without the dependency problem, it seems the constraint is only evaluated on the object level. So if you have an armature deforming the mesh, it won’t update the shrinkwrap (unless I missed something?).

I will say that if there is a way to get the result you want, it will be by using 2 armatures. That is the only way I know of to get around a dependency of this type (armature->mesh->armature->mesh). Since the armature is evaluated all at once (as a single armature object via a single armature modifier node - each armature modifier is evaluated separately), all the bones in the armature are evaluated at once. So if the position of one bone depends on the position of another bone in the same armature (which it would if it depends on the deformations of the mesh created by that bone), then you’ll have a dependency.

I’ve put a lot of thought into working this out, since this is exactly the problem I faced when designing the stretchy suzanne rig. It uses two armatures to sidestep the dependency. The bones are constrained to vertex groups on a dummy mesh so they follow along with the deformations created by the first armature. Their influence is then applied to the original mesh. The problem is that the rotation of the bones cannot follow the surface of the mesh (the data is just too chaotic). So I used the rotations of other bones for their orientation…

If you are trying to create the ‘mesh constrained controls’ as is commonly done in maya, then I would recommend taking apart that rig, because that is exactly what I was doing :slight_smile: If you need an explanation about any part of it, just ask :smiley: (preferrably in the rigging thread, because that is where I posted her).

Cheers!

#3

I’d had a good look at Stretchy Suzanne (which is a real feat), but it’s definitely different than what I’m trying to figure out. I’m wanting the controls to ‘slide along the surface’ – I guess the cyclic dependency’s a brick wall, at least for the time being.

#4

Maybe you could do something like that with a pyConstraint? I’m not sure, those are something I have yet to figure out myself :slight_smile:

Can you elaborate more on what it is you are trying to do? I don’t yet understand why you would need the controls to slide along the surface.

#5

Well, as I’m working right now, a bunch of little deforming control bones are parented to the head, but are free-floating, so the animator could grab one and drag it anywhere. I want their translation to be constrained to the surface of a mesh – other than the actual character mesh being deformed – as a guide, so you’d be able to grab them (and hopefully even constrain to a global axis) and translate them, but they wouldn’t be able to get into weird positions like -1BU away from the mesh. By constraining to a surface, the rig could have ‘sculpting’ controls while preserving the model’s volume (eg. how eyebrows move along the ridge of the eyesocket), and it’d make it impossible, or at least plenty more difficult, for the animator to break the mesh deformation by translating the bones way out of whack.

I’ve seen this done with curves in an old thread at CGTalk, but we can’t constrain bones along a curve yet – though with a commit by Aligorith this morning, and ideasman42’s fixing the curve twist problem a few days ago, it looks like the devs are already getting this in place for Durian. In that thread, it looks like they’re using a lot of “expressions,” which look to be the equivalent of pyDrivers, for solving stuff that we can do with Constraints in Blender. (A problem we’ve got is that Poses don’t have IPOs and thereby can’t be driven like Shapekeys, but that’s on another subject.)

I figure using a hidden surface would be better than curves, as, for example, by building a simple skull that resides with the rig (CopyLocRotScale or 100% weighted to the head bone, but not deformed by any of it’s children bones) extensibility among similar character models would be made much easier. Interpenetration of static things like the teeth, and to a lesser functional extent eyeballs, could be solved automatically.

I guess it’s sort of like a ‘muscle rig,’ but instead of the character mesh itself constrained to a set of muscles deformed by an Armature, it’s deformed by an Armature, which has lots of ‘skin’ deforming controls constrained to a simpler ‘skeleton’ mesh (sort of like Cessen’s Biped Rig, in fact!) to preserve volume, the ‘skeleton’ itself being driven by the same Armature. (Ha, the cyclic dependency is apparent in even the sentence!)

I’ve hadn’t played with pyConstraints either, but gave them a look yesterday. Tried making a CopyRot constraint. I don’t know why I hadn’t realized it beforehand, but they’re evaluated just like regular Constraints so they end up creating the same cyclic dependencies!

Maybe I should think about invest in some rigging DVDs or something – I wonder if this is even possible in other packages, or if cyclic dependency is a fundamental aspect of parent-child dependencies in general!

…Naw, I’ll just wait and play with the new Curves stuff.

#6

So you’re controlling the skin by sliding armature bones across the surface of a skeleton? Woah! lol

It definitely sounds like a good way to achieve realism… though it opens up the door to a level of precision that I think will also make the rig very complex to build!

I’m very interested to see what you can come up with! The only advice I have for doing it in Blender, again, would be to use 2 armatures. One armature would have the bones controlling the skeleton, the other would have the bones controlling the skin - which would be constrained to the surface of the skeleton one way or another :slight_smile:

This will spread your animation across two armatures (when you get to that stage), which can cause problems with linking and animation workflow (if you’ve tried linking suzanne, you’ve probably noticed the refresh issue). It’s not too big a deal, just append your character to the scene instead of linking, and assign your action deliberately to each armature before animating.

Good luck!

#7

Bunny, I understand what you want to do, but with your method you wouldn´t be using mesh deform, which is of great help for preserving volume. Apart from that, the shrinkwrap constraint may not be as predictable as you would expect in certain occasions, specially if it is following the surface of an object, sometimes it becomes a bit jumpy, unless the object is heavily subdivided.

Well, I hope you can achieve the result you are aiming for. I know it is a completely different technique, but have you seen BlenRig 3?

It is my rig, and it has muscle simulation achieved with the shrinkwrap modifier and muscle objects.

http://www.jpbouza.com.ar/ESP2/descargas/blenrig-3/id/en

#8

Ah, now I see what you mean! I hadn’t made the connection, even looking at the Suzanne Rig – two completely separate armatures, meaning that (without, maybe, a third ‘control armature’…?!) you would have to switch between two different Actions to animate both ‘body’ and ‘surface’ movement!

Maybe with a third armature that doesn’t deform anything, but just serves as a target for CopyLocRotScale from the other two, would be able to keep everything in one Action. Two deforming armatures, driven by a non-deforming ‘animation’ armature.

I’m going to test it out after having a look at this new FollowPath.

I’d played with BlenRig 2, but haven’t tried the alpha of 3 (though I was wowed with the video demo!). Downloading now!

#9

Just to be clear, you wouldn’t have to have two actions… Blender just wants to make a new action for each armature by default. You can easily force both armatures into a single action by deliberately assigning the action to each armature before beginning animation (select the first armature, create an action, select the second armature and assign the same action. You may also need to set a key on everything when assigning the action for each armature to make sure it sticks…).

It’s also a little strange to work with because you will have access to all the keys in the same action, but you won’t be able to select any channels in the action editor that are not in the active armature (in the 3D view). On suzanne it works fine, because the second armature contains only the detail controls for her face, so they are animated in a separate run anyway.

I did think of using a 3rd armature to mediate the two… but quickly realized it wouldn’t work. Because if the 2nd armature bone positions are tracking the 1st armature, then how can they also track a 3rd armature? If the 3rd were to control them, they would need to be constrained (loc/rot) to bones in the 3rd, which would have to override the constraints on the 2nd which follow the 1st… OR the 3rd would have to be constrained to the 1st which would just make it 100% redundant… if you’re with me still lol :slight_smile: Maybe there is a sly way to do it, but as far as I can tell it isn’t possible… if you figure out a way though, let me know! :smiley: