[Bf-python] Bone module simplification

[Gilbert, Joseph]

Very nice Yann! The clean up to vector is flawless. The clean up to bone
is very nice. 

The major item here is the way the Bone module is being implemented. You
have changed this module to wrap C-created object immediately instead of
making a python representation that is 'created' later.  

Basically this module was modeled on the way that NMesh created objects.
All python objects are not physically created until they are 'updated'.
When you create a 'Bone' for instance - it is only being created as a
python representation of a 'Bone'. Upon a call to Add_Bone() (or another
function where the bone must be used by the blender application) the
Bone module would only then create a C-representation of the Python
object.

This way all python objects reside in python and when a script exits -
python cleans up the mess (for bones that were nonsense). If you make
the Bone class a wrapper for C objects directly people may not use them
(maybe only as temporary objects) and they will occupy memory until
Blender exits - since datastructs in blender are not 'freed' till exit()
is called. 

The way you have changed it - it now no longer makes python
representation of objects and immediately allocates memory for a C
structure. The problem with this is that if someone repeatedly calls a
script the bone will be recreated in memory over and over using up
physical memory until blender exits.

However, Good work Yann.

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Yann
Vernier
Sent: Tuesday, January 04, 2005 5:46 AM
To: bf-python at projects.blender.org
Subject: [Bf-python] Bone module simplification

I've now reworked Bone.c, and because of structure changes some bits of 
Bone.h and Armature.c as well. Mainly it's a simplification by always
using Bone structures, not duplicating the fields in BPy_Bone.

http://donkey.dyndns.org/~yann/blender/patches/bonewrap.diff

Please try these changes out.  I think the code is more robust, and I
hope it may be more readable as well.  In particular I'd like to know if
this breaks any scripts that currently create hierarchic armatures (i.e.
armatures where the bones are parented).

Changes include: 
- Fewer memory leaks. For instance the functions to create strings, 
  matrices and vectors all duplicate their data. 
- No more duplicate references (causing references to freed memory). 
  To see what I mean, try parenting bones after adding them into an
  armature with the old code. This is what got me started.
- More efficient code in some cases, for instance clearChildren
  does not move listbase entries one by one. 
- Consistent Python exceptions - most of those thrown were unnecessary 
  and in addition threw the wrong exception type.  Python API functions 
  tend to set appropriate exceptions. 
- Perhaps some inconsistencies were resolved - I think bone parent 
  transformations were doubly applied if you parented before adding 
  bones to armatures.  Doing it the other way would cause memory
  corruption. 
Some weirdness remains, such as whether bone attributes are relative
to their parent or not (they are if both bones are in an armature),
and children not yet added to armatures aren't tracked.

Functionality lost is the probably unintended method to move bones from
one armature to another by reparenting them. I
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python