[Bf-committers] Question about bone allocation (Chicken or the egg)

Tobias Oelgarte tobias.oelgarte at googlemail.com
Tue Feb 1 19:12:54 CET 2011


@ Brecht Van Lommel:
You are right. I should have not made any further changes.

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<sswaney at centurytel.net>  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
>> sswaney at centurytel.net
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



More information about the Bf-committers mailing list