[Bf-python] Mesh Module

Ken Hughes khughes at pacific.edu
Thu Oct 6 22:58:17 CEST 2005


Willian Padovani Germano wrote:

> 
>> Should the "fat" vert created by Mesh.MVert() retain info about it's 
>> original index so that later the sequence assign_item handler can try 
>> to "fix things up"?  Any suggestions out there?
> 
> .index is part of the info about each vert, so it should be in the 
> pyvert, too, somehow. Looking at DNA_meshdata_types.h to confirm, 
> there's no index var, so it uses array order to define indices and so we 
> can use the position in the py list for that, probably. Btw, saw there's 
> a flag there, ME_VERT_STEPINDEX (there are similar ones for edges and 
> faces, too), that we'd better know about. Guess Zr introduced it, it's 
> used in three .c files, including subsurf and modifiers.
> 
> It occurred to me this morning that it might be a good idea to make 
> pyverts follow exactly the MVert struct, with the py object header being 
> the only difference:
> 
> typedef struct MVert {
>     float    co[3];
>     short    no[3];
>     char flag, mat_nr;
> } MVert;
> 
> ->
> 
> typedef struct PyVert {
>     PyObject_VAR_HEAD
>     float    co[3];
>     short    no[3];
>     char flag, mat_nr;
> } PyVert;


I've implemented PyVerts so far as a special case of MVerts, like Joseph 
did for the mathutils.  Only difference, he used an extra flag variable 
for Py_NEW/Py_WRAP and I used index=-1 --> Py_NEW, index >= 0 --> 
Py_WRAP (to avoid adding four more bytes to each object; can change that 
if the feeling is 4 bytes are less important than clarity; I'm flexible).

BPy_MVerts basically looks (or will real soon) like this:

typedef struct BPy_MVert {
     PyObject_VAR_HEAD
     int index;
     void *data;
} PyVert;

where data == (Mesh *) when index >= 0 (for a thin vert) and data == 
(MVert *) when index == -1 (for a thick vert).  For a thin vert, I use 
index and mesh->mvert to find the actual MVert *, so the end result 
either way is operating on an MVert.

Do you feel that PyVerts should be completely separate type, even though 
the attribute operations are basically identical?  I could reuse the 
attribute code and just present two different PyType structures (and 
PyGetSetDef tp_getseters, one without the index attribute), or make them 
totally separate and identical....

(brief aside to give you understanding of where I'm coming from; I've 
been teaching embedded systems design for 10+ years and have been living 
in the 32-64KB code memory world; so I tend to strive for efficient 
memory usage, sometimes at the expense of speed).

> With this we can copy data from one to the other type with a single 
> memcopy, instead of copying per var: pyvert->flag = mvert->flag, etc.

Yep, I'm using memcpy() now.

> BTW, are you convinced already about the usefulness of py verts, etc. or 
> would you like to discuss more?

I don't think I need "convincing"; would just like to get script coders 
feedback as to what they want/need.

Ken



More information about the Bf-python mailing list