Bones move in Editmode on their own! REALY UGLY BUG

As i was building a rig i saw some bones out of position, corrected it. Anything looked good. After some time the bones where off again. I adjusted them again, thinking that im stupid. :no:

Then i switched between edit mode and pose mode multiple times. The bones in edit mode moved every time a bit from their original location to another location, that they had in pose mode. Meaning that after some time you will destroy your setup completely.

I appended some screenshots showing whats happening if i switch between posemode and editmode.

http://www7.pic-upload.de/thumb/31.01.11/vvona73767pt.pnghttp://www7.pic-upload.de/thumb/31.01.11/5k3geurw4uus.png http://www7.pic-upload.de/thumb/31.01.11/us8fp31zim3u.png http://www7.pic-upload.de/thumb/31.01.11/d5y7zlzmusio.png http://www7.pic-upload.de/thumb/31.01.11/havm7lr78i2m.png http://www7.pic-upload.de/thumb/31.01.11/z1x4i4sts88.png http://www7.pic-upload.de/thumb/31.01.11/hdsv3t557sun.png http://www7.pic-upload.de/thumb/31.01.11/1ft83j3pi74k.png

At last here is the file in which this happen to me. Must have something to do with drivers, since i noticed it only after i added them to my rig. The file is prepared that way that you only need to tab between edit mode and pose mode to see this shit (already happens 1 time as you load it) :eek::

Can’t for the life of me get your file to download… get’s worse each time… last time it stopped at 12K.

If you set all the bone constraints to zero… especially IK do you still get the movement?

Simliar to this post http://blenderartists.org/forum/showthread.php?t=202715&highlight=bones+move+edit+pose+mode

Setting all constraints to zero might cost me a day (really a lot of them). I will upload the file to some alternative file hosters. Then the chances should be bigger. Will update my post after i did so.

Uploaded it to other hosters. At least one of them should work.

I don’t think it is related, at least the reason (making changes) is different. I only tab between the modes and the rig gets destroyed (sooner or later). Only way to avoid this would be “to never switch” to edit mode back again.

Phew… that’s one complex rig you’re working on there niabot.

Yeah i see what you mean… went to frame 0… hold the tab key down … and the knees slowly but surely bend out towards the knee targets… Hmmm so I thought lets put this puppy in rest pose and try that… and slowly but surely your knee targets fall to the floor. I think that is where the root of the problem lies… but this thing is like a tiger tank and currently i can’t see what would make them move switching between modes…

Try changing the parenting of your pole targets for the knees … I just parented one to the spine…(instead of the foot for example sake to get it out of the IK chain … or maybe better still empties) and alas that stopped the movement for that knee target.

Im currently reducing the rig to only the parts that are involved, while still keeping this odd behavior. Then it might be easier to find out whats going on. Must have something to do with the IK-Constraint, but how the hell does it affect the editmode. Its like as if you press “apply pose as restpose”.

That the knee-target moves down is related to its parent, that is moving. Essentially it must be the ik-toes.L/R Bone that gets rotated. If im thinking a bit back, i noticed some odd behavior from this bones in the actual rig. The bone “toes.L” liked it to to jump 180° (y-axis) while copying the rotation in worldspace, even though the difference between him and his 2 targets was only little. So somehow this bones (tip of the foot) getting affected. Anything else seams only to follow them.

OK. I hunted it down to “ik-toe.L/R”. Both bones have base as parent, and not a single constraint. Saying that they are only depending on bone “base” Still they change their positions.

What depends on this bones is the target (a childbone) for the IK-Chain and one bone (“toe.L”) that follows its rotation (copy rotation constraint). Thats all. But still this ugly bug.

Here is a file in which i reduced the rig very strongly (Bonelayer 6=FK, bones without any constraints, Bonelayer 16=IK anything related to the IK-Chain, Bonelayer 1=Bones that interpolate between IK/FK), while still having the problem:

Wrong deleted statement by myself. Bone was just hidden in pose-mode.

Beginning to question the parenting of a lot of your IK bones… I’m certainly no expert and haven’t put together anything as complex as this… as a rule of thumb i often have such bones parented to the root bone. I think this is where your hassles are coming from… the solvers move the parent the parent moves the solver… hence the movement when tooing and froing from edit mode.

Yep for arguments sake i just parented all your red bones (IK-only) to the center bone. (In rig from second post) In as much as it horribly deforms your rig it stops the edit/pose mode movement hassles.

That should’nt be the reason. That is a very common practice in many IK-Rigs. The leg is one good example, where you leave the toes on the ground and only move up the heel. You can’t do that right, if your target isn’t a child of the “toe” bone. A half valid way would be copy constraints to attach the targets to some other bone.

Now i reduced it to only some bones. That shows me that blender updates/changes the location of IK-Targets, as soon they are not parented to the “base”-Bone, which is very odd. The golden rule for the edit mode should be (or is): Do not change anything!

Doesn’t blender make a copy of the edit-mode locations and then uses them to calculate the actual positions for animations? There should be no “write back” into the edit mode. But that happens in this case and is a design flaw. Now the only thing i can do is to add even more bones and constraints to avoid this bug. :frowning:

Yes the changing rest pose is weird…

This is a known issue in blender. There are several bug reports for it in the tracker.
I have the same problem and posted here: http://blenderartists.org/forum/showthread.php?t=192517

Divine also has this problem:
http://blenderartists.org/forum/showthread.php?t=199970&page=2

I posted a bug report here:
http://projects.blender.org/tracker/?func=detail&atid=498&aid=25627&group_id=9

Brecht mentions that it probably happens due to constantly converting between the two different representations, and floating point imprecision.

