[Bf-python] Partial proposal for armature+bone modules

[Jordi Rovira i Bonet]

Willian Padovani Germano wrote:

>Hi, Jordi, sorry for not answering faster
>
>On Wed, 2003-05-21 at 11:16, Jordi Rovira i Bonet wrote:
>  
>
>>    - It is possible to wrap a NULL bone (when asking for the parent of 
>>a bone, for example) This is a temp solution, maybe i should implement a 
>>"has_parent" query, because it would be simpler.
>>    
>>
>
>Yes, a .has_parent function would be useful, but shouldn't the function
>that returns the parent of a bone simply return Py_None when there's no
>parent ?
>
If I return Py_None when there's no parenti get an "attribute error" at 
runtime, so there must be a way to check for the parent first. I've 
decided to add a "has_prent query, and raise an error when asked for the 
parent of an object that hasn't, thus removing the wrapping of NULL bones.

>>/* Function:              M_Armature_Get                                         */
>>    
>>
>The Get functions in the basic modules (the ones available in bpython
>that we already implemented) have already been completed.  Now they
>return a list of all objs of their type when no argument is given to
>.Get()
>  
>
This is what i meant when i said i forgot something... :) I'll do it 
right now.

>>    assert(current);
>>    
>>
>asserts are good for testing, but remember to use a gentler solution
>before we commit this to cvs.
>  
>
This was a way to test during development, this condition is impossible 
now, won't damage. It's not a way to control "user errors" :)

>>/* Function:    ArmatureCmp                                                  */
>>static int ArmatureCmp (C_Armature *a, C_Armature *b)
>>{
>>  if (a<b) return -1;
>>  else if (a==b) return 0;
>>  else return 1;
>>}
>>    
>>
>The pointer comparison is already done, for example, in Camera.c
>
I know, i suggested it :).

>The only relevant answers there are yes (they wrap the same Blender obj)
>or no, they don't.
>When it proved relevant, we could return "<" or ">" for some module,
>based on something else.  I mean: if they don't point to the same thing,
>compare some other data and return "<" or ">" based on that comparison. 
>Ex: for cameras we could compare their names or distance from (0, 0, 0)
>or whatever.  But until that proves useful, no need to do this for
>cameras or lamps or ...
>  
>
It could be useful to define an order operator if python uses structures 
more complex than lists (this is something i don't know), for efficiency 
reasons (logarithmic search time containers). However i agree that maybe 
the python api should resemble more a "natural api" than a techincal 
programming one, and comparisons should be defined according to some 
higher semantic reason (for example a lamp could be compared acording to 
the its brightness?) then it sould be very well documented when used. An 
exception is the vertex class, you can have many vertices in a mesh and 
probably you need a way to access them efficiently in most algorithms, a 
strong ordering criterium (like comparing first x coord, then y coord 
and then z coord) should be defined for them.

>You're doing a pretty good job on probably the most wanted new module
>for Blender, congrats : ).
>  
>
I've added a function to the NMesh module called "getVertexInfluence" to 
query for the a list of bone and weights pairs influencing the vertex. 
This is readonly and should be enough to write exporters. I've done it 
based on the other functions to keep coding style. Is this going to go 
to the cvs?

(bandoler)