OK. Now i wrote a patch against it. It's a little bit a hack, since i need to ensure that the roll is at least computed once while importing older files. New Files will store the roll after applying this patch.
What it does: * It prevents any modification onto the bones while switching between bone-edit-mode and something else. * It copies the current head, tail, roll to the "Bone structs" that are used in pose-mode * When entering edit-mode it just copies the values back, ensuring no issues caused by floating point errors. The good things: * Bones are now fixed and you can't destory you rig anymore by just tabbing between pose- and editmode. * Copying is faster then computation (not a real problem) The bad things: * Additional memory used for "Bone struct" (not a real problem) * A little hack, to ensure compatibility to older files. Otherwise you can't open them without destroying the rig The patch: * http://pastebin.com/mV5BwHqW What could be done: * I do not know in which way blender stores the bones. I assume it stores the "Bone structs". But i couldn't find the location in the code where they are read in. The problem is, that i have to setup the additional variables at least once, idealy when importing/creating the Bone structs. As long i can not fix this, i will have to use the variable "e_used" introduced by the patch. Greetings from Tobias Oelgarte, hoping on any kind of response, since this is a major bug. (I might be a bit angry, because my last rig got fucked up ^^) Am 01.02.2011 16:00, schrieb Tom Edwards: > Why are heads and tails stored anyway? This would be a great opportunity > to make editbones loc, rot, length. The difference between edit and pose > is bizarre from both a user's and developer's perspective, and a huge > HUGE headache when importing/exporting. > > On 01/02/2011 2:13, Tobias Oelgarte wrote: >> Im currently reviewing the armature code to fix the loss of precession >> while switching between edit mode and pose mode. Basically the locations >> and roll angles are computed back and forth every time. Since it is done >> with floating point precession the rig tends to fall apart. To correct >> that i will have to know how the "Bone struct" is allocated. Does it >> even get allocated? Meaning that it will always be the result from a >> conversion from "struct EditBone" to "struct Bone"? >> >> The question is basically about the fact which kind of struct is created >> first. From using blender i would assume that Editbones get created >> first and will then be converted to Bones, when you leave editmode. On >> the other hand: How it is handled while loading an existing file? Are >> the Editbones (for editmode) stored or the Bones (for Posemode and >> anything else)? >> >> What i basically want to do is to store the untransformed head and tail >> locations together with the boneroll as separate variables inside the >> "Bone struct". That seams to me the only way to get rid of the steady >> conversions, which will end up destroying the bone locations in editmode. >> >> Tobias Oelgarte >> >> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers