From BlenderWiki
Before Merge
Review
For code I think we had enough review already, refactoring and improvements here and ongoing, but we still miss some user level review which should be done before merge.
- Run regression test.
- Go over and test each:
- mesh editing menu item
- paint tools (weight paint, vertex color paint & sculpt)
- each modifier
- Have experienced blender users run their own tests
(load their own scenes with BMesh and ensure its working). - define some tests for BMesh to ensure no bad performance regressions.
eg, for some non-trivial blend files.- test draw speed editmode and object mode.
- animation speed with modifiers - subsurf and armature specifically.
- compare memory used between bmesh and editmesh.
would help to find volenteers for these tasks
All problems should be reported to BMesh tracker:
http://projects.blender.org/tracker/?atid=516&group_id=9&func=browse
What to Expect Before Merge
To give an idea of whats expected from BMesh team before we consider merging.
- no key tools or editing modes should be broken, hair, sculpting, weight painting etc must all be functional.
_but_ accept some specific options to be marked as BMESH_TODO .
note, 2.6x still misses features from 2.4x, having overly high standards here isn't workable and just means BMesh will be postponed indefinitely, also consider BMesh has useful features missing from EditMesh. - no crashes/memory-leaks/strange behavior for common editing tasks.
- addons/scripts wont necessarily all work correctly. This can be managed by addon authors before the first release including BMesh.
Issue Tracker
For the purpose of our issue tracker please don't report bugs in...
- ngon tessellation failing on overlapping or non flat ngons (we know this needs improvement)
- scripts not handling ngons nicely - scripts should work, but handling ngons correctly is for after merge.
- bugs/errors in any addons _not_ enabled by default (after merge todo also)
Forwards Compatibility
Loading files saved in BMesh in 2.60 and older versions of blender should work (at the time of writing edge data for triangulation is not written and entering editmode crashes).
Files from BMesh load into 2.60 triangulated (ngons converted to tris), there are not many good options here unless we write 2 separate meshes once for BMesh and another for older blender versions.
Propose to write edge data into files so they load in 2.60 and older, but add logic into BMesh that knows to ignore these edges.
Also, this extra edge data will slow down saving so it will be disabled for undo which also uses save code - Campbell
When to Merge / Release-Cycle
- aim for 2.63 / 2.64
- this relese is to focus on bmesh, no other large changes that touch mesh editing - mesh/display/modifier/tools code.
- merge needs to happen early on in our release cycle to give the most time to be ready for release.
- allow up to 1 month extension on our regular release if we need more time to stabalize,
of course if this seems likely we should delay merging bmesh another release.
Who Agrees When to Merge?
- bf-admins & the go ahead from active bmesh developers.
Steps to Merge
Pre Merge (minor changes)
Before merging bmesh we should pull in general changes from bmesh,
- BLI_cellalloc removed from bmesh
- DeformWeight's move to cellalloc. removed from bmesh
- Other changes to headers util-defines done
- BLI_array.h (header only malloc lib) done
- Changes to generic API's
- undo_editmode_push now takes different args
- ED_object_add_generic_get_opts takes extra arg
Create EditMesh branch
Make a branch for editmesh and keep the last version of blender before the BMesh merge, Just as we have a 2.4x branch. This is useful so we can test & compare tools without having to go back revisions.
Merge BMesh to Trunk
As said before this happens at the start of the merge window, we need to be confident no big issues are being merged in and that we're able to resolve bigger issues in time for release. or at least not push the release back too much.
--Ideasman42 01:25, 1 December 2011 (CET)
