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

[Campbell Barton]

Hi Howard, sorry for not replying to this earlier,

Ill reply to each of you're points inline, then write up my own
suggested proposal on the wiki.

On Sat, Aug 27, 2011 at 3:58 AM, Howard Trickey
<howard.trickey at gmail.com> wrote:
> 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.
Agree on 3 too, zero crashes is a good terget but think realistically
we'll probably only get to *almost* zero crashes.

> *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.

Joe addressed the memory issues I mentioned in my review. Im ok to go
with whats in trunk.
Also, I did some benchmarks recently with deforming meshes and it
worked as fast as in trunk, Ill need to further look into it.

> *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.

I'm not too worried about this, as in - I think we will deal with it
when the time comes, IMHO think 2 is fine.

> *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.

What you suggest here seems roughly ok, but Id like to handle this differently,

My concern is that we make some big list of whats needed and say ....
15% of these end up being really hard to solve and hold the project
back.

If we make a list of useful features in 2.4x, blender 2.5x _still_
misses some of these, so I think being too picky on a per-feature
basis doesn't help the overall project so much.

Instead I rather to divide BMesh into sub projects (Editing /
ModifierStack / ImportExport... etc) and have a summery of the bare
minimum of what should work within that (Ill post shortly)

I think this lets developers better focus on what they are capable
of.... when it comes closer to merging it will become more clear if
there is anything really standing out as missing in any areas - If
that happens we can choose if its a blocker or not (we == BMesh devs +
BF-project admins).

Will write up proposal next,

- Cheers.

> * 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell