[Bf-committers] Mesh development freeze

Brecht Van Lommel brechtvanlommel at gmail.com
Mon Apr 13 22:33:31 CEST 2009


Hi Joe,

joe wrote:
> I'm requesting a freeze on all non-bmesh-related mesh development
> (excluding modifiers).  In the two times I've participated in
> significant mesh refactors (first hemesh, then when I kickstarted the
> bmesh branch), both suffered from other people doing concurrent work
> in the same code I was refactoring.  The second was the worst; during
> the first major push at integrating bmesh, significant work was done
> on DerivedMesh in trunk (digging that particular hole deeper and
> deeper) which after a certain point killed that branch, and all of the
> integration work in it.

Can you give an estimate for how long this freeze would be needed?

> 1. Replace editmesh with bmesh.  Mesh DNA unchanged.
> 2. Change mesh DNA, but in a backwards-compatible way (which is yet to
> be finalized).
> 3. Improve stability of existing code/tools.
> 4. Period of user testing and developor feedback
> 5. Merge with 2.5.  Note that some editmesh legacy tools will remain.
> DerivedMesh will not be ngon-aware,
>    though there might be a hack for subsurf to work with ngons properly.
> 6. At some happy point in the future, gradually refactor DerivedMesh
> so it actually becomes useful as an abstract mesh
>     structure.  This'll be done in steps, I imagine, slowly replacing
> certain interfaces with ones based off of
>     geometry iterators.

Which mesh DNA changes are needed? I thought f-gons flags would be 
sufficient at that point?

Thanks,
Brecht.


More information about the Bf-committers mailing list