[Bf-taskforce25] BMesh integration status

[Brecht Van Lommel]

Hi Joe,

Thanks for the status update, nice progress.

Brecht.

On Tue, 2009-07-21 at 07:05 -0600, joe wrote:
> I've done quite a lot of work at integrating bmesh into the 2.5
> codebase.  I've replaced EditMesh with BMesh (though not completely as
> yet, a lot of stuff still uses EditMesh), changed mesh DNA, modified
> DerivedMesh and made a good start at getting all the modifiers working
> with ngons, and a bunch of other stuff.
> 
> BMesh doesn't directly replace EditMesh.  Instead, I created a wrapper
> structure around BMesh called BMEditMesh, that stores a bmesh, it's
> triangle tesselation, and a bunch of stuff that didn't belong in the
> BMesh structure itself.  I've ported a lot of tools to this new
> infrastructure, though there's still a lot to be done.  I've made the
> remaining EditMesh tools interface with BMesh, though this hasn't
> worked out well; I hope to port over all existing EditMesh tools
> before commencing serious user testing.
> 
> The changes I made to mesh DNA are pretty much as we discussed
> earlier.  MFaces are now used to store the tesselation of the mesh,
> while a new layer (MPolys and MLoops) are used to store real faces.
> MPolys logically represent a face, while the face boundary itself is
> defined by a series of MLoops (stored in one contiguous array for all
> faces).
> 
> The new face structures are:
> 
> typedef struct MPoly {
>     int loopstart;
>     int mat_nr;
>     int totloop;
>     int flag;
> } MPoly;
> 
> typedef struct MLoop {
> //vert, edge indices
>     int v, e;
> } MLoop;
> 
> Mesh {
> <all the stuff in Mesh>
>     MPoly *mpoly;
>     MLoop *mloop;
> }
> 
> MPoly->loopstart points into mesh->mloop.  MPoly->totloop defines the
> number of MLoops, and together the mpoly and the mloops define the
> boundary of the face.
> 
> On the DerivedMesh side, I added simple face iterators to DerivedMesh.
>  I did this for two reasons; I wanted to evaluate the possibility of
> porting DerivedMesh to be entirely iterator-based, and it also seemed
> like using iterators would be easier then matching the design of the
> rest of DerivedMesh, given the new split nature of faces into
> MPolys/MLoops.  I'm no longer convinced this was a good idea, and I
> may rewrite it if I get the chance.
> 
> The Subsurf, array, and mirror modifiers are now ngon-aware.  Subsurf
> still has some work left to be done (e.g. with CustomData
> interpolation).  Both array and mirror now use bmesh; array is mostly
> working, but has a few minor things done, while mirror is pretty much
> finished.
> 
> At this point, I've started tackling the UV editor/unwrapper code.
> UVs are now stored per-loop, and I've managed to port much of the uv
> editor code to this new representation in the past few days.  My plan
> is to finish this, port over vertex/weight paint, and then concentrate
> for a while on stabilizing mesh editmode; rewrite old EditMesh tools
> in BMesh, fix bugs, and in general get that stabilized.  Once I've
> gotten this next bit with the UV and vertex/weight paint code done, I
> figure I'll be finished with the major refactors, and can concentrate
> on getting what I already have stabilized.
> 
> Joe
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>