[Bf-committers] bmesh merge timeline

[joe]

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
>