Hi, We should continue discussion in the patch tracker, please open a report there. I'll reply later trying to explain what I mean, I still think this is the wrong solution...
Brecht. On Tue, Feb 1, 2011 at 7:12 PM, Tobias Oelgarte <[email protected]> wrote: > But regarding the storage of the variables i can't imagine a better > place, since the editmode is where the precession comes from. If you > store the restpositions in editmode and check with some delta against > it, you will end up with the same problem again (floating point errors). > The only right position for bones is the location inside the editmode. > The editmode can have an effect on the the posemode, but whatever you do > should have NO effect on the locations in editmode. > > For example: A mesh will be deformed, but kept locally as it is. The > same paradigm must be applied to bones. > > The hack inside my code will be only necessary for importing. Once > imported, it isn't needed anymore. But i could not find the codesection > that creates the Bone structs while importing. Thats why i wrote it the > way it is. Anything in "if (curBone->e_used == 0) {" should be moved > there and no hack will be needed anymore. The variable "e_used" could be > removed. > > Maybe you want to give me a hint in which file the Bone structs are > created. As soon i will know, i can implement a short check and set them > up correctly without the need of additional variables, except for > e_roll, e_head and e_tail. > > Greetings from Tobias Oelgarte > > Am 01.02.2011 18:47, schrieb Brecht Van Lommel: >> Hi, >> >> This patch and the other one you posted contain many formatting >> changes, please keep those out of patches, it's hard to see what you >> changed. >> >> Regarding this fix, it would be better to store original >> roll/head/tail + loc/rot/scale on entering edit mode in the EditBone, >> and then use that when you convert back from EditBone to Bone, if the >> roll/head/tail didn't change (maybe need to check for parent changes >> too). That keeps it nice localized. Better not store duplicate state >> in files, not because of memory usage, but because it's better to keep >> such hacks in runtime code. >> >> Brecht. >> >> On Tue, Feb 1, 2011 at 6:36 PM, Stephen Swaney<[email protected]> >> wrote: >>> On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote: >>>> The patch: >>>> * http://pastebin.com/mV5BwHqW >>> Blender has a Patch Tracker. Putting patches in our tracker >>> makes it easier to review and maintain them. >>> >>> Making it easier for patch reviewers is making it easier to >>> get your patch applied. >>> >>> -- >>> Stephen Swaney >>> [email protected] >>> >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
