[Bf-python] Thinmesh module, v1.1

[Ken Hughes]

Willian Padovani Germano wrote:
>
> 1) Addition of verts is not hard. We can simply have an append method 
> for mesh.verts and create a BPy type for verts (*):
> 
> mesh.verts.append([v1,v2,v3,...])
> 
> This append method would reallocate the vertex array and copy new data 
> to it. Users would be able to add one vertex at a time (not not not 
> recommended, of course) or all at once.

This is what I've been playing with the last few days (adding vertices 
and edges); more comments below.

> Ending this huge email, it should be clear now why I favor the first 
> milestone: get things working fine before trying to handle addition / 
> deletion of verts/edges/faces. Even without that TMesh will be welcomed 
> by a lot of important scripts. NMesh can take care of additions / 
> deletions well, no reason not to use it. My vote, now, is to stay away 
> from additions / deletions in TMesh, Ken, and get it ready and well 
> tested by users for the next Blender release.

Ok, I'll finish up the attributes and methods which allow modifying 
existing meshes for now and post that as the main part of v1.2.  I don't 
think that will take more than another day; we just need to get more 
people to try it and test it out.

The addVerts() and addEdges() code I've written so far might also be 
useful, again just for people to experiment with.  Seems that the 
overhead for Python list manipulation is not bad (from a speed 
standpoint) and adding vertices and edges in masse is the way to go.  I 
did some benchmarks last night comparing TMesh with NMesh in adding 
large number of vertices and edges, and for edges there's no comparison. 
  TMesh is able to add 125K vertices (a 50x50x50 cube) and 375K edges
in about 5.6sec on my AMD XP-M 3000+; (1M vertices with 3M edges takes 
about 10 times longer, but part of that might be I filled RAM and 
started swapping).  Of that 5.6sec, only about 0.3sec was the actual 
addVerts() and addEdges() code; the rest was building the argument lists.

> Since Blender itself has well tested code for all needed updates in 
> editmesh, we should really try to use that when possible (use editmesh 
> and let Blender update everything for us). Because of that a 
> Blender.EMesh module might be a good idea.

I looked at the editmesh a little, and others can either confirm what I 
think or correct me, but it looks like it would be possible for more 
than one mesh to use the code (and maybe even while something is being 
edited in the UI) provided that we don't mind maintaining G.editMesh 
ourselves.  It seems to be the main reference point that much of the 
editmesh structures work from.  I assume it's also obvious that 
Blender.EMesh would be like Blender.NMesh in that there would have to be 
an .update() or .Put() to place the dump the editmesh back into the real 
mesh structure; otherwise every operation would have to load and save 
the editmesh itself, which would slow things down if there's more than 
one operation.

Ok, my turn to shut up and head off to bed -- will post another update 
when v1.2 is ready.

Ken