The good news is that it is on the todo list, the bad news is that nobody seems to be assigned to it yet.

Imo this is a serious bug. Practically any armature becomes useless because you can’t edit it.

I give up. It’s impossible to avoid this bug. Even parenting the ik-target to the base-bone does not help. It constantly changes it’s position without any real reason. Sometimes i get the feeling, that if i want to create big things i should return to other software, since it are always the never fixed bugs that keep me from finishing projects…

It could be I have misunderstood this entirely. But let us for the sake of sanity clarify something.

Your bones are not moving in edit mode. And the original position is not Pose mode. It is Edit Mode. If you go through and remove all of the contraints you will find the original positions in edit mode, not pose mode.

Are you saying that the bones are actually shifting their original positions that they were in - in Edit Mode?

You are calling Pose Mode the “original position”. This is not the case. This is the modified position. As a very simple example, when you apply a copy location constraint the bone will move in pose mode to that new location if it is different than edit mode. The same is true for all constraints. They modify positions and orientations in Pose Mode. So when you go into Edit Mode the bones will of course “move” to their original location.

This explains this comment:

Must have something to do with drivers, since i noticed it only after i added them to my rig.
Of course, constraints can have an effect of the position rotation (orientation) of the bones while in Pose mode.

My suggestion would be to go back over the entire rig with this simple concept and see which constraint set up is causing the problem and work to correct it in pose mode. When corrected, then you should not see the shift.

Now, unless I missed something entirely even more obvious, this is the root of your problem. And since I was not there watching you build the rig, I can not verify that the positions changed from what you originally set in Edit Mode to another position in Edit Mode. If they did, yes, a bug. But that is not what I am seeing in your description nor the file and it in fact follows the normal laws and workflow of rigging.

Hope this helps you get it sorted.

If in fact, the rigging constraint set up you have is based on sound theory and practice to not normally shift the location of the bone in Pose Mode then, the solution is to submit it as a bug to the bug tracker. Now is the time. Now is when they are working to make corrections.

Sorry for not reading all posts. Just want to say: i had the same problem, the solution was to round the float values for the affected bones (head and tail), so that they have only like 3 digits or so after the comma. I had some values that looked like 0.0, but they really where like 0.00015 or something (figured it out be copying and pasting into a text editor). This fix worked perfect for me.

I guess we could also have a script to fix that automatically.

The problem is the other way around. If you create a rig in edit-mode, go to pose-mode, add some constraints (IK, or something else), change the pose to look how things work and go back to edit-mode you will find, that the bone-locations/rotations will have changed in edit-mode. That should never happen.

It is bug, as in some post before, you will see that it is already known. At least some others had the same problems. Floating-Point inaccuracy may be the issue. But why the hell are the locations of the edit-mode converted anyways? Anything on top of the edit-mode should work with a copy and not storing any values inside the original.

Then you are fighting only the symptoms and not the real issues. A position/angle etc. should be as exact as it can get. If you have some little rounding errors in pose-mode: Who really cares?

But if you create a rig and see it getting destroyed by just changing views, than it is really not a nice day. I can only hope that this will be fixed. Otherwise 2.5.6 (2.6) is no option for me.

Well here is how to verify this.

Make a copy of the rig, so that the edit mode positions are exactly as you first had them. (make sure there are no actions shared by the two rigs so that the copy does not affect the original)

Then on the copy rig, make your constraint and pose changes. Tab back into edit mode and see if they are or are not in exactly the same position they were - as verified by the original rig. If they are changed position in Edit Mode, then you have your verification. If not, it is not what you are claiming but something else.

Otherwise, all I or anyone can see (even the dev guys) is that the rig changes from Pose Mode to Edit mode. This could be “normal” and or problematic. But it does not prove your point.

Once you do this, then submit here for verification if you like. But more important, submit it to the bug tracker so it can be fixed.

If it is a bug, it can not be solved here.

I took a look at the rig and I agree with Richard Culver.
What you see in edit mode is correct.
I muted some of the Damped Track and Track To constraints, then made sure the ik targets were actualy and end of the ik chain where they should be, and everything seems to work, for the most part (things don’t jump around any more when you go into object or pose mode.) I think the problem is simpley to many bones tracking, copying, following, … to many other bones.

“leave the toes on the ground and only move up the heel. You can’t do that right, if your target isn’t a child of the “toe” bone”
If foot roll is what your talking about, I think this is a much better way (I may have miss understood what your trying to do, but if not this is work looking at.)
http://www.vimeo.com/13614039

And wow, that’s a lot of bones to just wiggle some toes :wink:

Best of luck,

aljo

There is no need for another prove. Just look at the first screenshots i made and compare the distance between the parallel bones. It gets bigger and bigger. And it is in edit-mode (Image 1, 3, 5, …). I just tabbed between the modes. That is definitely not right and not an error of myself.

But why should i write a bugreport, if nobody cares for duplicates of the same bug, that is known for a long time?

I don’t need a tutorial for rigging. I develop such rigs for myself and to have fun with them. On the other hand is this ugly bug, that has nothing to do with constraints and computational errors. They are there, but they are minimal. The real problem is, that a pose has an effect on the bones original locations in edit-mode. This should never happen. A bone in edit-mode is meant to keep his location no matter what animation or crazy things you do with him in pose-mode.

If you look at one of my first posts, then you will see a link to a blendfile. I removed nearly every bone for this example. The effect is still there. You might delete anything beside the IK-Bones in Bonelayer 16 and the “base” bone. Now you can switch between pose- and edit-mode and you will see that the target for the IK-Solver will move upward in edit-mode, and of course of this also in pose-mode.