[Bf-committers] Future of the Python API : was EditMesh funcs must no longer be static

joeedh joeeagar at prodigy.net
Fri Oct 8 19:13:18 CEST 2004


Tom Musgrove wrote:

> [QUOTE] I have severe troubles with exposing editmesh to python.[QUOTE]
>
> What we are doing right now is just allowing the retrieval of the 
> perspective matrix, which has been added to the Window module.  Then 
> doing everything else in python.  So thus far we aren't using edit 
> mesh stuff.
>
> The current method is blazing on 400 face and verts (a simple head or 
> basic object), fast on 7000 faces and verts (make human), but 
> something complex (such as Poser models- 60,000 vert 120,000 faces) it 
> is too slow to be usable.

And I myself almost managed to make something similar to this script 
(well, in a kindof faked way in that it only worked on individual faces) 
with my EMesh module.  The main problem seems to be that repetively 
calling findnearestface can cause it to stop working.

>
> [QUOTE] The editmesh is highly critical code that needs to be fully 
> reliable & stable, bothering about what's exported to third parties is 
> not a  requirement I like to see happening now.[/QUOTE]
>
> The lack of any API is resulting in coders jumping through hoops to 
> accomplish tasks that ought to be accessible from python.  A promise 
> that the API won't change isn't really necessary.  We've had API 
> changes that have caused breakage in the past, and if they were 
> scripts that people were interested in, they got updated.  Just put a 
> great big hairy warning regarding using the API, and make the list of 
> exposed APIs fairly small.

Unfortunately by it's nature, EMesh has to be a fairly low-level 
wrapper.  Putting an abstraction layer between it and the actual 
EditMesh functions would not work.

>
> This way, even if huge changes are made in the way things are done 
> internally, updating the API to use the new C code will be a 
> reasonable task.
>
> As long as the API coders know that you plan to possibly make large 
> changes that may neccessitate rewriting the wrappers, and as long as 
> you make that clear to end user programmers, then exposing some of the 
> functionality seems reasonable.

Yes.  Exactly.  We need EMesh!  And I'm almost done with it!!!

>
> [QUOTE] So what's the focus of our Python API? It can't be replacing C 
> coding... for that Blender wasn't designed at all.[/QUOTE]
>
> Why shoudn't it largely replace C coding?  While it might make some 
> tasks easier if Blender was 'designed for it', as far as python is 
> concerned that isn't really relevant.  For your typical programmer, 
> python is vastly more productive (due to expressivity, introspection 
> capabilities, clarity of style, and interpretive language debugging 
> methods), and for non programmers it is straight forward enough that 
> artists can use it to create their own specialized tools.

True.  Actually a great deal of Blender could be rewritten in Python.  
The problem is whether or not we want that.  But that doesn't apply to 
our case; EMesh isn't going to replace any of the EditMode functions 
(although it can!).

joeedh


More information about the Bf-committers mailing list