[Bf-committers] bmesh merge timeline

[joe]

Oh.  Forgot about lukas's project; I think we can still merge that in
in the near future.

Joe

On Tue, Sep 8, 2009 at 3:50 AM, joe<joeedh at gmail.com> wrote:
> Ok plan B (actually, the first plan A): Bmesh will be merged in after
> the october release, when it's stable enough to not interfere with
> durian development.
>
> In order for this to go smoothly, it's important to limit the amount
> of work done on the mesh system in 2.5 to a bare minimum.  Obviously
> loopcut and knife cut and edge slide has to come back, and twiddling
> with UIs is probably fine (if annoying to merge).  But it's important
> to make no large-scale changes, especially to DerivedMesh.  Remember
> that I have to rewrite or adapt *everything* you do. :)
>
> Also, post-bmesh I think it'd be best if people didn't manipulate mesh
> DNA through python scripts directly; all write-access for meshes would
> go through a bmesh py api, or at least some sort of higher-level
> python api with careful consistency checks.  To this end, I'd like to
> request that we hold off on a fully-functional mesh api for now, so
> people don't end up writing scripts that simply won't work post-bmesh.
>
> So here's another (integrated) todo list:
>
> * Port all remaining editmesh tools to bmesh (beauty fill, join
> triangles, edge fill, path selection, probably lots of minor tools).
> * Don't do loopcut or edge slide, wait for them to show up in 2.5 first.
> * Multires! Multires will likely need significant refactoring.  I'd
> appreciate it if anyone could send me a list of what features the new
> multires supports, and it's limitations, so I can think about
> realistic solutions to suggest to Nick.
> * Sculpting probably needs some work, I've not even tested it.
> * Edgesplit modifier.  I've prototyped a fast algorithm for this, just
> a matter of writing it in C one of these days.
> * Deal with the (probably dozens of) unexpected small problems and
> unfinished issues.
> * Get shapekeys to work, bringing back the old editmode hack is
> probably good enough for now.
> * RNA api for bmesh, and updated (read-only) api for mesh dna.
>
> Joe
>
> On Tue, Sep 8, 2009 at 2:47 AM, joe<joeedh at gmail.com> wrote:
>> I think we should merge bmesh into 2.5 in the next couple of weeks.
>> At first I wanted a completely stable and finished system before
>> release, but I don't think that will work.  For one thing, we'd have
>> to get editmesh into shape instead, which would mean parallel
>> development (and would be very bad).  For another, the october release
>> clearly isn't going to be 100% functional or stable anyway.  It seems
>> all around better for development to merge it in now.
>>
>> So, the proposed plan is:
>>
>> 1. Merge lukas's project into 2.5 this week.
>> 2. Merge bmesh into 2.5 a week or two later.
>>
>> Lukas's code seems fine to me; I've looked over it.  Editmode handling
>> could be improved, but that's not lukas's fault; designing a really
>> robust system for sending incremental updates to the GPU for editmode
>> was outside the scope of his project, really, especially given the
>> architectural changes within DerivedMesh, the drawing infrastructure,
>> etc it likely would have required.  Besides, what he managed to get
>> working gives a significant (70% I think?) speedup in editmode,
>> anyway.
>>
>> Bmesh integration is fairly close to feature complete.  Here are some
>> lists of missing features:
>>
>> Things needed before 2.5 is released:
>> * Edge Slide.
>> * Loopcut.
>> * Make sure theeth's etch-a-ton thing works.
>> * Edgesplit modifier.
>> * Remove doubles tool (the code is there, I just need to hook it up to
>> a wm operator).
>> * Probably a bunch of minor things I'm not yet aware of.
>>
>> I can do all of the above.
>>
>> Editmesh tools that sortof work via the editmesh<->bmesh bridge, but
>> should be properly bmeshafied:
>> * Various selection tools; e.g. shortest path.
>> * Beauty fill.
>> * Edge fill.
>> * Triangles to Quads.
>> * Add Primitives.
>>
>> I'd like these to be done before the release, but it's not really
>> terribly important to do so, functionality-wise.
>>
>> There's also the issue of an RNA api; mesh RNA needs to be updated,
>> and an RNA wrapper around bmesh itself needs to be written (people
>> really shouldn't be writing python scripts that write to mesh DNA
>> directly).  I'm not sure if that last one is feasible before 2.5; if
>> not, people will simply have to live with limited mesh scripting
>> capabilities.
>>
>> Joe
>>
>