[Bf-python] Vertex Influence for no-armatured objs

[Willian Padovani Germano]

Hi, Joseph

> I guess you
> could add a function to nmesh that would cycle the G.baselist looking for
an
> object with a meshdata block match....

The code for this is already there, in NMesh_update, I guess, since if there
is no Object yet, one has to be created.  But there might be a problem for
your case: a mesh can belong to more than one object, and when we look for
the "owner" object, which one should we choose ?  For that reason, besides
time and the fact that this info is stored on objects, as Joseph pointed,
it's not a bad idea to have these functions on object.  Because then we
clearly start from a chosen object, do whatever needed to its vert groups
and at any time reach its mesh directly from the object.data field.

Of course, with an EMesh module we'd know the object for sure, it's stored
as a global when we enter editmode, you know.  But even so extra workarounds
would be needed, since emeshes will be "fat" wrappers like nmeshes are (in
the sense that the info is copied and kept in pylists till we nmesh.update()
or NMesh.PutRaw() it, when a conversion to the real blender structs occurs).
We'd also have to copy group info from object to emesh, making them even
"fatter" and less related to the blender counterpart, that's unnecessary.

> p.s. is the ID unique or only an identifier for serialization?? (I think
> it's not unique but not sure).

Unique inside each struct type: mesh, lamp, etc. from what I remember.

> p.p.s.The script is slow on group with a lot of vertices being added.  I
> think it's because addVertexToGroup calls editmesh/loadmesh each time.  If
> a set of vertex points was added and then edit/load called that would be
> better. (Emesh.....) I was just guessing that people didn't know the set
> they need and the function would be easier to use in a loop.

People would "know": even if the info is not available as a whole (being
parsed from a file or "discovered" one vert at a time), they can first store
all relevant verts in a pylist and then send the whole list at once.  Better
take the expensive call out of the loop.

** So I believe your functions to add and remove verts to vgroups should
handle lists of vertex indices, not single indices.

> More popups! Yes! :)
Maybe ... there's plan to add popups (and Ton yesterday said they can be
complex, full of buttons -- I just knew simple blender popups).  Well, let's
see about complexity, but for simple dialog / warning / button boxes we can
probably add them easily.  But first on the list now is putting scripts in
menus and getting free from ALT+P.

--
Willian, wgermano at ig.com.br