[Bf-python] Discussion: Mesh PVert/MVert change?

Ken Hughes khughes at pacific.edu
Sat Jan 14 16:57:40 CET 2006


Campbell Barton wrote:
> Hey Ken, so far I havnt needed pverts and it seems like theyd be a bit 
> slower, but as long as fast access is available- its ok I suppose.

Ulless you were "editing" the me.verts list, they didn't do much.  I 
didn't realize until recently that they weren't accepted as parameters 
for verts.extend() at all.

> Just Writing a edge subdivide function and came accross 2 problems.
> 
> Non wrapped MCol objects cant exist AFAIK..
> 
> An example is rotating the colours on a face.
> f.col = (f.col[1], f.col[2], f.col[0]) # Didnt work; somehow assigning to 
> the wrapped data made a colour appear twice.

That the problem with wrapping; f.col[] gives an MCol which wraps the 
face data, and "f.col = " .... writes to the wrapped, data.  The first 
thing which happens is f.col[1] writes over f.col[0], so by the final 
assignment of f.col[0] the data is gone.  What would be worse is:

f.col = (f.col[2], f.col[0], f.col[1])

It would be the same as :

f.col = (f.col[2], f.col[2], f.col[2])

> f.col[0] = (12,255,0) # Syntax would ben nice and easy to deal with.

This would mean designing a MColSeq type... anyone else feel like 
jumping into the Mesh code?  I won't have time before 2.41, unless it's 
postponed a week or so.

Ken



More information about the Bf-python mailing list