Strange armature problem.

I’m trying to do something pretty simple here, but it’s gotten strangely complex. I have a mesh which is basically a swing-wing aircraft. I have an armature set up to control the motion of the wings, and the opening of the canopy. The armature consists of 10 bones :


The wing armatures work fine, rotating the wings at the pivot points defined by the Wingroot-wing joint just like I would expect. However, when I move the Canopy bone in pose mode, the canopy deformation group not only rotates, but scales as well (ie: shrinks as well as opens). I’ve tried everything I can think of short of completely reconstructing the mesh. What would cause this, and why is it only doing it on one of the bones and not the other two?

This sounds more like an armature/parenting/constraints problem than a mesh problem. Things to check: are there any unnessecary constraints on your bones? Any unnessecary parenting? If it were me, the canopy would be a separate object, parented to the armature with the ‘bone’ method.

I haven’t been able to find any constraints on anything involved, and the non-functioning canopy armature is parented exactly like the functioning wing armatures are. I did the whole armature set all at the same time, so I’m a bit puzzled why part of it would be behaving differently. I’ve tried going in, clearing all the vertex groups, destroying the armature, getting rid of every link I could think of that could modify behavior short of actually rebuilding the mesh, and without fail when I reconstruct the armature, the canopy, and only the canopy, behaves in this way. What else might cause this behavior?

Maybe a size IPO or two got stuck in your Armature Keyframes

go into keyframes.

click on armatures at the bottom of the grid, and select any Size IPO’s and delete em.

that happens sometime when the armature has been resized outside of edit mode. Try applying the size (Ctrl-A) to fix it.


I actually thought that might be the issue, but this doesn’t seem to have solved the issue. I applied size/rot to the armature which re-scaled and oriented the mesh object it’s attached to. I then went into edit mode in the mesh and re-oriented and scaled it back to where it was supposed to be, but it still behaves the same way. I’m getting the impression that I’ll either have to live with this or completely rebuild the mesh, alas.

If worst comes to worst you could try appending the mesh into a new blend file.

But be careful that you import only the mesh and not the object, that way you won’t get any nasty attachments with it. This, I fould, is a good way to clean any nasties from a model

Hope this helps

How exactly do you do that? I tried following your advice, but when I choose Append, pick the file, pick Mesh, choose the mesh, and hit “load library”, nothing happens. It works fine with Object, Armature, or Material, but for some reason Mesh doesn’t seem to give me anything.

that’s because it only imports the mesh inner data, with no correspondign object. You then have to link it to an object.

Just create a plane, go to the Edit Buttons window (F9). Click the browse button (-) next to the ME: field and select the one you want to link to.


Well, looks like theeth got in before me … as I was typing the reply actually :smiley:

good luck.

i know what your problem there is all about morris! I nearly killed myself when i was first learning armatures trying to figure out what i was doing wrong! :slight_smile: but anyways, i know now thanks to the forums! morris…when you make weight groups for each of your armatures MAKE SURE that no one vertex is shared by 2 or more groups…make sure every vertex in your mesh only belongs to 1 and only 1 group…it should work if you fix that…i think it should work in your situation anyways…hope it helps! ciao!

TUDBZD69 over and out!!! [>] [>] [>]

TUDBZD69: There are a lot of situation where assigning multiple groups is useful, joints just to name one. But you’re right, for mechanical rigging, multiple groups is more often than not the reason of unwanted deformations.


I checked the vertices straight away, and that’s not the issue. I even imported the mesh into a new object, completely rebuilt the armature and redid all the vertex groups, and it’s STILL scaling that one same group of vertices when I hook it to an armature. Thanks for all the great input, but at this point all I can figure is that there’s something about the way I generated that part of the mesh in the very outset that’s causing Blender to treat it differently than the other vertex groups in the mesh. Nothing else seems to make sense at this point, it’s very odd.

You’re doing a mechanical move, right? (Opening of cockpit canopy) The canopy really shouldn’t be a part of your main mesh. Moving mechanical parts should (IMHO) be separate meshes. Select the vertices of the canopy, then hit P to separate them into their own mesh. Parent this new object (the canopy only object) to your armature, select Bone from the parenting popup that appears, then select the relevant motion bone from the list that appears. Now try your motion. Let us know if it still exhibits the scaling behavior.

That’s a pretty slick idea, and I’d been wondering how exactly to separate objects like that. However, it still didn’t solve the problem. Separated the canopy into a separate object, parented it to the armature, and it still behaves exactly the same way as it did before. As the canopy opens (rotating along the Y axis) it also scales, but only in the X and Z axis (ie: height and length change, width does not). THat’s almost the wierdest think about the whole business, is that it’s not just scaling, but it’s specifically scaling in two axes but not the third. At this point I’ve found an acceptable workaround for this particular instance, but it’d still be nice to figure out what the heck I did to cause this so it doesn’t happen again.

Thanks for all the help so far. It’s been really useful info, even if it hasn’t solved this particular issue.

You should try to give access to your blend file (if you’re not reluctant to) in order to people here to be able to check what’s wrong.