[Bf-python] EMesh

[joeedh]

Willian Padovani Germano wrote:

> 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.

I agree.

>
> 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).

That makes me feel 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.

NMesh is actually pretty good, too.  It's just not designed for 
real-time manipulation of meshes.

>
> 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.

I agree!  I never, ever, ever even considered the possibility of 
replacing NMesh with EMesh, since as you say they both 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.

Yes, I left Node (IRC client) on to log the meeting.  It's at only 7:00 
in the morning where I am, but I've been recovering from a cold and 
didn't want to wake up that early. :)

>
> 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.

That's the basic idea.  But I see no reason why to not have 
EditVert/Edge/Face types--This is python, by it's nature it's really 
easy to do error-checking on attribute values before sending them to the 
actual real EditVert/Edge/Face struct.  And, uhh, I've kindof done 90% 
of the work on the EditVert/Edge/Face python types.  I even figured out 
how to do the edge seam and crease stuff.

For example, I see no reason whatsoever to have a Select function, since 
I see no reason not to have a "sel" member of EMesh_EditVert/Edge/Face. 

>
> 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.

Crashes, ALL of them, must be eliminated.  I know this and fully intend 
to kill all such bugs.  It's just that the patch I sent to the list 
wasn't nearly finished, and was kindof buggy.

>
> 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.

That's my reasoning too.  It's our (well, mine at the moment) job to 
manage EMesh--Ton can improve EditMesh to his heart's content, and he 
need not worry about breaking EMesh sine we'll just fix it.

>
> 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?

That's fine.  That'll work.

>
> 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.

Oh, good.  Rewriting large portions of Blender in python is never 
something I've been eager to try. . .*shiver* that would be complicated, 
to say the least. . .it would make writing EMesh seem like a piece of 
cake (to quote a cliche).

joeedh