Editing User:Bhollister/Proposal

= Title = 

Command-line Editing NMG Data-structures in BRL-CAD 

= Abstract =

This project will expose some of the low-level NMG routines to a command-line interface. Users will be able to add and remove various parts of the NMG data structure, such as regions and shells, along with manipulation of vertices, edges, and faces. Users will see the results displayed in either MGED or Archer.

Additional info: http://people.ucsc.edu/~behollis/hollisterGSoC2015Revised2.pdf

= Benefits to BRL-CAD =
BRL-CAD will gain a command-line interface for directly editing NMG data-
structures via Archer. The new features will be:
* Ability to select subsets of an NMG via the command-line.
* Ability to add and remove elements of an NMG while still satisfying validity constraints through the command-line.
* Ability to move parts of an NMG via the command-line.
* Visual feedback in the geometry window.

= Deliverables =
The implementation will consist of C code integrated with relevant modules
(/librt/primitives/nmg/, etc.).

= Project Details =

The fundamental data-structure for boundary representation in BRL-CAD is
the NMG. It is an implementation of a radial-edge data-structure and does
not enforce manifold constraints on mesh data. Boolean operations are closed
under the B-rep data type, thus making the NMG the preferred representation
for BRL-CAD.
The NMG Library Interface [1] is fundamental to the functionality proposed
here. There are broad categories of function calls that allow a high-level manipulation of the NMG data-structure in BRL-CAD. The categories are:
* CONSTRUCTION ROUTINES; for example: nmg mm(), nmg mmr()
* DESTRUCTION ROUTINES; for example: nmg kill(), nmg kr()
* MANIPULATION ROUTINES; for example: nmg face g(), nmg face bb()

The NMG data-structure hierarchically stores the mesh by: regions →
shells → f aces → loops → edges → vertices. Access into the data-structure
is provided by the high-level manipulation routines. For instance, when pro-
viding the ability of a table edit to change a vertex position, it will be nec-
essary to update the specific vertex in the table via the the nmg vertex gv()
routine. This routine requires a pointer to the vertex struct in the NMG data-
structure that represents the vertex. Other manipulation routines, such as
nmg ck closed surf(), i.e. “Check for a Closed Surface,” provide tools to enforce
various validation constraints.

The command-line functions will mirror the existing API, but expose as
much as possible. The interface may borrow some from the Blender low-level
API, using the following (see http://wiki.blender.org/index.php/Dev:2.6/Source/Modeling/BMesh/Design):
* BM vert createkill: Make Vert and Kill Vert
* BM edge createkill: Make Edge and Kill Edge
* BM face createkill: Make Face and Kill Face
* bmesh semvjekv: Split Edge, Make Vert and Join Edge, Kill Vert
* bmesh sfmejfke: Split Face, Make Edge and Join Face, Kill Edge
* bmesh loop reverse: Reverse the loop of a BMFace. Its own inverse

= Project Schedule =

Milestones:
* Week 1: Add placeholder commands by following example in commit 46507, which adds the exist command. Make sure that commands can be added and data is reflected internally.
* Week 2: Identify ways of specifying to the command-line the parts of model to be changed. For example, how to specify a vertex to a command that removes a vertex and update the NMG model in the render window.
* Week 3: Should be able to implement commands now. Allow two weeks to complete each type of command. Starting this week with NMG CONSTRUCTION ROUTINES.
* Week 4: CONSTRUCTION ROUTINES - initial take is to provide CLI for existing internal nmg_* api routines.
* Week 5: CONSTRUCTION ROUTINES - initial take is to provide CLI for existing internal nmg_* api routines.
* Week 6: CONSTRUCTION / DESTRUCTION ROUTINES. 
* Week 7: CONSTRUCTION / DESTRUCTION ROUTINES. 
* Week 8: CONSTRUCTION / DESTRUCTION / MANIPULATION ROUTINES.
* Week 9: CONSTRUCTION / DESTRUCTION / MANIPULATION ROUTINES.
* Week 10: Test / Feedback from users. May need to iterate on prior weeks.
* Week 11: Test / Feedback from users. May need to iterate on prior weeks.
* Week 12: Test / Feedback from users. May need to iterate on prior weeks.
* Week 13: Test / Feedback from users. May need to iterate on prior weeks.
* Week 14: Final fixes and clean-up.