[Bf-python] EMesh

[Willian Padovani Germano]

Hi,

First of all, I read your patch, Joe (joeedh), but didn't try it yet.  
The code, as you say, needs some cleanup and is still experimental.  But 
it looks good, congratulations :), that's a lot of work. 

I agree with you that an EMesh module is needed, since NMesh requires a 
full mesh update (converting Python data to a Blender mesh) for each 
change to be visible in Blender.  That's slow for realtime editmesh 
operations.

Now keep in mind that whenever we add things that require non trivial 
changes outside python/ ,  we have to fight a little :)...  please don't 
let that upset you.  Of course it is not because Ton hates us or Python, 
he just wants (and we all need him to) understand and control what is 
getting in the program.  But since he has too much to work on and isn't 
used to the Python/C API.  Even when something is in shape to be 
committed, it can take a while.

Ex: I had a patch to add scripts to menus ready before 2.30, but thought 
I should wait.  Then close to 2.31 Ton suggested we waited a little more 
and later I had to convince him to let me apply the patch before the 
2.32 release.  And this for an addition already discussed at the bf 
mailing list and requested by many, even himself.  The patch only added 
two files, but it added a few lines in many files here and there, so it 
was not fun to update it.  I had to re-integrate the patch from a local 
copy to my local cvs version at least three times in the process (of 
course this made the final version better).

Joseph Gilbert is also experiencing this difficulty with his code to 
open panels for bpython.  And btw, to answer Joseph:

 > As I remember EMesh was willian's baby for years but was never 
implemented.

Not actually years :).  Last year we talked about either updating old 
NMesh or rewriting from scratch and the decision (good one) was to keep 
NMesh, so it was updated and bugs were fixed.  This was for the 2.28 
release, when the current implementation substituted the old bpython 
written by NaN programmer(s).  So, let me make that clear: NMesh, Draw 
and BGL are "very old" modules not written by any of us.  We only 
updated where needed, fixed bugs and added new functionality to those 
modules.

Only for the 2.34 release, while adding the EditMode, QAdd, etc 
functions in Blender.Window and playing with them, I became convinced 
that EMesh was necessary.

A "fat" wrapper like NMesh isn't suited for realtime work, but it is a 
good idea for reading mesh data and also adding many new verts / faces, 
etc.  So both NMesh and EMesh complement each other.

-*-

joeedh: yesterday we talked about EMesh and, in general, the role of 
Python in Blender, during the meeting.  As he expressed on the mailing 
list, Ton is a little concerned about what Python should be given access 
to in Blender.

He asked that the EMesh was only allowed to do what a user can via the 
interface (that's more or less the case with BPython, anyway), not 
access the internals directly.  We'd have a "public interface" to 
editmesh functionality that BPython could wrap.  Martin Poirier (theeth) 
suggested EMesh could work like a set of macros (move(), extrude(), 
smooth(), etc).

This might turn out cumbersome for basic things like moving vertices, 
etc., so we can study things a little more before deciding.

Let's see:

Ton's main concern were things like your comment about possible crashes, 
etc.  These we should and can avoid even if we have to use some tricks 
to make sure required steps are performed always.

Another problem is that the emesh related structures can change and the 
coders want freedom to do so.  But I guess we don't have to worry about 
that.  They are free to make changes to the structs and we just update 
the bpython side whenever needed.  Most or all that an EMesh module 
needs to access are basic 3d things like vertex positions and face, edge 
vert lists.  No matter how much they change editmesh structs, these will 
always be around, so no risk to break the EMesh API or whatever.  We 
don't need to access anything but the main functions and basic editmesh 
variables.

It seems to be too late to add EMesh for 2.35 and that gives time to fix 
and test it properly.  It can become part of some testing builds once 
done or maybe tuhopuu, so users can help in the process and start 
showcasing possibilities with their scripts.  After that we can discuss 
again at the bf list and irc meetings to get it approved.  Ok for you?

BTW, we know EMesh is not meant to substitute C coding, that it can help 
a lot testing new functionality that can later be rewritten in C, and so 
on, so don't worry about not being understood.

-- 
Willian