[Bf-python] Thinmesh module, v1.1

[Willian Padovani Germano]

Hi,

Sorry Ken and all, I keep disappearing...

Ok, let me think out loud about dynamic storage in TMesh, maybe it can 
help bringing specific ideas to be discussed and more people to the 
discussion. Excuse me for uneeded parts. I'll talk about vertices, but 
this is also relevant for edges and faces.

Let's consider the case of adding a new vertex to or removing from an 
existing mesh.

Blender itself does this (looking at editmesh.c and editmesh_add.c):
single vertices are created and added to linked lists for editmeshes, 
which makes deletion also trivial. When this editmesh is used to 
(re)create the mesh, a single chunk is allocated for all verts and the 
editverts data is copied to it sequentially.

With Blender.NMesh we have something similar to that: the nmesh, a 
temporary struct in Python/C, and the basic Blender mesh. We work with 
nmesh and when needed (script author decides) pass the info back to 
Blender's mesh with nmesh.update().

So in both cases there's a temporary struct more suited for addition and 
deletion of elements. Being a thin wrapper, TMesh doesn't have this 
temporary struct, but we "need" some way to let data (vertices, edges, 
faces) be created or deleted and we need this to be fast and memory 
efficient.

Whatever we do, in the end it'll mean reallocating the vertex arrays of 
the mesh being edited. Of course we should not even think about doing 
this final step per vertex. Staying close to Blender ways and avoiding 
old troubles (having a slow .update() method or having to count on users 
to avoid mem leaks) are important goals, too, as well as looking for 
some "pythonic" approach for the API.

Fine, up to here I was just trying to give a basic picture for myself 
and possibly those who may not have followed this closely.

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.

(*) Just like we have for meshes themselves, lamps, cameras, etc., 
instantiated with a Vertex_CreatePyObject function, which would call 
PyObject_NEW (just check any of the _CreatePyObject functions in the 
api2_2x dir). This can even be done directly in Python in a helper 
module, called BPyMesh or something, creating a class with its member 
vars and methods:

class Vertex:
   def __init__(self, vcoords_xyz = []):
     if not vcoords_xyz: vcoords_xyz = [0,0,0]
     self.co = vcoords_xyz
     #... all attributes of a tvert would be here, too
   def copy(self, tvert):
     # copy data from tvert (defined in TMesh module)


2) Deletion is more complex. Being naive (*): three cases: single 
"random access" removals, multiple, intervals.

For single removals we might provide a mesh.verts.remove(index) method, 
so that we can do this in C in a smarter way, by copying the data from 
the last vertex to the one to be removed and shrinking the array by one, 
instead of reallocating chunks of data. Of course this also means 
updating the index in the mesh.edges and mesh.faces arrays.

(*) But there are other parts of Blender that depend on the vertex 
indices / positions, like vertex keys, etc. (?) So this will require a 
good plan, we should talk to Ton, Daniel, Martin, etc. before trying 
this route.

But a general method for multiple removals would be better. Possibly by 
working on a temporary list that later substitutes the old mesh.verts data.

For removing intervals, the easiest case, we can do it in the relevant 
tp methods for sequences.

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.

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.

-- 
Willian