[Bf-python] Thinmesh module, v1.1

[Joseph Gilbert]

Ken Hughes wrote:

>>
>> *ACK* BPy should never use guardedmalloc directly to alloc/free 
>> memory. Your looking for trouble mister.
>
> Advantage of this: there's only one MEM_callocN() / memcpy() needed 
> for this since I process the list of edges once
>
> Even if the memory was allocated by MEM_callocN()?  This is the 
> Blender mesh list of edges, not a BPython list.
>
Well I have to take that back! MEM_callocN is needed when we are 
allocating 'sub objects' of a structure. (like edge i guess :))  Usually 
blender supplies wrappers for MEM_callocN or alloc_libblock - usually 
called add_xxx(). But sometimes these aren't available. MEM_callocN is 
ok when there is no blender wrapper (i.e. add_xxx()) and the parent 
object is already being managed by blender through a called to 
alloc_libblock (which makes the object managed by blender through it's 
'database' of G.main). Blender (not always consistant) expects some 
things that things be added in ways which keeps track of allocated 
blocks so allocating with MEM_callocN (sometimes) can be dangerous. It 
would be nice if blender was a bit more constant is suppling factory 
functions for creating subobjects like bones but it's not always 
possible. Raw memory allocation (for variables and such) can be done 
through PyMem_malloc. Sorry :)

>>> But since I'm relying on Python to build my list of tuples (and 
>>> assuming a more complex script is going to be using append() 
>>> operations to build the actual list) I don't know which is more 
>>> advantageous.  So later this weekend I'll try some tests with larger 
>>> meshs and see what results.
>>
>>
>> How would someone call an edge? (just wondering) For instance 
>> Mesh.edge[1] ? How do I know that mesh.appendEdges(v[0],v[1]) makes 
>> me and .edge[1]?
>
>
> Should addEdges() return a sequence of edges, corresponging to each 
> vertex pair?  Or is the edge list only needed to add faces; maybe in 
> that case we just make an addFaces() method which takes vert pairs 
> and/or edges and makes the faces, creating edges and verts where needed?
>
Maybe the edge should have someway to test to see if it contains a vert. 
Something like:

for edge in mesh.edges:
...if v1 in edge:
......myEdgeList.append(edge)

This would mean that 'edge' would need to implement the sequence 
protocol. Something similar could exist for faces. If you wanted to 
contruct faces from a series of verts you may have to contruct edges (im 
not sure) internally. If that's the case things are pretty siimple. If 
not (i.e. you can construct faces from simple points without the need 
for edges) then faces can contain edges and verts:

for face in mesh.faces:
...if v1 in face or myEdge in face:
......myFaceList.append(face)

Anyway these are some ideas. Returning a reference to the edge in the 
container i don't think is needed. Rarely would someone call:
mesh.addEdges(e)[1].callSomething
This seems a bit bizarre to me.

I think to do this you would need to override *PySequence_Contains *and 
then test the 'edge' container to see if the contents of v1 where 
contained in edge and return a (boolean) int.

>> Also it seems edges are an ugly manual process where the user needs 
>> to define what an edge is. If it was me i would load all my verts 
>> into a list and run a loop:
>> e =([v1, v3],[ v3, v4], [v4, v5], [v6, v7])
>> for a, b in e:
>> ...mesh.appendEdge(a,b)
>
>
> That's exactly what addEdges() does, except you could do this instead:
>
>  e =((v1, v3),(v3, v4), (v4, v5), (v6, v7))
>  mesh.addEdges(e)

good point :)  As another idea the single edge addition (v1,v2) might be 
useful where verts are extracted from some more complex structure in a 
loop like a class. Whatever you decide :)