[Bf-python] About the NMesh module

[Willian Padovani Germano]

On Wed, 2003-05-28 at 12:58, Jordi Rovira i Bonet wrote:
>     I've been examining the NMesh module (both in the experimental
> api, and the old one) and have some questions and comments.


> The main one is: why does this module "copy" all the data in blender
> C structures using python objects, instead of wrapping the thing like
> in all the other classes?

Yes, let's call it "fat" wrapping instead of "thin" wrapping ... when I
first started helping Michel I went that way, so
dir(Blender.Camera.New()), for example, would give what I expected (all
attrs and methods), but saw that it wasn't necessary and cleaned the
modules.  Michel from start was already using the "thin" approach.

I was going to write an alternative Mesh module, different from Mesh and
NMesh, using the thin wrapping, but it was decided that Blender 2.28
should include exppython (that's why Ton posted asking for programmers
to help) and we had to hurry a little.  I was already porting from
bpython BGL and Draw, so went along for NMesh, too.

Later there may be a thin Mesh module if NMesh doesn't prove good
enough.  Now let's consider why it is "fat".  They wanted the
possibility to create new vertices, new faces and then add them to a
mesh.  This can be done with malloc'ed Blender vert structs, but can
also be done the way they did, which is actually simpler.  Instead of
making a thin wrapper for each loose vertice (fresh, not belonging yet
to any mesh), they did a fat pyvert obj (the NMVert) that is a struct
already with space for vert data and is independent from Blender until
we add them to our mesh AND update() it.

One strong reason for doing this is wanting to support n-gons in Blender
Python.  You can't simply wrap real Blender faces then, because those
only hold 3 or 4 vertex indices.  They do that with their own structs
then tessellate them upon update().  Another thing to keep in mind is
that they had plans for Mesh that we don't know well.  It was left there
half(?)-finished.

There's more.  Blender has two mesh structures (and so also two face and
two vert structs): the normal mesh and the Edit Mesh (so EditVert,
EditFace -- actually called "EditVlak").  Just check the
source/blender/src/editmesh.c file.  When we press ALT+TAB to enter edit
mode, if the active object is a mesh, an editmesh is created out of it,
vert by vert, face by face, the structs are different, they have flags
to mark selected verts and faces.  When you ALT+TAB out of edit mode,
this editmesh data is used to update the mesh and the editmesh memory is
freed.

NMesh has the select flags, though I'm not sure the functionality is
working, there's a comment there that the flag would be taken away.  So
NMesh is more than a simple wrapper of mesh data, it's more like
editmesh data and that has to be updated.  Mesh would one day be able to
do this, from a comment in Mesh.py.

> Wouldn't it be possible to make it 
> thinner and faster simply wrapping (using pointers, or
> pointers+indices for array elements) and redefining the comparison
> function?

Remember it is used to create new meshes, too, so it must alloc space
for new verts and faces anyway.  Having them as NMVert and NMFace py
objs is, again, probably simpler than dealing with dynamic allocation of
blender vert / face structs in C.  They leave the allocation for later,
when it's time to "update()" (allocation in convert_NMeshToMesh).

> I suppose that in the experimental api, this has been ported
> straightforward from the old one without questioning this.

It is being ported, but not 100% straightforward (there are datablock
parts that need a total rework) neither without questioning : ).

>     Knowing that the main goal now is to keep compatibility with old 
> API, this changes (if turned out to be possible) would have to wait 
> until we could change this compatibility.
Yes, that's it.  And we're also in a hurry.

>     Another question is... why NMesh and not Mesh. I think this comes 
> from a reimplementation when both neede to coexist. If i'm right i 
> suggest switching to "Mesh" again when we could break the API.
Mesh is not written in C.  It's a small python wrapper (look in
blender/intern/python/modules/Blender) of a C file.  Guess which?  NMesh
(blender/source/blender/bpython/intern/opy_nmesh.c).  To keep
compatibility we'll probably add the functions Mesh uses (some are as
simple as Mesh.Get() which is just NMesh.GetRaw(), from what I
remember).  NMesh was marked to die, but the code is still "all" there. 
Mesh would be written later.  In the state they left it, it's a wrapper
and it's incomplete.  For example, it should handle n-gons, though
Blender itself only uses triangles and quads.  The code for that would
be exclusive to Blender Publisher, the $$ version.

NMesh deserves a good look before we decide to leave it.  Maybe a few
improvements will get it in good shape for now.

>     Another question that suddenly comes up to my mind... not related
> to python... what doesn "NLA" mean? i've seen all around the code.
No idea, I'll pass that : ).  But I want to know it, too.  Michel?  At
least we  know what "vlak" is ...

--
Willian, wgermano at ig.com.br