[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