[Bf-python] Mesh Module

[Willian Padovani Germano]

Hi, should have replied sooner...

Ken Hughes wrote:
> For the code example you give above, what should happen if the size of 
> the list myverts is different than the current mesh verts list?

Probably in this case it's better to simply get rid of the current array 
and construct a new one, when the py coder does something like 
mesh.verts = somelist.

> should we prune edges and faces for deleted vertices?  Should 
> ALL edge and face info be deleted?

At least initially we can leave all of this to the users. If they delete 
  or add vertices, they take care of updating mesh.verts, mesh.faces and 
mesh.edges accordingly. Later, if needed, automatic facilities can be 
added to help with deletion, for example, in well controlled ways.

> 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;

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.

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

> Oh, and one of those "now that I know enough to be dangerous" ideas; 
> supposing the mesh does have vertex keys, should we make them accessible 
> through something like mesh.keys[]?

Sure, that's useful for many scripts. But it's better to get Ton's input 
on it, see if things are stable there enough to be wrapped for bpython. 
Toni and others are also interested (Joseph, too, for import / export, 
if I remember correctly).

-- 
Willian