[Bf-committers] bmesh: priority order and plan for bmesh TODOs

[Howard Trickey]

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