Let's start a discussion about the priority order for the Bmesh TODOs and where the line could be drawn for "this is good enough for merge with trunk". While this is aimed at the bmesh developers, input from other Blender developers would also be appreciated.
The list of TODOs is at http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/BMesh. Also, see Campbell's review of the state of the branch in May at http://wiki.blender.org/index.php/User:Ideasman42/BMeshBranchReview. Here is my strawman proposal, just to give us something concrete to discuss and modify. *What level of "stability" is good enough for merge?* *From a user-visible functionality point of view, we could choose any of these levels, in increasing order of difficulty to reach:* 1. Where we are today is good enough 2. Where we are today for functionality is good enough, but also require zero crashes during extensive testing and some long modelling sessions. [From here on the 'zero crashes during extensive testing' is assumed.] 3. Functionality should match trunk with possible minor regressions for rarely-used things. 4. Functionality should match trunk in every way. 5. Functionality should match trunk in every way and there should be some progress on 2.49 -> 2.5x regressions. 6. Functionality should be as good as 2.49+trunk in every way. 7. There should be some significant new tools (e.g., proper inset; intrude) to make up for some likely pain during the transition period. My vote would be 3, with some discussion (here) to reach agreement on what minor regressions would be acceptable. *From a memory/performance point of view, we could choose any of these levels, in increasing order of difficulty to reach:* A. Where we are today is good enough (Campbell's review says: Bmesh data structure ~1.5x bigger, deforming subsurf 2-3x slower). B. Where we are today is good enough for memory, but all performance measures should be at most a factor of F slower (F to be decided here; 1.5? 1.1?) C. Memory usage and performance have to be about the same as current trunk. My vote would be B, with F=1.5. *From a code cleanliness point of view, we could choose any of these levels, in increasing order of difficulty to reach:* I. OK to have lots of BMESH_TODOs, #ifdef 0's, commented out code, unused functions and unused files, as long as functionality and performance criteria are met. 2. The only commented out, unused, etc., code should be stuff that we are pretty sure will be brought back but don't need to yet (because functionality and perf critera are met). 3. There should be no #ifdef 0's or commented out code or unused functions (except those already in trunk), and only minor BMESH_TODOs. Also no compiler warnings. 4. Like 3., but also no BMESH_TODOs left. My vote would be for 2 or 3, not sure which. *What is the priority order for TODOs?* The TODOs are in two parts: first are know user-visible deficits and the second are the places in the code with BMESH_TODO. Probably many of the code todos are responsible for the user-visible deficits, it is hard to understand all of those connections without a deeper understanding of the code than I have right now, so let's talk about them separately. Here is my strawman ordering of the user-visible TODOs, from most important to least important. I imagine there will be a lot of differing opinions here, but mostly it won't matter unless we decide on functionality level 3, and then all that matters is what is above and below the 'allowed minor regression' dividing line. * crash when: extrude a vertex, hit ctrl+R * loopcut segfault on ngon shared face cuts (if still live; can't reproduce right now) * sculpt display update is delayed until mouse release: on cube in sculpt mode, pick grab brush, drag a point and see it doesn't move until after mouse button release * automerge Editing * extrude individual bug: select a cube, edit mode, face select mode, extrude individual -> mess. * knife tool still not completely working in ortho mode: on default cube with loopcut at z = -.5, knife from top edge to bottom - the loopcut will not be cut * knife tool doesn't respect "use_occlude_geometry" setting. If I start a knife cut "off" the mesh and drag across the mesh and confirm only the front faces get cut regardless of that backface toggle.... * make sure mirrored tools work (MirrorObject for instance does not seem to work) * rip tool doesn't work in many cases where ngons are in the mesh and "selection" isn't maintained; does not work correctly with cuts made by knife tool (faces disappear, or in dosen't work at all) * bevel (especially with recursion) give unwanted results, it seems to be depended on how big surrounding faces are. Also, could be more interactive. * merge two vertices (Alt-M) of cube inverts some normals * old split tool is not present so won't separate geometry: new split "y" tool is only for adding edges to ngons.(so either a new tool and key shortcut is required or more context sensitive behavior) * weight paint not mirrored properly on cylinder with both mirror and subd modifiers. * texture painting, vertex painting, skin weighting: face selection (Bkey box; CKey Paint) doesn't work * animating: add 1 shapekey to a "heavy mesh" and playback speed crawls [[User:ZanQdo|ZanQdo]] * UVs > Show/Hide Faces (the only thing it does is deselecting) * UVs > Snap > Selected to Adjacent Unselected * UV island select selects all, instead of just the island of interest * solidify tool doesn't work * bevel as modifier doesn't work * snap to self (use_snap_self) doesn't work when the snap element is set to edge or face (r39529). * loop select doesn't work on circle (probably all chains of 2-valence vertices) * recalculate Normals Inside is impossible. * vertex parent is not correct. * make face (F) tool doesn't work with mix of edges and an isolated vertex, cf http://www.pasteall.org/blend/8366 . * UV: follow Active Quads (always give the error "Active face not selected." even though it's) * Select > Side of Active * Select > Every N Number of Verts * need to go through all trunk scripts and maybe contrib too to make sure they mostly work (probably won't work with ngons of course, but otherwise hope they mostly just work) * fix at least some import/export scripts or C code to handle ngons (obj, collada); for obj there is now C code for export, perhaps do C code for import too. * knife snap-to-vertex radius seems too big * UV: stretch is shown wrong for area * UV: stretch is not shown for angle * 3D View's header is not updated after validating a loopcut. * Suzanne Mesh unwrap has a few vertices in wrong place (very long spikes) * looptools: bridge fails, circle doesn't do what it should, relax works but a bit weird ------- strawman for dividing line? ------ * change the number of loopcuts with the number keys * Sort Faces Menu is missing (Needed for build modifier). * Smart UV Project * Lightmap Pack * rigging: sketch-a-ton * faces flash once when doing extrude * face center dot disappears when doing mesh editing * make face doesn't work if more than two edge chains selected. * scripting: read and write access to real (n-gon) faces * scripting: read access to edges of face, faces of edge, edges of vertex, perhaps using walkers * old knife functionality has no equivalent: freehand sketch... * loopcut like 2.49:cut proportionally (ie a percentage along the edges)is oimplemented, but not " relationally " (a fixed distance from the start or end points of the edges...) * (Maybe) dissolving two crossing edges out of 4 at a vertex leaves the vertex - which may seem invisible to artist if the edges left are collinear. Maybe fix? * (Maybe) make face with two vertices selected on a face should cut like Y * New UV Maps are called "Face Texture". This is not what they are.. they are UV Maps *Code TODOS* - let's discuss those in a separate message, this one is already too long. - Howard Trickey _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
