[Bf-python] EMesh

[Joseph]

joeedh wrote:

> 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
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>
>
>
Yes, again good work it's always hard getting a handle on all the python 
internals etc.and writing your first module.  I only have 2 concerns : 
1) I disagree that selection should not be a part of EMesh.  This is 
something people have asked for previously (the ability to select and 
deselect verts/edges etc.). The ability to select verts, edges and 
'vlacks' :) through EMesh is critical not just an addition 2) I'm not so 
sure about having exter/exit editmode as part of the world module as the 
same type of 'EMesh' will need to be written for the armature code for 
bone selection and I don't know how we would distinquish between mesh 
editmode and armature editmode. It would seem to me to be much more 
sensible to have enterEditMode() as part of the NMesh or EMesh module as 
it applies to meshs and not to armatures, lattices, etc. Also editmode 
only applies to a single object at a time not the entire scene - nor 
does it apply to 'world' objects.. Example could be: 
myMesh.enterEditMode() where the module fuction is called from NMesh - 
don't know but having a global editmode might be too narrow imo.