[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