						 -*- coding: utf-8 -*-
BRL-CAD To Do List
==================

This document contains a collection of desirable BRL-CAD development
tasks.  Included is a list of the tasks expected for the current
monthly development release iteration, tasks that will hopefully be
completed within two iterations, and a remaining "backlog" of
unscheduled development tasks.

This is not an official list of tasks that will be completed.  Instead
it's more like a developer scratch pad for recording ideas and
coordinating release tasks.  At the beginning of each month,
developers add the tasks they expect to complete and then remove those
tasks as they are completed.


THESE TASKS SHOULD HAPPEN BEFORE THE NEXT RELEASE
-------------------------------------------------

* coordinate with bext to have it produce a manifest of what
  files need strclear/plief processing of various types so
  we don't need to redo the characterization pass every time
  we configure.  We have strclear and plief in bext, so that
  repo should be capable of doing the work for us as a post
  build step whenever bext changes.


THESE TASKS SHOULD HAPPEN WITHIN TWO RELEASE ITERATIONS
-------------------------------------------------------

* DEFERRED mouse sweep rect

* DEFERRED apropos (view command

* fix ARB8 promotion to BoT, so calls between prep and shot don't get
  inconsistent data (soltab needs to match).

* verify arb6 editing in cheese wedge tutorial

* rtarea is sometimes missing regions on summary reporting, at least
  on Windows, possibly a threading issue setting up the results
  container.


THESE ARE UNSCHEDULED BACKLOG TASKS
-----------------------------------

* make sph sph
  clone -i 1 -t 1000 0 0 -n 100 sph
  kill sph
  g line sph*
  clone -i 1 -t 0 1000 0 -n 100 line
  kill line
  g square line*
  clone -i 1 -t 0 0 1000 -n 100 square
  ... takes a crazy long time ...

  This should be merely 1M spheres, but it chokes with non-linear time
  increase.  Appears to be excessively reading/writing objects and
  getting slower as it progresses.  Needs to be optimized.

* Add two-tiered option handling to tire, propeller and naca456
  For most uses we'll want a few pre-baked high level settings -
  those can be command line flags.  For full control of the complex
  settings, we should take a JSON file that holds detailed settings.
  Idea is more general than those 3 tools, but they are low risk
  experimental targets that would all benefit from the approach.

* write meshing/remeshing/decimation guide

* fix libanalyze.  it has turned into a seeming dumping ground with no
  design or naming consistency evident or documented, or at least
  extensive violations from the prevailing analyze_* naming prefix and
  binary interface to analytic routines.  notable outliers include
  nirt_* (including CLI handling..), voxelize*, rt_gen*, rectangular*

* ensure datum objects convert out via g2asc and back (currently
  writes "a Tcl output routine for this type of object has not yet
  been implemented")

* fix recursive bu_parallel() to not have a hard-coded limit on the
  number of threads or to more aggressively abort when more that
  supported are dispatched.  currently supporting 64x64 threads and
  still with some potential for race conditions on the book-keeping.

  [HARD] Concurrency heisenbug cluster: hard-coded 64x64 thread limits
  plus ID/bookkeeping races (IDs exceeding MAX_PSW).  Fixes must be
  provably correct under contention across pthreads/C++11/Windows.  See
  BUGS "recursive bu_parallel() failure", "race condition causing bus
  errors on exit", and the gqa semaphore-contention item.
  [FAN-OUT: yes for the audit -- one agent per bu_parallel() call site
  / semaphore user -- but the actual race fix needs one careful hand.]

* Teach lint command to look for comb instance paths with non-uniform
  scaling matrices that have tor primitives as leaves - those will not
  raytrace as expected.  May be other primitives that should be
  searched for as well.  Would be ideal if we could also have the comb
  creation routines (group, comb, r...) reject any operation that
  would result in such a configuration being created and reporting the
  details of why it wouldn't work.  Maybe allow a -f forcing flag to
  do it anyway, since it *can* be done currently in MGED, but it
  definitely seems like a practice to discourage - if TOR did someday
  get support for handling such raytraces, any users depending on it
  NOT doing that would be caught by surprise.  Seems more likely
  though that users would expect the TOR to be stretched (as it is in
  comb editing wireframes) and be let down when it ultimately doesn't
  work...

* Per discussion with Sean - look into whether the draw command
  (probably the one in the qged draw stack) could be modified to do
  async population of drawing structures, starting from fastest
  possible and refining to greater detail.  Goal would be to make draw
  a non-blocking operation for the GUI, getting up whatever info we
  can quickly.  Might also be able to take into account metrics like
  FPS and memory usage to decide when we're approaching the "too much
  info for available resources" threshold.

* consider retiring the mater -d option in favor of a "mater density"
  subcommand (which is really how it is being used anyway.)  Might be
  worth considering whether shader related functionality should go
  under a "mater shader" subcommand.

* implement nirt flag to report a secondary ray fired in the direction
  of the hit point surface normal.

* calculate maximum/minimum presented area az/el for a given model

* convert non-planar arb's to brep objects for ray-tracing.  see how
  well it works to see if we can remove an arb limitation.

* explore c++ fastf_t class.  compile-time support for using GMP or CLN
  for arbitrary exact precision arithmetic computation support

* Update find_package uses to take advantage of EXPORT targets when
  upstream packages have them available.  This should let us reduce
  the number of Find*.cmake files we need to include.  Ultimately,
  we may want to look at using the new *Config.cmake mechanism for
  all bundled dependencies, except when we still need Find*.cmake
  to locate system installs that don't provide them.

* Windows installer does not respect the "add to path" checkbox
  and always adds BRL-CAD to the system path

* Look into https://www.kitware.com/really-fast-isocontouring/ to see
  if those algorithms could be useful for BRL-CAD

* Investigate https://github.com/zeux/meshoptimizer to see if its
  algorithms would be useful for our BoTs - unless there's a reason
  not to, writing out optimized meshes might help performance in
  a few graphical display cases.

* There are probably a number of algorithms in our code where
  we should check to see if the GTE implementation would be better
  than ours (line/point distance functionality, for example).

* add a flag to prefix command to remove prefix on a group hierarchy.

* restore libged commands that were only exposed via archer but lost
  during libged ged_exec() refactoring.

  see 5f8aa3204bd for a number of them, but need to check all of the
  archer command mappings.

* add rt* option to output reusable view specification similar to
  saveview scripts, but perhaps just the command portion.  this would
  be similar to what 'art' does, so a given rendering can be reloaded.

* make saveview and loadview work with and output rt command scripts,
  not shell scripts.  to work, rt command scripts will need to bake in
  the entire view specification including perspective, ambient, and
  append/overwrite properly when writing out to the same file
  (currently appends additional invocations).  primary use case will
  be to save out multiple view iterations that render the sequence to
  multiple files.

* explore whether we can write a command to replace bad brep
  3d edge curves with ON_BezierCurve::Loft approximations of
  3d points evaluated from a valid 2d parametric curve associated
  with the same edge.  Hoping to use this to repair geometry
  that has valid face and 2D parametric info but bad 3d edge curves.
  Preliminary work is in the brep repair subcommand.

* ability to draw lines, boxes, and text on rendered outputs/images.
  we sort of have this ability through plot3 and composition tools
  but end-user request was integration with rt* tools so, for
  example, there could be a way to specify a coordinate frame overlay
  on images output by rtwizard, using stippled lines.

  some existing APIs with similar functionality include opencv,
  matplotlib, matlab, and processing

* ability to place/align/mate objects tangentially, e.g., having a
  vehicle rest on a piece of terrain or putting one object next to
  another object.

* race condition causing bus errors on exit

* material infrastructure has regressions due to attr sync code that
  needs to be resolved.

* dbconcat corrupted database / failed. created a top-level comb with
  invalid "1_[subcomb]/" to be created that result in error messages
  during any db listing (e.g., tops).  workaround was to manually edit
  the comb and remove the 1_ and / on the entries.

* The following will be removed from MGED's menu bar (unused
  features, can be accomplished another way, or will be exposed
  only as lower level settings when there are sensible defaults
  that are seldom changed.)

  Modes->Display Lists
  Misc->Keystroke Forwarding
  Misc->Depth Cueing
  Misc->Z Buffer
  Misc->Lighting

* implement uv-mapping callback so we can texture-map BoT, NMG, and
  NURBS geometry

* modify libfb's default memory buffer allocation to be dynamic

* create a BRL-CAD .g with all possible object types embedded.
integrate into testing. e.g., scene with all object types plus a
lookup check to ensure none are missing.

* fix pipe subtractions shaded display issue in archer

* attribute normalization is drastically slowing down region creation
  - need to fix or back out

* add regression test for directional light sources

* bundle primary rays in rt front end into postage stamps, shoot via
  rt_shootrays(), modify to pass all rays down through the spatial
  partitioning simultaneously

* re-add support for vrml v1 to g-vrml so that users can select
  whether they want v2 (default) or previous v1 output format via a
  command-line switch.  see
  http://brlcad.svn.sf.net/viewvc/brlcad/brlcad/trunk/conv/g-vrml.c?view=diff&pathrev=22798&r1=16900&r2=16901

* metaball in command input needs sanity checks and better validation.

* integrate gen-registered-attributes-html output into website

* OpenCL for enhanced performance boolweave sorting

* create boolweave+boolfinal unit tests to validate weaving behavior
  and performance.

* tree command shouldn't infinite loop when encountering a cyclic path
  - need to print a warning and stop walking.  Requires full path
  awareness in tree command walk.

  Consider implementing a corollary to FTS instead of dirent for
  simplified tree traversal with cyclic awareness.

  https://keramida.wordpress.com/2009/07/05/fts3-or-avoiding-to-reinvent-the-wheel/

  [HARD] Needs a full-path-aware, stack-based replacement for the
  recursive db_walk_tree with general-graph cycle detection; touches
  every hierarchy-traversing command.  See BUGS "Recursive submodel
  predictably goes infinite" and the clone-1M-never-returns case.
  [FAN-OUT: yes -- audit all recursive-traversal call sites in
  parallel; the new walker is written once and rolled out.]

* bounding box reduction command

* consolidate dbconcat, clone, make_name, and any other .g I/O
  routines that need to autogenerate names to use the new
  bu_vls_incr/bu_vls_simplify functions.

* g-obj not exporting colors

* heap unit test needs to actually compare performance against system
  allocation, not just do some work

* mged> nirt -f fmt needs output cleanup. When run with -f csv there
  are unexpected warnings and duplicate line prints

* move the rt_*_timer timing facilities to libbu and rework to allow
  contexts, allowing for more than one timer to be active.  Make sure
  the old librt API can be obsoleted cleanly.

* consider user interface and usability implications of gchecker
  and/or overlap_tool as commands that kick off GUI.  need to consider
  if there's a non-GUI output/utility and how the CLI pairs up with
  other GUI-inducing commands like rtwizard, raytrace control panel,
  geometree, etc.

* automatic tops

  db_ls with the DB_LS_TOPS flag can supply us with a list of top
  level entities.  Implement a db_tops_default() to support automatic
  default object loading for commands like rt* that typically work
  with top-level objects.  let some commands default to an unspecified
  object when there's an identifiable priority according to matching
  criteria:

  a) _GLOBAL has a tops_default attribute set, default to that object
  b) there's only one object, default to that object
  c) there's only one comb, default to that comb
  d) there's only one comb (sans any ext) matching filename (sans ext)
  e) there's only one comb with pattern matching '^(all|scene)*'

  if _GLOBAL has a tops_default attribute set to empty/negative, then
  this behavior will be disabled.

  when there is not a match, the commands should report out the
  available top-level objects by default.  that way the user doesn't
  have to manually run mged to figure out what can be rendered.

* automatic ground plane

  Need ability to auto-calculate a ground plane default for a given
  model.  Need render option to display the ground plane (e.g.,
  auto-insert a half or arb8).  Need libged command for
  creating/manipulating explicit ground objects.  Needs to work with
  ground_plane_offset attribute on _GLOBAL.

* audit support for slashes in object names and commands that expect
  paths or can/should have meaningful behavior with paths

* default tops to undecorated, deprecate -n, add tops -p

* default ls to undecorated, deprecate -n, add ls -p

* consider not using spaces in the default installer path on Windows
  for simplified scripting usage (e.g., when installed to C:\)

* color management of objects in mged/archer so you can brighten dark
  objects, darken bright objects, map objects to other colors, etc.
  related to the luminance adjustments being done in the Creo export
  plugin.

* idents command needs to have csv/xls output options and should
  output a column header and optionally not export the comment header
  for ease of import into spreadsheet programs.

* running mged geometry browser and selecting preview results in an
  error.  code appears to be assuming both /dev/X framebuffer and uses
  /dev/null redirect to sink output.

* rtwizard greys out the File->New and Open menu items when run with a
  filename, which is very confusing.  Either menu should remain usable
  or there should be some other indication that a file was specified
  and is open.

* the mged tutorials apparently do not mention the tops command (even
  once), but really should as it's the starting point for discovering
  what is in databases that are opened or imported.

* add metaball scaling feature (presently in a tclscript)

* ability to visualize metaball centerpoints and with/without
  translucency.

* add linear interpolation method for metaballs

* optimize metaballs performance case where there are lots of single
  points, no interpolation.

* add script/command for changing metaball weights in masse

* gdiff in mged appears to be broken?  get "no primitives found" on
  second comb when specifying two combs (gdiff comb1 comb2).  UPDATE -
  this appears to be a consequence of how gdiff internally implements
  its raytrace diffing.  The "fix" would be to separately raytrace
  each object and post-process the line segments, rather than drawing
  up everything at once - the latter has problems if part or all of
  comb2 is shared with comb1.  A workaround is to keep out comb2 and
  dbconcat it back in, then gdiff comb1 with the imported tree.

* pixscale doesn't seem to handle stdin (due to bu_seek) for very
  long

* The embedded framebuffer for the X display manager is not working
  with Tcl/Tk 8.6 - it brings down mged with an Xerror when it tries
  to XFlush after X24_blit.  Better solution is to replace the X dm/fb
  with a cross platform software rasterizing solution of some sort.

* extract a skin or other exterior surface for a given model.  3 options:
  1. Implement a "shrinkwrap" feature that calculates a concave hull
  2. Shoot rays from outside, construct exterior mesh based on hits
     (akin to marching cubes, a surface reconstruction)
  3. Shoot rays from outside at exterior vertices, retain all mesh faces
     and objects encountered (i.e., not reconstructed, but extracted)

* look into using Manifold::Hull() to replace our copy of QuickHull -
  manifold made some robustness improvements and we rely on them anyway,
  so we should probably just leverage them.

* latest Manifold has a Contains(vec3) method - that's likely quite
  robust and may be worth using in our code for "point in mesh" tests
  if it is performant enough.

* RTAREA

  * add an option to rtarea for onehit.  this is probably best as an
    option that reports the requested objects only and then has a
    verbose option for the more detailed hierarchical report that is
    currently produced.

  * verify rtarea.  There are reports that the rtarea
    command may have a bug in its calculations.  This needs to be
    investigated.

  * review and fix rtarea's taxonomy for describing
    presented/projected areas.  users expect presented area to
    represent what is currently referred to as exposed area.  may make
    more sense to introduce a different terms for other shotline
    encounters.

  * make rtarea display a cross-hair and perhaps coordinates for the
    center of area if run from within mged.

* bot -V check solid bot.s visualizations don't show up if bot.s is
  first drawn in MGED - should properly "overlay" them so the user
  doesn't have to first erase the solid from the scene visual.

* add bot plot and bot pick subcommands to mirror brep subcommands
  and let us inspect individual aspects of a BoT's structure.

* procedural studio box generation allowing for specification of size,
  shape, material, and lighting characteristics

* verify all of the src/util utilities behave correctly on Windows
  with respect to mode (i.e. correctly using setmode/O_BINARY when
  performing file I/O.)

* replace los references/terminology with span, len, dist, factor, etc
  accordingly since los is ambiguous and a source of user confusion.

* enhance env command to handle debug variables, use sysctl style
  groupings of variables, and in general make the setup simpler and
  more uniform (ideally we'll fold the debug command's capabilities
  into env in some form.)  Need to have a usability brainstorming
  session, but after discussion with Sean general outlines are to:

  Switch all debug variable management to staging through environment
  variables rather than directly setting hex values on the globals,
  but leave the globals as the low level mechanism for performance
  reasons (getenv is much more expensive, don't want it in core code.)
  Something like:

  LIBRT_DEBUG_HF (env variable) -> debug.rt_hf (env cmd) -> rt_debug hex val (library)

* overlay command needs to accept multiple file arguments

* Bounding Boxes

  * make the bb command default to calculating a tighter-fitting
    bounding box using plot points and knowledge of the subtraction
    objects (e.g., perform inside/outside test against arb8s).

  * implement a faster raytraced AABB function that calls ft_plot(),
    shoots a ray through each point, and computes the resulting box.

  * g-shell-rect appears to be the only command that will give a
    raytraced AABB.  we need to refactor that feature into either the
    gqa -Ab (which merely reports the prep box) or the analyze command
    (or both).

  * add option(s) to 'bb' for reporting different types of boxes:

    1) unevaluated, without subtractions (current fast result)
    2) unevaluated, with subtractions
    3) evaluated, coarse (use plot points)
    4) evaluated, precise (use ray tracing)
    5) evaluated, exact (requires Implicit+CSG->BREP+CSG->BREP-CSG)

    option dimensionality #1: sphere v aabb v obb v 8dop v cxhull
                          #2: unevaluated v evaluated booleans
                          #3: without v with subtractions
                          #4: coarse v precise v exact

  * investigate why the new bbox() routines for ARS and BoT result in
    bounding boxes that are way too big.

  * implement prep optimization to the default fast bbox approximation
    specifically for arb8/rpp since we know the exact extent of their
    bounds and can chop away at a box with a box.

  * make gqa -Ab use sample points for reporting an evaluated AABB.

  * make bb report an evaluated AABB by default.

  * provide option for displaying object bounding boxes while
    rotating.  visualization feature to help with rotation operations,
    showing global object alignment with respect to its own coordinate
    space.

  * Extract bounding box code from both autoview.c and get_autoview.c
    into a general bounding rpp function in librt and use accordingly
    (particularly in libged).  Should combine autoview.c with
    get_autoview.c (perhaps as a flag) and utilize the general
    function in lots of places (e.g., the ged_arb() function).

* add unit tests for primitive callback routines (e.g., bbox).

* put bu_num_print() to use

* use bu_gettime() in rt -l8 heatgraph visualization mode

* fully implement analyze for all geometry objects

* move analyze logic into libanalyze (with respective primitive logic
  into src/librt/primitives/*).

* extend analyze output formatting to user-specified formats ala nirt

* calculate products of inertia in 'analyze' and/or gqa output

* calculate radii of gyration in 'analyze' and/or gqa output

* implement make, ted, edsol, mirror, and analyze for revolve
  primitive.  implement tess() too.

* go_open inmem to db command

* optimize mged interactive loop command processing.  creating 10k
  objects: 40 sec, via inmem: 2 sec

* implement a bu_exec wrapper and investigate something like capnproto
  to build up a process-isolated command execution system for libged.
  Possibly useful resources:

  - https://github.com/s-u/multicore/blob/master/src/forknt.c
  - https://github.com/diacritic/BoxFort
  - https://yuhui-lin.github.io/blog/2017/08/01/serialization

* Implement a bu alarm(2)-style interface so we can abort library
  routines gracefully from application code. A quick initial attempt
  at this didn't succeed very well (r71644 has what was tried).

  [HARD] Safely interrupting arbitrary in-flight library code means
  unwinding across allocations and held locks, cross-platform -- and it
  was already attempted once without success (r71644).  One of the
  hardest "small-sounding" items.
  [FAN-OUT: poor -- a single mechanism needing one careful design, not
  parallel coverage.]

* cppclean audit

* add a multiview rt script to regression testing (e.g., see rtwalk
  output)

* finish implementing pnts:
  - ray trace pnts
  - make color and vectors on pnts work

* handling of geometry with names like "--_25" fails in archer

* drawing with origin, axes, and overall dimensions for rt/rtedge/etc.

* Fedora doesn't have the old fonts mged assumes: dm-X: Can't open
  font '9x15' or
  '-adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1'

* lay out filesystem and URI models for database storage and access -
  these design decisions are fundamental and have broad implications
  for many other design decisions.  Issues to consider include where
  and how versioning, how to access attribute data from URIs, what the
  filesystem analogies are (combs -> directories, objects -> hard
  links, etc...), where they break down (comb boolean expressions
  don't map cleanly to the notion of directory contents, for example)
  and how to handle the various cases, how to present a "db_glob" API
  etc.  Need a proper document laying all of this out.

  Potentially relevant/useful links:
  URI specification:  https://tools.ietf.org/html/rfc3986
  Minimal URI parser:  https://github.com/cloderic/curi
  Larger URI parser: https://github.com/bnoordhuis/uriparser2
  Fast parser, has deps: https://github.com/toffaletti/libguri
  OpenBSD glob with function callbacks (rework/simplify
     to be *only* a callback API to make this properly generic,
     then have OS or .g specific functions...):
  https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/include/glob.h
  https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/glob.c

  [HARD] Foundational design whose decisions cascade everywhere; the
  combs<->directories analogy breaks on boolean trees with no clean
  answer.  Relates to the geometry-URL/VFS, symbolic-links, and
  filesystem-backed-collections items.
  [FAN-OUT: yes -- parallel survey of URI/VFS prior art plus a
  use-case/edge-case catalog before committing to a spec.]

* replace guts of bu_ptbl to see if we can improve performance -
  implications for removal if an appropriate substitute is found,
  needs to be deprecated if we remove all API but we can update guts.
  Try moodycamel https://github.com/cameron314/concurrentqueue

* check state of adaptagrams work - turn on? if not, delete?

* brlman - need remote text display in MGED, maybe run non-graphical brlman
  in MGED console mode?  A last resort fallback could be console text output
  via mandoc...

* add ability to capture any command's output to a file, ideally with
  options for specifying stdout and/or stderr.  of priority are the
  attr and rtcheck/gqa commands.  this should probably be handled by a
  libged command wrapper so it's consistent and available to any
  command.

* mater command does not validate its arguments - fix that.  Also
  properly document using "." to skip specifying something - not in
  the man page currently.

* bullet integration - need to expose restitution as an
  object parameter so we can configure behavior:
  http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?p=&f=&t=3248

* afl on libged/mged/rt/...

* moodycamel as libbu queue/list/ptbl implementation

* define geometry URL and VFS behavior

* change _mged_ command prefix to a simple '.' prefix to hide/protect
  the built-in commands.

* sync tgc/rec shot() behavior, sort results for proper normal.
  inspect t62 grazing with r653,r735 (tgc on an arb8) looking at ae0,0
  and z=1524 (was hit/overlap, now misses).

  [HARD] Numerically delicate primitive-intersection edge cases (t62
  grazing, ae 0,0 hit/overlap -> miss).  Couples with "fix ARB8
  promotion to BoT" (prep/shot soltab mismatch) and the global grazing
  policy in the OVERLAP TOOLS section.
  [FAN-OUT: partial -- a fan-out can generate the ray/primitive-pair
  test matrix; the fix itself is serial and tolerance-sensitive.]

* havoc.g s.nos5g reliably exhibits the grazing edge bug where only
  one hit point is being returned.  to reproduce: e s.nos5g ; ae 35 25
  ; units mm ; center 26912.4 7089.08 7168.96 ; nirt

* obsd stack crashers

* closing the graphics window brings down X11 on Mac due to a bad
  context.  fix or revert recent close window behavior.

* V&V bwcrop, pixembed are behaving correctly, as documented

* implement unit tests for bu dirent / stat API

* convert src/util/terrain.c to src/shapes/terrain.c writing out the
  datafile to a binunif along with a referencing dsp.  perhaps add
  command line option to skip .g to retain prior datafile capability.
  need to review command line options to simplify complexity and
  control randomization better.

* get_eyemodel returns an eye_pt entry, but feeding the results to
  archer's eye_pt command results in get_eyemodel returning a
  different eye_pt, even when the units are all in mm.  is this
  expected?  intuitively, I would expected feeding the results of
  get_eyemodel to eye_pt to result in no change, modulo unit
  conversions.

* make rt -b accept a pixel index in addition to x,y pixel coordinates

* teach pixdiff and other tools that can/should support the capability
  to read/write (as appropriate) pixel index values or x,y coordinates
  and reproduce the ray fired to create that pixel. currently does -l
  index but not xy coordinates.

* make mged work without a batch script

* Need to rethink libbu hash API - ideally should be much simpler and
  expose much less to the user.

* The current libbu mime API needs to be retired in favor of something
  more powerful.  It was a mistake to use enums generated from the
  mime types - they are static, cannot be enriched at runtime (say, by
  icv plugins) and the separation of the context from the type itself
  (image/png -> BU_MIME_IMAGE and BU_MIME_IMAGE_PNG for example) is
  both cumbersome and unnecessary.  Instead, grab a subset of the
  capabilities of libmagic (https://github.com/file/file) and define a
  new libbu mime/data-typing subsystem that is runtime populated by a
  default set of pseudo-libmagic style file definitions (may want to
  adjust their format slightly, to require a mime type for each entry,
  and we need an way to define entries where we don't (yet) know how
  to inspect the file contents to identify them...)

  This approach will let us define the types that are of interest to
  BRL-CAD, while also letting plugins "educate" the system to support
  processing of formats the base system (and the "standard" mime type
  lists) know nothing about.

* investigate merging functionality from the sig tools into libicv
  and removing the tools themselves.  Also, need some documentation
  for the sig functionality (currently none??)

* start making use of the CMakePushCheckState macros - we are doing
  this manually in several places

* expand libbu parallelism with thread-level control, i.e., the
  ability to start/stop/wait on individual threads in addition to the
  existing bu_parallel() call.  bu_parallel() gets updated to call the
  new thread-level control under the hood, but allows for more
  expressive threading structures (e.g., a function similar to
  bu_parallel() that is non-blocking).

  One consideration would be to implement something similar to Intel's
  Cilk API:

  + bu_spawn() specifies that a function call to execute
  asynchronously, without requiring the caller to wait for it to
  return.  This allows for parallelism but does not mandate it (so
  code will function as expected if it does block).

  + bu_sync() specifies that all spawned calls must complete before
  execution continues.  This allows for synchronization of data at
  different phases of a computation.

  + bu_for() specifies iterations of a loop body to be executed in
  parallel.  This would be a way to easily parallelize existing code
  without needing to create wrapper functions for bu_parallel().

* convert usages of Tcl_InitHashTable() and friends to libbu
  containers (see src/conv/enf-g.c for example usage)

* importer for LS-DYNA .k keyword files.  they support a variety of
  geometry constructs.  their spec is freely available online.  no
  existing libs are known.

* implement gdiff support for reporting the amount of spatial
  difference between two objects.  primarily for calculating amount of
  error introduced via bot, nmg, and brep nurbs format
  conversion. also useful for knowing relative difference between two
  versions (e.g., which is bigger).

* air regions (aircode > 0) are removed/skipped during prep, but there
  is no message to the user that this has occurred.  this can result
  in unexpected behavior (bad usability) if/when air regions are the
  only geometry being displayed (or are a substantial portion of the
  current display.  prep needs to return a catalog so summary
  reporting can be facilitated (of all objects, successful or not).

* evaluate replacing libfft with the KISS FFT library
  (http://kissfft.sourceforge.net, BSD) or the OpenCL-based clFFT
  (https://github.com/clMathLibraries/clFFT, Apache2).  we need to
  test correctness, precision, and performance via dfft.

  May also be worth looking at https://github.com/anthonix/ffts (has a
  CMakeified version at https://github.com/henrygouk/ffts)

  Priit Laes converted our tools to FFTW (circa 2010, see
  brlcad-devel), but FFTW is not license-compatible.  there is an sf
  patch containing this conversion, untested.

* import CTRI material information in fast4-g as per-face data.

* Integrate ADRT into Archer as a visualization mode.

* high-performance VOL for medical data visualization.  consider
  leveraging OpenVDB, PCL, Paraview/VTK, etc.

* establish the Basic Application Runtime (BAR), only consisting of
  libbu and libbn, as a stand-alone self-contained project.  provide
  an API that supports most C/C++ application development and
  documents our facilities that help simplify code portability,
  performance, and maintainability.  the scope is basic application
  utility and numerics only.  this scope is particularly tailored
  towards 3D and scientific application development.

  the basic utility routines encapsulate platform-specific constructs
  portably.  the basic numeric routines provide general math
  facilities common to scientific application development with a
  particular emphasis on being platform agnostic, high performance,
  and validated.

  the Apache Portable Runtime (APR) and GIMP Toolkit (GTK) are similar
  alternatives (particularly to BAR's basic utility routines) but have
  different emphases, scope, and development philosophies.

  BAR API design aims to be minimally intrusive on application
  developers, not requiring them to be aware of or adapt types or
  functions until it provides some clear advantage (e.g., portability,
  performance, and/or maintainability).

* rename the "joint2" articulation command (possibly also rename the
  "joint" command) worked on when joint objects were implemented.
  joint2 interfaces with the old text-file based articulation
  interface, but conceivably should get updated when joint objects can
  describe everything in the old text files.

* create a joint articulation (manually is good, automatic is better)
  for the tin woodsman so he can move his arms, legs, neck, and head.

* create a joint articulation (manually is good, automatic is probably
  impossible) for ktank so the turret can spin and the gun barrel may
  be raised up/down within a given range.

* need ability to report the smallest feature in a given hierarchy
  (smallest edge?) and/or largest error in a given boundary model
  (largest edge gap or distance between two points that should be
  coincident).

* geometry compiler.  provides different levels of "optimization"
  (ways of reducing the geometry complexity with or without
  introducing 3D changes.  provides different stages of compilation
  (e.g., similar to preprocessing, compilation, AST reduction,
  optimization, encoding transformation, etc.).  name ideas: bcg, cg

  [HARD] Two new subsystems (with the geometry debugger below).  The
  compiler needs real CSG optimization (tree contraction, null-object
  detection -- hard in itself); the debugger demands a dependency-free
  re-implementation of .g parsing to inspect corrupt files.
  [FAN-OUT: yes -- catalog candidate CSG optimizations and the on-disk
  .g layout in parallel; the cores are then implemented serially.]

* geometry debugger.  low-level geometry database tool with minimal/no
  run-time dependencies on our own libraries.  the idea is a tool that
  can inspect/repair a potentially corrupted/invalid .g file or help
  debug library robustness issues.  using headers for identifiers and
  codes in the implementation is okay (as are library functions, but
  just don't rely on any).  name ideas: gdbg, dbadmin, dbtool, dbmaint

* convert all calls to BU_SETJUMP/BU_UNSETJUMP into familiar try/catch
  logic layout using if/else.

* re-do the sh/enumerate.sh script for CMake

* get bu_extern out of bu/parse.h into its own header file.

* geometry symbolic links (hard and soft links)

* investigate INFINITY spatial partitioning issue.

* kill material_head static global in src/librt/mater.c

* Teach CMake to respect and use user-defined CMAKE_C_FLAGS and other
  options supplied at the command line and in environment variables.
  See whether we can pass a variable into CMAKE_C_FLAGS that will
  allow specification of build flags at make time.  Relevant link:
  https://cmake.org/Bug/view.php?id=12928

* investigate the possibility of allowing functions to define their
  own custom filters for some version of the db_search API.  If we can
  figure out a programmatic approach of some kind, why not allow code
  to define their own "filters" that don't have a corresponding
  mapping to the MGED command string?  As long as the functions
  satisfy the API templates used by the db_plan structures, wouldn't
  custom functions work?

* implement rt_volume() API for computing geometry volume (gqa style
  for complex, direct for primitives)

* decouple libwdb from librt, particularly the headers and relevant
  structures that cross over to both such as the rtgeom.h types.

  [HARD] Untangling circular core dependencies without breaking ABI for
  downstream; pairs with "refactor ... nmg processing ... into its own
  library" below.  Measured blast radius: 671 files include raytrace.h;
  231 reference nmg_*.
  [FAN-OUT: yes -- parallel dependency mapping (per header/symbol)
  first; the moves themselves must be serialized.]

* Translate logic from clipper polygon clipping library
  (http://www.angusj.com/delphi/clipper.php) into libbg and use it as
  a pre-processing step for detria's algorithm along the lines of what
  bitfighter did: https://github.com/raptor/clip2tri Some useful notes
  here: http://stackoverflow.com/a/16115775

* Implement Shamos-Hoey test for checking whether a polygon is simple
  in libbg: http://geomalgorithms.com/a09-_intersect-3.html

* figure out what in f_matpick (or possibly some other related
  function) is causing ipathpos to get incremented to a number larger
  than the number of objects in the full path it's supposed to be
  referencing.

* refactor rt_mirror (src/librt/primitives/mirror.c) into the functab

* refactor rt_functab accessors to go through an api call or calls so
  that the array is not accessed directly.  either an rt_eval() style
  interface with data-driven keys to tell it with function(s) to call,
  or simply have an rt_*() for each function (e.g., rt_mirror(),
  rt_shot(), rt_describe(), etc.).

* review proc-db for promotion to src/shapes

* fix nurbs_ssi and nurbs_tester unit tests

* get rid of the -P#processors user option (except rt* tools) common
  on utilities.  call bu_avail_cpus() and provide an environment
  variable override used by the library.

* In tree.c line 531, the initialization of the local storage of the
  full path in stp->st_path is conditionalized on the specifics of the
  tree structure.  Why?  Could we get away with always initializing
  (or never initializing, if it is not used) the st_path?  Current
  behavior is odd - if a region has a solid unioned under it the
  st_path is not set, but if it has a comb unioned in the path is set
  - is this an optimization, and if so is it necessary?

* investigate integrating Pixar's OpenSubdiv for subdivision surfaces:
  http://graphics.pixar.com/opensubdiv/

* implement a null spatial partitioning method so we can determine
  what other intersection hits are being masked (and what impact a
  given method has on performance)

* [hn]to[hn]* conversion functions were usurped by windows 8 so we
  need to either wrap them or undeprecate our xdr API or see if a
  simple config header fix might work (ideal)

* The sph wireframe drawing routine doesn't seem to like drawing very
  small spheres far from the origin:

  in test_2.s sph 1, 2, 1 0.0007  (draws a sphere wireframe correctly)
  in test_1.s sph 10000 -15000 3000 0.0007 (incorrect wireframe)

* rework the database object hash to push the iteration up into librt
  as API instead of expecting callers to use RT_DBNHASH and
  RT_DBHASH() manually.  consider using bu_hash or other container.

* temp colors and temp matrices during ray tracing, rt, rtwizard.
  need a command-line and mged method to override parameters.

* fix 64b detection across platforms. Fix rhel 32/64 confusion

* merge conv-vg2g into dbupgrade

* add option to rtedge to also show back-facing hidden edges

* convert teapot to use nurbs surfaces instead of bspline

* create a FASTGEN sample geometry with all entities defined and a
  corresponding regression test to make sure outputs don't change.

* investigate bu_vls_encode/decode failures on g-dot.c (see that
  file for FIXME note); add tests for both functions (note only
  g-dot.c wants to use the functions at the moment)

* eliminate dbi_filepath (perhaps replace with dbi_filedir) as we
  shouldn't need to search.  we were told where the database was.

* make libdm framebuffer parallel-safe.  use bu memory management.
  remove semaphore locks in src/rt/main.c and elsewhere.

* eliminate the need for bu_semaphore_init().  allocate up to the
  index requested on demand (so we can retain O(1) lookups) and
  reserve the first N semaphores for BRL-CAD library use.  change
  index to a uint8_t or uint16_t type.

* make bv/plot3.h functions parallel-safe so callers do not have to
  manually wrap with bu_semaphore_acquire().

* rendering of the 'part' primitive is wrong for cases where H is less
  than r1 (i.e., smaller cap is partially or fully within the larger
  cap's radius).  It ends up rendering the larger sphere.

* update mged to not call wdb_init_obj and wdb_create_cmd, trace down
  other vestiges of wdb_obj for removal

* add support to rt tools and gtools for specifying az/el in radians
  or degrees, propagate throughout mged commands that take angles too.
  probably best implemented as a general libbn string to val function.
  perhaps an explicit 'rad' suffix and an implicit 'deg' suffix, e.g.
  rt -a 0.3rad -e 0.5rad and aet 0.3rad 45deg 0

* change fbserv usage to require a flag for its non-daemon mode, make
  the device type optional for both daemon and non-daemon mode

* work on vdeck/comgeom-g converters needed:
  - primitives recognized by comgeom-g but not vdeck:
      ehy, epa, eto, rhc, rpc
  - primitives recognized by comgeom-g (but not vdeck) but
    with possible equivalent versions in BRL-CAD:
      haf (half), rvw (right vertical wedge), raw (arb8), wed (DoE name
      for 'raw'), wir (pipe), arw (arbitrary wedge [ERIM?])
  - generate new comgeom-g tests with tgms from old GIFT docs

* test tgf-g conversion with "ring-mode" geometry

* fix metaball/adjust.. wipes out all metaball values with:
  adjust metaball 1 1 1
  just gives usage with:
  adjust metaball 1 1

* test for -msse3 requirement for __SSE.*__ definition

* improve sse run-time detection so illegal instruction crashes are
  avoided.  presently, adding -msse* to compilation will result in a
  crash if that binary is run on non-sse hardware (e.g., Pentium M)

* add support for a zoom/viewsize and twist options to rt so you can
  adjust the image without having to feed a view script.

* struct rt_bot_internal should be using "size_t *" instead of "int *"
  for the faces and face_normals members

  [HARD] Looks mechanical but touches BoT serialization, libtie, and
  every converter, with subtle signedness/32-bit landmines on huge
  meshes.  ~72 files reference the faces/face_normals members.
  [FAN-OUT: yes -- per-file/per-converter sweep with a verification
  pass.]

* pixdiff reports bytes, but reports incorrect (off-by-one) bytes for
  .bw input files.  cause is due to tool assuming input is rgb
  triplets (even though output is bytes, wtf?).  should probably
  report pixels and/or have a -b option for handling byte/bw input.

* investigate why epa primitive is so sensitive to coarse absolute
  value changes (run csgbrep, tol abs=1, facetize and get 321k poly)

* implement http network transfer tool for crash reports and benchmark
  analyses (via libfetch)

* reimplement benchmark suite in C/C++

* include defaults about the compiler in the benchmark suite output
  including the compiler name and version at a minimum, plus hopefully
  describing the CFLAGS that were used too.  ideally would include all
  of the versioning details (such as described from "gcc -v" if we
  compiled with gcc) too.

* make bu_dirname not allocation memory.  have caller pass buffer in
  as a parameter with size ala snprintf/memcpy.

* make mged not have a garbled display manager window if the
  framebuffer is enabled and the window is resized.  initialize and
  refresh the new memory and zap the framebuffer.

* make the right-hand path to oed optional

* vls name wrapping (reversible argv-to-vls, vls-to-argv).  look at
  src/libged/glob.c code, very similar.

* update g-xxx_facets to use libgcv

* render annotated images to the OpenDocument format.  this is
  particularly useful for rtedge-style renderings with object
  annotations where we can leverage layout components and scalable
  vector graphics.

* investigate OpenEXR (BSD licensed HDE image format)

* usage statistics.  similar to the eclipse Usage Data Collector, keep
  track of which BRL-CAD command-line commands and MGED/libged
  commands are run.  Give the user the option of uploading those
  statistics (now, always, later, off).  Provide terms of use
  explaining the ways that their data will be used and shared.
  aggregate, this can help us focus development resources towards
  improving workflows, documentation, robustness, and new development
  areas.

* automatic anti-aliasing as a second render pass on the edges
  encountered (possibly using bilinear filtering scheme, improve upon
  rtedge's current simple filter)

* make loadview still load the view if the database doesn't match the
  currently open database, only load geometry as an option (and then
  just ignore the db).

* add a force option to the tracers to support overwriting the current
  output file (so long as we're going to make it read-only by
  default).

* clean up new rt -l8 heat graph lighting model so that it works in
  parallel and with no "splotches"

* separation of stderr from stdout within libbu, particularly for
  MGED, so that there is a clean separation of result output from
  diagnostic output.  this is a fairly separate idea from having log
  levels (ala syslog) but is somewhat related to the concept of having
  definable output streams.  idea in mind is to have a bu facility to
  obtain a bu_log()-style callback function returned from a logger
  registration function.

* investigate impact of using lookup tables for root solving.
  implement lookup tables for a range of linear, quadratic, cubic, and
  quartic polynomial coefficients.  compare performance to root
  solving without lookups.  evaluate memory use.  non-imaginary roots
  are relatively sparse, may need to consider linked lists, hash
  tables, or some hybrid storage arrangement.  Idea inspired by:
  http://math.ucr.edu/home/baez/roots/

* make fbclear and raytrace control panel obey a -F advanced option,
  i.e., better remote framebuffer support.

* MINOR: add tolerance parameters to the bn_*() functions that have
  near-zero tests.

* add an option to bot_dump for outputting surface normals.  Make sure
  all supported dump formats (obj, dxf, etc.) optionally write out
  normals.  Consider adding an option to smoothly interpolate normals
  (per face or vertex).

* refactor and manage libbn tolerance uses by providing an interface
  default (e.g., an init macro) and making everyone use that where it
  is hardcoded to 0.0005 presently (and a few places where it's
  inconsistently/incorrectly 0.005).

* add a default phong 'metal' shader.  annoying to keep making plastic
  more reflective or mirror less reflective when it's such a common
  material appearance to want.

* consider adding an option to reid/remat and edcodes (and others?) to
  ignore negative regions (regions subtracted from regions or
  intersected with them) since, while bad practice, are valid
  geometrically.

* make sure there are no getenv() non-NULL assumptions within the
  code.  might want to see if there's a pattern of variables being
  checked such that a libbu interface would be warranted (e.g.,
  instead of checking HOME, having a bu_find_directory(BU_USER_HOME)
  routine or similar facility) for finding common resource locations.

* make db_open modes behave the same as the fopen() modes (i.e.,
  create the .g if one doesn't exist when write mode)

* inside support for ARS

* add support to 'rtxray' for outputting inverted pixel values so that
  we have pixel values that are directly related to material thickness

* mged inconsistently ignores signals.  initially allowing mged to be
  backgrounded, but then later ignores them.  needs to consistently
  ignore or not ignore them, ideally the latter.

* integrate library tester into regression suite that validates
  exported library symbols published in headers.  make sure they at
  least exist and maybe even try to ensure they will run with null
  arguments without crashing.  make sure headers compile as c++ (with
  proper extern "C" wrapping).

* make _plot() callbacks fill in plot objects instead of returning
  line segments.

* implement a jitter-style option to rt that makes it average the ray
  results to take a weighted light contribution for a given
  resolution.  saves more memory over rendering at 2x/4x/8x/whatever
  with or without jitter and then scaling down.  present jitter option
  doesn't average.

* refactor mged/bwish/g_diff initialization to all use the same routine

* refactor mged's signal handling to make it possible to safely
  interrupt long-running commands

* make Mac OS X universal binaries actually work.

* fix/change naming convention for presented/exposed area

* re-enable RISE client in ADRT

* test homovulgaris' root solver patch that puts coefficients in the
  right order

* review librt polynomial root solver (cubic and quadratic case)

* give bot-bldxf the axe (reconcile and merge with bot_dump)

* come up with a new tool that automatically generates "inside"
  regions for a given model as a way to automatically model air.
  particularly useful for bot models where the inside air compartment
  is predominantly (but not entirely) a complex bot structure in
  itself.  idea is to use some sort of marching cubes/tets to find
  those volumes, perhaps use a libified gqa.

* extend metaball control info beyond simple points (e.g., line
  segments)

* address the TODO items in src/mged/clone.c

* fix rt parallel crash
  (true ; while [ $? -eq 0 ] ; do rt -o /dev/null moss.g all.g ; done)

* fix parallel crash report generation (multiple BU_MAPPED_FILE's
  getting acquired)

* make only closing BOTH the command window and graphics window shut
  down mged (i.e., fix unintentional behavior), not either alone.

* add keybinding to restore a command window if only the graphics
  window remains.

* remove hit_normal and hit_point from struct hit.  add RT_HIT_POINT
  macro.  refactor all callers as needed.

  [HARD] Surgery on the hottest struct in the ray-tracer: ABI break,
  perf-critical, every primitive's shot() must be re-audited.  Measured
  blast radius: 107 files reference hit_normal/hit_point.
  [FAN-OUT: yes -- strong mechanical sweep; one agent per
  file/primitive to migrate to RT_HIT_POINT, then verify.]

* make bombardier actually send the report somewhere

* hook bombardier in for crash reporting

* add high dynamic range image support to the framebuffers

* add alpha channel support to the framebuffers

* remote framebuffer timeout support (perhaps as ::key=val;key=val)

* develop a tool that applies a text overlay to a given rendered image
  (e.g., as an rt option) for things like adding an image title, the
  az/el, and objects displayed.

* bezier extrusions need to be optimized, really should not be
  performing dynamic memory allocation in the root solver

* Implement an optical shader for the new "pixelated" military
  camouflage style

* enhance dxf-g to create more than just one combination per layer,
  creating multiple objects for the individual objects in the dxf file
  (instead of one conglomerate BoT)

* review and merge in the rest of the GSI modifications

* inside/outside point and voxel testing capability in librt

* automatic geometry voxelizer (perhaps using arbs or vol primitive)

* implement support for raw voxel data (g-voxel) where each position
  in the binary array (unsigned 8-bit integer) corresponds to a voxel
  coordinate given by X + Y x Nx + Z x Nx * Ny where Nx = grid width
  and Ny = grid height.  this consequently happens to match our bw
  format if you concatenated N bw image slices into one file.  for a
  2x2 example, position=>coordinate: 0=>0,0,0; 1=>1,0,0; 2=>0,1,0;
  3=>1,1,0; 4=>0,0,1; 5=>1,0,1; 6=>0,1,1; 7=>1,1,1. See
  http://support.echoview.com/WebHelp/Reference/File_formats/
  Export_file_formats/Volume_data_set_file_formats.htm

* add support for querying geometry properties to library including
  computing surface area and weight/mass.

* add verification and validation tests confirming behavior of the
  ray-tracer and computations of area, mass, volume, etc.

* testing suite for all binaries:

     for cmd2 in $(for cmd in `find . -name Makefile.am | xargs cat |\
       perl -pi -e 's/\\\\\n//g'| grep -E "PROGRAMS ?=" | \
       sed 's/.*=//g'` ; do echo $cmd ; done | sort | uniq ) ; \
       do echo command: $cmd2 ; done

* Mac OS X SGI dial knobs support
  - Note that we might do better here to focus on the 3Dconnexion
    space navigator mouse, which is a lot more commonly available
    nowadays...  spacenav.sourceforge.net is something to bear in
    mind in this context.

* ability to "unpush" objects, translating them to a new position and
  applying the correct matrix (using either bounding box or center of
  mass, for example).  would be useful to optionally allow the
  creation of a parent combination that contains the unpushed matrix
  so you could return primitives to local coordinates.  See sf feature
  request 2826720 from cericole.

* optimize CSG structures automatically: automatic simplification,
  tree contraction, null object detection.

* have libbu report memory allocation statistics so the exact amount
  of memory requirements for a geometry database can be computed on
  the fly via a pre-prep phase.

* libfb + font rendering (perhaps through libbn's plot interface) for
  a posix terminal.

* getexecname, "/proc/self/cmdline", program_invocation_short_name.
  separate out into new file.

* geometry viewing commands/visualizations of exploded levels

* librt-based path tracer

  [HARD] A global-illumination engine: importance sampling,
  convergence/denoise, integration with the existing shader stack and
  framebuffers.  Couples with "Integrate ADRT into Archer" and the
  automatic-anti-aliasing item.  A whole rendering subsystem.
  [FAN-OUT: partial -- parallel component research (samplers, denoise,
  ADRT bridge); the integrator core is serial.]

* system identifier application with sysctl-style information
  database, with some back-end functionality placed into libbu.

* add callback data parameters to libpkg hook functions

* rtedge-style tracer that outputs tool paths (splines/segments, etc.)
  for CNC/CAM style toolpath cutting descriptions (g-code files).

* rtedge shoots twice as many rays as it needs to (shoots the 'below'
  ray for each primary, only reusing current scanline cells).

* make the DSP primitive use less memory when data is coming from
  a binunif. allocating 160 times binunif size is a bit extravagant
  (which comes from sizeof(struct dsp_bb)).

* add dynamic geometry support. i.e. the ability to modify the parsed
  in-memory geometry tree on the fly via api calls (e.g. to add holes)

* investigate why g-iges followed by iges-g on a single box results in
  permuted vertex lists

* add support for filesystem-based geometry collections

* libbu's bu_opt is our option handling API that supports more
  features than getopt - remaining features we need:

  - need a way to consolidate documentation for options into one place
    (DRY) that supports all of our various documentation styles.
    Discussed with Sean in the past - initial thoughts:

    + support printing out the options and documentation in formatted
      structures that allow our build system to build the command and
      have the command itself supply a generated block of text or
      markup that could be incorporated into the final document.  For
      example, the DocBook man page for a command would be set up to
      expect the <command>_options.xml file generated by <command>
      --print-options DocBook (or some other mechanism, that's just an
      idea) and the CMake build could first build and then run the
      command at compilation time to provide the most current option
      listing and short descriptions for the other docs.

* investigate the libngpcore and libngput libraries from the ngPlant
  project as a possible means of procedurally generating plant models
  in BRL-CAD (libraries are BSD licensed:
  https://github.com/stager13/ngplant)


OVERLAP TOOLS
-------------

* Need to mark or otherwise disambiguate grazing hit segments so we
  can consistently retain or remove hits without introducing overlaps.
  Consider the case of a tgc stacked on top of an arb8, perfectly
  tangent, and shoot a ray at that point:

                                   -----   z=2.0
                                   |tgc|
  shoot a ray through here --->   -------- z=1.0   <--- or here
                                  | arb8 |
                                  -------- z=0.0

  Here are the primary concerns:

  A) solidity: a ray should never pass through the two without one or
  both evaluating to a hit,

  B) usability: a convention that precludes forcing the user to
  "nudge" them apart by some arbitrary epsilon is desired (it's
  intuitive and common for users to model two objects with "perfect
  tangency"),

  C) deterministic: firing a ray should give the same result every
  time that same ray is fired, and,

  D) bidirectional: a ray fired in one direction should evaluate to
  the same result if fired from the opposite direction along the same
  path (view independence).

  If we hit both, an overlap will ensue unless these objects are
  unioned.  This is undesirable.  If we miss both, slipping through
  the hairline "crack", it can be devastating for analysis and result
  in raytrace speckling.

  In order to only hit one, a consistent grazing policy must be
  applied such that grazing points on one "side" of an object are
  always kept and grazing hits on the other "side" are always thrown
  away.  The proposed method, similar to handling special case
  grazings with a Breseham line painter algorithm, is to consistently
  consider grazes with a procedure:

  1) Calculate the ray intersection, detect whether the hit is grazing
  (defined as a hit being barely in/on the surface either through a
  point, edge or even down a surface).

  2) Calculate a hit normal.  It may be desirable to average both the
  in/out hit points to get more of a "practical" surface normal.

  3) Calculate the ray of reflection.  Use the surface normal and ray
  of intersection to calculate our reflection direction.

  4) Determine which plane of a globally bounding rpp the reflected
  ray would intersect with.

  5) If the reflected ray hits the front, right, or bottom face, the
  grazing is kept, but if it reflects onto the back, left, or top
  face, the grazing is ignored.  In ray-view projected 2D, this
  corresponds with keeping the grazing if the reflection is pointing
  up or to the left and discarding if pointing down or to the right.

                                   discard top/left/rear
                rear              keep bottom/right/front
            .____________.
            |\           |\ t              discard
            | \          | \ o           ._________.
          l |  \         |  \ p          |/////////|
          e |   o____________o          d|//view// |
          f |   |        |   |          i|//of///  |
          t |   |        |   | r        s|//ray/   |k
        b   .___|________.   | i        c|////+    |e
         o  \   |         \  | g        a|////     |e
          t  \  |          \ | h        r|///      |p
           t  \ |           \| t        d|//       |
            o  \o____________o           ./________.
             m     front                     keep

  This should result in consistent grazing behavior that addresses the
  above case: we consistently hit the tgc but not the arb8 and there
  are no overlaps requiring modeler intervention.  The main problem
  with this approach, however, is calculating an appropriate surface
  normal for edge and face grazings can be difficult for some objects.

  In the case above, we do not get a hit on the tgc's bottom ellipse,
  for example, instead getting two hits near the edge of the side.
  Similarly, we hit the left and right arb8 faces, not the top face
  even though that is what we are conceptually grazing through.

  One possibility to address that difficulty is to simply report all
  grazing hits, but mark them as grazing, and let rt_shootray() sort
  it out by sampling a 3x3 pattern that determines if we're grazing
  the "top/left" or "bottom/right" side of a surface.

  [HARD] Needs one grazing convention that is simultaneously solid,
  deterministic, view-independent (bidirectional) and overlap-free
  across every primitive; the text above concedes a valid edge/face
  graze normal is "difficult for some objects."  Governs global
  raytrace correctness; see also the s.nos5g grazing-edge bug and the
  tgc/rec shot() item.  A fully-correct solution may not exist.
  [FAN-OUT: yes -- one agent per primitive to characterize graze
  behavior, plus an adversarial bank of bidirectional ray test cases.]

* implement quasi-random unbiased iterative spherical ray sampling.
  requires devising an algorithm whereby we obtain a set of points on
  a sphere with rays randomly going through those points, so we sample
  the volume evenly.  we need to be able to add additional sets of
  points/rays (incrementally or step-wise) in order to evaluate
  convergence and estimate error.  this feature is useful for checking
  overlaps, surface area, volume, and moments of inertia.

* add an overlap depth reporting tolerance parameter to the
  ray-tracers (similar to -R).

* a_logoverlap doesn't work with rt_shootrays because it overwrites
  a_uptr

* sort gqa/rtcheck/check/lint/analyze/g_lint functionality into
  logical groupings (probably analyze - calculate properties and
  lint - find problems). Come up with a command design that
  lets us rationalize the features and reduce the command set.

* add support for custom and random views to gqa.  provide an option
  to evaluate every N degrees for all unique az/el pairings, e.g.,
  every 15 degrees.  should automatically discard duplicate views.

  command line usage:
  -a begin[:end[:count]][,...] -e begin[:end[:count]][,...]

  the begin, end, and count can be any real or integer number or can
  be a literal '#' to request a random integer number ranged [0,360]
  inclusive.  examples:

    Default 3 views (1 duplicate discarded): -a 0,90 -e 0,90
    One specific view: -a 35.12 -e 25.6
    360 orbital, every 30 degrees: -a 0,30,60,90,120,150
    360 orbital, every 30 degrees: -a 0:180:6
    10 random views: -a #:#:5 -e #:#:2
    Up to 129600 random views: -a #:#:# -e #:#:#
    Comprehensive "front" view, 1-degree increments: -a -90:90 -e -90:90
    Comprehensive orbital, 1/2-degree increments: -a 0:360:720

* implement an overlap reporting function (boolean and volume)

* implement adjacent object detection in gqa -- find objects that are
  within a specified tolerance of optionally specified object(s).

* have gqa calculate the volume of overlapping regions, not just
  shotline overlap distances.  that will allow output to be sorted by
  volumetrically significant regions and should eliminate a common
  source of user misunderstanding.  It should eliminate the perception
  that large overlaps are suddenly appearing when there are changes in
  grid alignment/density.

* fix gqa spewing of massive amounts of plot data with th -Av -v
  options:
  ../src/gtools/gqa -u m,m^3,kg -g 0.25m-0.5mm -p -Av -v gqa.g closed_box.r
  -rw-rw-r--  1 morrison users 41572569618 Apr 23 15:14 volume.pl

* make gqa overlap reporting suck less.  uselessly reports the same
  objects multiple times instead of keeping track of uniquely
  overlapping pairs of objects (rtcheck used to have this problem but
  not now).  also reports overlaps even when not requested (e.g. -Aa)

* gqa semaphore locking on results is very slow and gets worse as the
  number of cores and speed of cpu increases.  resource contention on
  semaphores slows everything down substantially.

* gqa needs to be more informative when it runs - needs a header
  letting you know what it's doing, and if possible a "progress
  report" for longer runs that provides some notion of how much of the
  total job is done.

* modify gqa to search for >1 region flag in a tree path.

* modify default behavior of the overlap GUI to do what overlaps_tool
  -F does or to supply some togglable means to enable that option in
  the GUI.

* extend overlap GUI to report null/empty regions and regions not hit

* need some means to control the runtime and/or density of the overlap
  GUI sampling, ideally without exposing grid size options so that it
  remains agnostic to future sampling methods.  a good solution would
  be better status reporting of the current density sampled and a
  means to interrupt the process cleanly (while retaining progress and
  ability to pick up from that point)


DATABASE MAINTENANCE/ADMINISTRATION
-----------------------------------

(Note: See src/util/admin-db.cpp for a starting admin tool which could
be expanded to do the following tasks.)

* implement some means (perhaps glint) to check a .g file for
  duplicate region IDs and material inconsistencies.  perhaps exposed
  as a new command, it should take an assembly/comb name as input,
  walk the tree, and report duplicates.  if no arg, it walks all
  top-level objects but processes them independently and only reports
  sub-paths once (so you don't get the same object repeatedly reported
  for all N top-level copies).  in the output, group together regions
  with same and different material properties together:

DUPLICATE ID NUMBERS
comp.r1 ID 1234
comp.r2 ID 1234

DUPLICATE ID NUMBERS WITH DIFFERENT MATERIAL PROPERTIES
comp.r3 ID 5678 material code 1 LOS 50
comp.r4 ID 5678 material code 5 LOS 75

* develop a low-level tool for investigating, reporting statistics on,
  and repairing geometry database files.  the tool should nominally
  perform big/little endian conversions, report number and types of
  objects, allow deletion/undeletion/hiding/unhiding, provide some
  general means to manipulate the packed and unpacked .g file data for
  performing low-level modifications

* evaluate performance of using an SQL/XML store for BRL-CAD geometry,
  particularly as it pertains to rt_dirbuild() run times on large
  models and db_lookup() times.

* multiple-representation geometry.  support storing different
  "versions" of a given combination node, as selectable subtrees where
  one selectable subtree is always marked active/selected.  the
  selectable subtrees could generally be entirely different
  configurations (e.g., different poses) or different geometry
  structure (e.g., a blast, signature, or lethality version of a given
  model).  These could be implemented as a modification to the union
  tree and exposed to the user as a parametric selection on a comb.
  Something perhaps like this:

  union tree {
    ...
    struct tree_representation {
      uint32_t magic;
      int tr_op;
      const char *tr_name;
      union tree *tr_subtree;
    } tr_r;
    ...
  };


LIBGED
------

* See src/libged/TODO for new command and subcommand ideas.

* libged needs to support "temporary" objects that are in-memory only
  and will disappear when the ged instance is destroyed, yet is
  otherwise considered real objects in a given database.  this
  supports temporary additions to the wireframe (e.g., plot data from
  nirt from cvt_vlblock_to_solids()) and in-progress selections.

* restore libged axis/grid commands code made in r44153 but with
  libged decoupled from libdm/libfb.

* the 'l' and 'analyze' commands now require an object be specified
  and won't use the currently highlighted solid.  undoubtedly related
  to libged refactoring.  this is related to sf request 2954409.  this
  needs to be handled in a generalized way so that most/all commands
  have a notion of operating on the currently 'selected' object(s).

* refactor the libtclcad go_*() functions and invocation wrappers
  (also in mged) into libged where appropriate. the 'png' command
  comes to mind.

* refactor wdb_obj and view_obj in libged. they should disappear but
  shouldn't have wdb_*() funcs in libged regardless.

* make ged command names aware of object arguments for automatic
  globbing and regular expression expansion:
	attr set [regex .*\.r] t 1
	attr set [glob *.r] t 1
	attr set *.r t 1

* review adding support for infix and postfix CSG operators for
  libged/mged.  be sure to revive or at least check out the previous
  effort in src/mged/comb_bool_parse.y that already has support that
  recognizes the classical infix notation.

* Explore possibility of expanding dm command to accept object names
  as a way of tweaking display manager specific properties (wireframe
  vs solid drawing, shading on normals, etc.) that are currently
  controlled only via the draw command.  Many of the undocumented (or
  poorly documented) draw options are very specific and there are many
  more possible similar options that aren't defined.  Initial thought
  is to allow passing "dm" subcommands to draw (maybe --dm key=val or
  some such) and using the dm command to offer display type aware
  hooks (for example, solid drawing isn't a valid option in text mode
  display, so options about how to shade normals don't make much
  sense.  On the other hand, a full scene graph could have many
  per-object display options the user (or application) would want to
  tweak on a per object basis, e.g. dm obj.r transparency 0.3. Hard
  wiring draw options isn't going to be flexible or user friendly;
  need something similar to the new dm ability to supply dm-backend
  specific options to the user.

* use the globbing work needed for proper rm support to enhance the
  ls command.  filesystem/URI work relates to this - in "flat" viewing
  ls */* is meaningless, but in the hierarchy view it should do the
  same glob resolution rm will need to do in that context.

* make the idents command not list subtracted objects by default,
  optionally list everything

* improve performance of these commands that seem to have exponential
  cost: bot_split, killtree, and
  make s sph; make a arb8; sed a; e a; tra 0 0 500; r hemi u s - a; tol norm 1 ; facetize hemi.bot hemi
  # compared to tol norm 2, # triangles is up ~20% but facetize is >200%

* BoT mesh editing command.  Subtasks:

  - enumerate functions desirable
  - catalog features of other mesh manipulation tools
  - investigate mesh editing libraries and/or relying on NMG editing
  - bind GUI editing to the BoT mesh editing command

* object error heuristic.  implement a function/command to report how
  big of an error a given geometry object has.  the intent is to help
  prioritize geometry modeling errors based on their spatial impact.
  this is particularly relevant for nurbs/brep and nmg geometry where
  there may be solidity gaps in the topology that need to be sealed or
  dangling faces/surfaces of different sizes.  this is meant to be a
  relative heuristic applicable across all geometry, not necessary an
  exact measure.  this may make more sense added as an output option
  to glint or as a warning category for a geometry debugger.

* implement a region anointment feature where the user can turn an
  assembly into a region and change all lower or higher regions into
  combinations.  basically consolidate or distribute region flags.
  this is partially covered by the 'comb' command but it tries hard to
  ensure geometry isn't left in a broken state.  needs to be a way to
  do the simple consolidate/distribute operation regardless of
  resulting state.

* the 'comb' command both updates and creates combinations.  this is a
  problem because it's not possible to infer an intended result from
  the command string alone.  it should either append to an existing
  combination and fail if it doesn't exist (with flag to create) OR it
  should create a combination and fail if there is an existing
  combination (with flag to append).

* Update the comb "region lift" capability to handle automatic
  duplication and substitution of the duplicate into the tree of combs
  who can't have their definitions changed without impacting other
  geometry in the .g file.

* change 'mirror' command offset to be prior to mirror instead of
  after, so that you can mirror intuitively over a specified point
  along a given axis.

* add option to 'mirror' command to delete the source object.  support
  specification of a plane as the view plane, 3 points, XY, YZ, XZ.

* replace sed and oed commands: functionality provided by new 'edit'
  command, but requires testing (unit tests) to make sure it's working
  correctly.

* make sure 'preview' works, particularly the 'tree' subcommand.

* add support for a custom unit conversion factor to the units command
  (e.g. 'units 9.3120223' or 'units metertons 9.3120223')

* implement some sort of archive/backup command in mged in order to
  save the currently open database out to a file.

* add a -color option to all mged commands that draw geometry (B, eid,
  and E come to mind)

* have mged record a timestamped command history by default

* implement 'analyze' command option to write output to a file

* implement mged object name globbing similar to tclsh's globbing
  (i.e. via a globbing command and quoting globs that use []).
  testing shows db_glob doesn't seem to behave correctly, at least not
  like glob.  hook globbing into all commands so glob_compat_mode
  statefulness can go away.  a db_glob expression that doesn't match
  anything should not return the expression.

SHADED DISPLAYS
---------------

* See doc/notes/TODO.shaded_displays


ARCHER
------

* See src/archer/TODO


ATTRIBUTES
----------

* See src/libbu/TODO.binary_attributes for more info about
  bson based binary attribute work.

* attr command change to only output non-standard attributes

* attr command change to have an optional object argument and to work
  with multiple objects.  make output format scriptable.

* implement an attribute versioning system.  can hang attribute
  version off of _GLOBAL (ideally) or per-object so application codes
  (including our own tools) know whether they're compatible or whether
  the attributes must be upgraded.

* implement an "attr upgrade" subcommand that allows for forwards AND
  backwards conversion of attributes.  the command will need two
  function pointers per version that describes how to upgrade and
  downgrade for that version transition.  this will allow new files to
  be downgraded for use on older versions and obviously lets new files
  be upgraded to the latest conventions.

* implement namespacing for attributes as a means to group attributes
  together.  examples: cad:color, cad:region_id, muves:component.
  similar to svn properties, the namespace is predominantly (perhaps
  entirely) a naming convention, but allows us to document and assert
  requirements/conventions over a given prefix (e.g., 'cad:'), and
  provides 3rd party applications with a sandbox to work with.

* expose the list of internally recognized attributes via the man page
  documentation and some internal method (e.g., an 'attr standards'
  subcommand).

* clean up default attributes to be consistent and upgrade old
  attributes to their new names.  includes likes of region, region_id,
  material_id, air, los, rgb, oshader, and inherit.  see
  doc/docbook/system/man5/en/attributes.xml for more detailed listing.

* implement an option to "attr upgrade" for reading upgrade/downgrade
  plugins/instructions from an external file for 3rd party use.

* prevent nirt from outputting a trailing space after values when
  there are no attributes to be displayed.  the problem is in the nirt
  format strings where they use " %s" for displaying any attributes.
  need to left-pad a space conditionally, perhaps by supporting %*s
  and sizeof(var).

* add additional support for user-specified sorting for the attr
  command when new attribute attributes are added (e.g., creation
  date)

* binary attributes, see backwards-incompatible section for details.


NEW OBJECTS
-----------

* multi-region VOL objects.  this basically will either introduce a
  notion of data-reuse where multiple regions reference the same VOL
  and get different spatial results, or a single primitive reports
  distinct material/region/spatial information that will get
  propagated up into separate region hits.  the prior is probably
  easier and less error-prone.

* view/camera objects.  non-geometry object type that encapsulates the
  concepts handled by saveview/loadview including awareness of
  orthogonal vs perspective, ambient lighting levels, and possibly
  styling/render modes.

  obviously need to be able to derive a homogeneous transformation
  matrix, but may want to encode/preserve scale, translate, rotate
  with prescribed ordering separately for proper reversibility.

  vect_t: eye point
  vect_t: view center point
  vect_t: up vector
  float: perspective angle (-1 ortho?)
  float: ambient intensity
  color_t: background / ambient color
  uint[2]: size / pixel dimensions

  vect_t: rotation vector
  vect_t: scale vector
  vect_t: translation vector
  derivable (or vice-versa):
  float[2]: grid cell (ortho-only)
  float[6]: view frustum (implies perspective matrix)
  float[4]: perspective projection (fov angle, aspect ratio, znear, zfar)

* datum objects.  implement support for datum points, axes, planes,
  and coordinate systems.  Nominal prioritized task decomposition with
  time estimates:

  2 day - stub in datum object into librt with sub-object types
  1 day - implement typein support for datum axes
  1 day - implement matrix pushing / verify rt_generic_xform()
  1 day - implement listing / text / plot callbacks
  1 day - implement adjust support for datum axes
  1 day - update in.xml documentation on typein interface
  2 day - add datum axis creation to archer GUI
  2 day - implement datum axis option panel in archer GUI
  2 day - implement datum axis mouse editing in archer GUI
  3 day - write up documentation on datums (with example)
  1 day - serialization+typein support for datum planes
  1 day - serialization+typein support for datum point sets
  1 day - serialization+typein support for datum coordinate systems
  3 day - callbacks for planes, point sets, and coordinate systems
  2 day - add datum plane to archer
  2 day - add datum point sets to archer
  2 day - add datum coordinate systems to archer
  1 day - update in.xml documentation on typein

* annotation primitive.  specifically a means to create an object in
  the database that can optionally be associated with another object
  and/or position(s) that a label refers to.  there are various styles
  such as a single line from a point to text and two lines (e.g.,
  indicating measurement) to text.

  the object should allow for different line styles including having
  no lines.  there should also be support for view-fixed or
  view-independent annotation placement (which requires a change to
  plot()'s and possibly prep()'s signature).  it would also be useful
  to allow an optional _annotation_ "thickness" so that the
  annotations can represent physical geometry (so they raytrace).

  the concept is nearly equivalent to a combined sketch+extrude object
  but with options specific to annotations.  the underlying export
  form should be fully generalized as much as possible with a
  higher-level "in" command constraining available options into a
  user-friendly form.  a new "annotate" command will similarly be
  needed to support modification of existing annotations (as well as
  creation ala the 'in' command).  see the web for tons of examples.

  References:
  http://en.wikipedia.org/wiki/Geometric_dimensioning_and_tolerancing
  ASME Y14.5 2009
  http://www.draftingzone.com/shoppingzone/6-1.pdf
  http://www.wikistep.org/index.php/Recommended_Practices_for_the_Representation_of_GD%26T
  http://www.wikistep.org/index.php/Recommended_Practices_for_the_Presentation_of_Dimensions,_Dimensional_and_Geometric_Tolerances
  http://www.wikistep.org/index.php/Associative_Text_in_3D_recommended_practices
  http://www.wikistep.org/index.php/Model_viewing,_basic_drawing_structure_and_dimensions_recommended_practices
  http://www.iigdt.com/Products/Images/0f390980.jpg
  openNURBS: opennurbs_annotation*

  Types of annotations:
	text:                   text.
						   text --,
	leader:                 text ---->.                \
				      .            .        \           .        .         .  .
	linear dimension:             |            |         .          |        |         |  |
			    .         |<-- text -->|                --->|  text  |<--   -->|  |<---- text
	angular dimension:   \  text
			      \_____.

  Annotation placement:
	xyz position:             (1.0, 3.5, 2.1)
	named reference(s):        hull.r
	above/below/left/right:    below
	offset:                    33.4
		(e.g., "at 1.0,3.5,2.1" or "below hull.r offset 33.4" or "at hull.r", etc.)

  Text:
	user-defined string:     my awesome component -----> .

	named/point reference:        hull.r1 -----> .
						  .               .
	automatic dimension (two points):         |_______________|
				   .        .           5.4 mm
	custom dimension label:    |<------>|<--.
						 \ Length of hull.r1: 5.4mm

	      (custom label specified via format specifier: "Length of %target: %size")

  Point properties:
       styles, for interface familiarity, provide option to describe
       points as [empty] . + x * ! as well as all 6: in a circle, in a
       box, and in a circle in a box.  that's 24 styles altogether.
       non-arrow annotations that lead to/from a point should allow
       source and target point styles to get set separately.

  Text properties:
       font name
       font size (height)
       font style: bold/italic/regular
       font color
       justification: left, center, right, bottom, middle, top
         (combineable options, e.g., "top left")
       placement: default, above, below, inline, interior, exterior

  Line properties:
       head style (point o-, arrow_to >-, arrow_from, <-, square #-)
       tail style (point o-, arrow_to >-, arrow_from, <-, square #-)
       line weight (thickness)                    .___.                     target        .---- text
       2d points:               text  ._____.     |    \                    .     .      /
					     \    |     .---> target        |     |     /
					      .___.                      -->|     |<---.
  Symbol type:
       degree:   (superscript circle)
       radius:   ('R', e.g., 'R10.5')
       diameter: (circle with slash, null symbol)
       ... several others
       http://www.tec-ease.com/gdt-terms.php

  Annotation properties:
       scale: fixed size or proportional to view
       alignment: to datum (plane or axis) or to view
       draw bounding plane
       draw target axes at uv offset position
       draw feature control frame (characteristic tolerances in
         symbolic form: www.draftingzone.com/shoppingzone/6-1.pdf)
       3d thickness

* offset surfaces.  provide feature edit operation to create a solid
  "level set" style object so you can represent degraded geometry
  states (e.g., damage around a hole in a plate of metal might be
  represented by the toroidal intersection with a cylinder some radius
  larger than the hole, providing a separate region that can have
  different material properties).

  geometrically, this is simply a means to separate a given object
  into multiple objects without changing the cumulative volume.  a
  linear offset from a given surface or set of surfaces is usually
  desired.

* minkowski and hull operations/objects.  These would be
  meta-combination objects similar to blending where objects are
  specified and a resulting operation is run on them.  minkowski sum
  provides an intuitive means to blend and hull a means to simplify.

* Cache objects.  These are proper non-geometric geometry database
  objects intended to store binary results that have a dependency on
  other object(s).  A named hash (e.g. md5) is recorded for each
  dependent object along with the computed results.

  Three potential candidates for leveraging cache objects are 1) prep
  objects containing the final prepped state of a given object
  hierarchy (particularly useful for BoT and BREP geometry), 2)
  raytrace objects containing the intersection results for a given
  view (i.e., a grid of primary rays), and 3) rtgl point samples
  (which is a variant of 2 but potentially view independent).

  Considerations:
    fast dictionary with expiration by time? (eviction during writes)
    cache rate read/write / sec > 10k @ 500bytes
    remain fast with millions of entries
    immediate retrieval (consistency)
    provide for concurrent access (concurrency), perhaps via sharding (N locks)

* alias objects.  this is an object handle in a geometry database that
  refers to another geometry database object.  in effect, it
  encapsulates the idea of a symbolic reference for database objects.

  alias objects should be very lightweight, corresponding to basically
  a simple named reference to another object.  this allows for
  geometry objects to have multiple names, all referencing a given
  primary name.  whenever an alias is referenced, it returns the
  object pointed to instead of the alias object itself (this includes
  the rt_db_internal()).  this prevents the creation of cyclic
  references.

  this directly supports geometry importers that contain object name
  mappings (e.g., part numbers to engineering names) as well as
  simply supporting multiple names per object that one might want to
  persist.  there is an issue of whether aliases show as top-level
  objects or even display by default without a listing option.

* edge feature edit objects: highly related to feature edits, object
  modifiers that add to or subtract from edges (e.g., smooth corners
  or representing a weld):

    ext    int      ext  ext           ext      int
    rounds/fillets, cuts/chamfers, and scallops/beads  (original)
      ------_        ------.           -----.          ----------
             \              \               /                  /
              |              \             |                  /
             /                \             \                /
            /                 /             /               /
           /                 /             /               /

* feature edits: support for adding holes (diameter+parameters),
  hollowing out objects (specify thickness), and (maybe) bending or
  twisting objects.

* CSG blending: smooth union, smooth subtract, smooth intersect.
  specify a k parameter that defines a blending radius between two
  objects as an additive operation.

* clone/grid/pattern/repetition objects: similar to aliases and the
  existing clone command which creates actual copies of objects, this
  entity represents copies of objects implicitly.  it maintains the
  grid pattern as a parameterization allowing it to be easily changed
  and more efficiently processed.

* image objects (tbd objects) for v5 geometry files.  not only the
  ability to have images in the 3D space, but to view-align them for
  image underlay modeling.

* material objects (non-geometric attribute-only objects) for v5
  geometry files.  instead of material attribute value becomes
  material object name.  material object encompasses hierarchical
  material traits.  some traits potentially of interest:
    - density
    - Young's modulus
    - yield strength (in different dirs, e.g., rolling & transversal)
    - ultimate tensile strength (also in different dirs)
    - Poisson's ratio
    - cost per ton?
    - ...

* parametric material properties.  support the ability to define
  material properties based on parametric values such as distance from
  surface, distance from medial axis, distance from centroid, distance
  from plane, etc.  this supports parametric descriptions of materials
  that have highly variable densities (e.g., bone, certain alloys and
  plastics, etc.).

* shader objects (non-geometric attribute-only objects) for v5
  geometry files.  allow shader string to refer to said objects for
  shader parameters.

* 3D plot objects for v5 geometry files.  very closely related to
  other ideas about having 3d wireframe objects, but these would
  probably be non-geometric in nature.  basically the plot3 files that
  are stored out to disk being stored as objects in the database with
  support for the overlay command to import, export, display them.

  minimally should probably support the basic drafting elements
  (predominantly from collada, dxf, iges, and step specifications):

	point := x, y, z
	line := start point, end point
	polyline := various (closed, open, paired, modified, etc.)
	circle := center point, radius
	ellipse := center point, major radius, minor radius
	hyperbola := center point, major radius, minor radius
	parabola := center point, focal length
	arc := center point, radius, start angle, end angle
	spline := degree, control points, knot values
	text := string, insertion point, size, style, alignment

* procedural geometry objects.  database objects that are described at
  run-time by a scripted definition.  at core, this is a means to
  define geometry via outboard descriptions that conform with a
  particular syntax (e.g., tcl or python).

  minimally, an object will need to define what parameters are
  required, what parameters are optional, and what default values will
  be used.  the object will also need to provide a procedural
  definition (e.g., a function or set of functions/objects) that
  receives parameter values in order to describe geometry on-demand.

  similar to shader, material, and other object constructs, it'll
  likely be desirable to support embedding of the procedural
  definition within a .g file as well as the ability to reference an
  external file that may be more conveniently edited.

  care will need to be taken to avoid bad behavior when presented with
  a malformed procedure (e.g., an infinite loop, fork bomb, syntax
  error, thrashing condition, etc.).

* ovoid - a 3D rotated oval "egg" shape.  can be constructed as the
  union of two separate ell.  very similar to our pill/particle
  primitive except that an elliptical curve connects the two shapes
  (and depending on which oval curvature is used) -- could probably
  use eto+sph evaluation for shot().

  http://www.mathematische-basteleien.de/eggcurves.htm
  http://www.geocities.jp/nyjp07/Egg/index_egg_E.html
  https://en.wikipedia.org/wiki/Oval

* conical edge (cubic) - unsure of this one's practical utility except
  as a means to construct a pinched tgc (unioning two halves).

* apple (quartic) - this is basically a continuation of torus where
  the ID > OD/2.

* cushion (quartic) - bowl shape, related to elliptical torus with
  filled interior.

* eight/piriform (quartic) - a conic/ellipsoid blending shape.

* goursat/tanglecube/tooth (quartic) - related to superellipsoid
  surface, provides corner/edge blending and rounding shapes.

* lemon (quartic) - elliptical nose cap (requested shape) shape.

* lipschitz blend - means to procedurally blend surface edges based on
  a blend function and sphere tracing. see "Combining CSG modeling
  with soft blending using Lipschitz-based implicit surfaces".

* SDF blending - likely requires defining per-prim distance functions,
  but would then allow automatic implicit blending, chamfer/bevel,
  rounding, and filleting.


WINDOWS
-------

The following binaries are not yet available on Windows.  The reason
is identified in parentheses.

bombardier (possibly just a problem with the build logic)


CONVERTERS
----------

* add obj cstype/bezier/surf/curv/param/trim/etc import for nurbs
  import/export support

* add glTF exporter (.gltf and .glb file formats)

* add 3MF importer/exporter (3D printing file format like STL that
  supports materials, colors, and other information.)

* add gcv support for the Microstation file format (DGN), probably
  leveraging http://dgnlib.maptools.org/ (MIT-licensed)

* integrate the submitted x3d-g (Web3D, VRML successor) importer
  (pending patch on sf)

* compare libIGES (lgpl, https://github.com/cbernardo/libIGES) as
  potential replacement for our complex IGES conversion logic.
  appropriate time for review when IGES gets added to libGCV.

* investigate the asset import library (assimp.sf.net) to see whether
  we can replace a lot (but probably not all) of our bot-centric
  importers/exports (ply, obj, stl, etc.) with the assimp library to
  save us the time/effort of supporting those parser ourselves.

* make the converters export all top-level objects by default

* implement support for exporting sketch objects via g-iges

* by default, only export valid (manifold, solid if 3d, etc) objects.
  have option to override and export invalid entities.

* add csv, xml, nff, bzw, pov, blend geometry import and export
  support

* finish obj-g importer.  need to test more inputs and make sure all
  geometry is preserved on import in some form.  make sure new libobj
  parser works and is integrated with new front-end.

* implement a g-step exporter (with NURBS, implicit CSG, and NMG/BoT
  options)

* implement a g-dae (Collada) exporter and dae-g importer
  http://en.wikipedia.org/wiki/Collada

* implement a g-nc (g-code) exporter.  ideally this converts geometry
  to NURBS format, trims surfaces, evaluates boolean expressions, and
  then generates tool paths on resulting surfaces and interior paths.
  http://en.wikipedia.org/wiki/G-code

* implement a u3d-g importer
  http://en.wikipedia.org/wiki/Universal_3D
  http://libharu.org/wiki/Main_Page

* implement a g-pdf exporter and/or open source 3D PDF library
  http://developer.techsoft3d.com/adobePDF/index.html

* SVG renderer.  go straight from 3D model to a 2D vector image for a
  given view.  similar to the plot/postscript wireframe view saves,
  this would need to store projected contours (ala rtedge) and filled
  color regions.

* implement a g-sat (Solidworks) exporter and sat-g importer
  http://local.wasp.uwa.edu.au/~pbourke/dataformats/sat/sat.pdf

* implement a g-json exporter
  http://www.json.org/

* implement a g-xml exporter
  http://en.wikipedia.org/wiki/XML

* implement a ls-dyna "keyword" file format importer.  perhaps extract
  as nmg/bot boundary representation meshes.  lots of great vehicle
  datasets at http://www.ncac.gwu.edu/vml/models.html
  Update - above link seems to be down as of 2020, see:
  https://www.nhtsa.gov/crash-simulation-vehicle-models
  https://www.ccsa.gmu.edu/models/



STEP
----

* add hierarchy preservation support to step-g

* implement g-step exporter (see above)


BREP/NURBS
----------

* optimize prep.  crazy slow building a surface tree deeply to ensure
  surface evaluations will converge to proper hit points.  this uses a
  lot of memory and requires cpu-costly derivative evaluations during
  surface splitting.  it also uses classic object structures and
  incoherent pointer chasing during construction and traversal.

  among several optimization approaches discussed, one plan involves
  making prep only minimally subdivide surfaces (e.g., only one
  subdivision per surface initially) and letting ray tracing
  dynamically evaluate surfaces as needed.  a heuristic that takes
  volume and/or structural complexity into account (e.g., no
  derivative changes across all encompassed knots) could result in a
  better initial per-surface prep.  with knowledge of the prep
  subdivision bounding volume sizes, it should be possible to
  calculate static arrays per surface that will serve as coherent
  book-keeping during shot.  instead of pre-calculating the depths
  during prep, the static arrays get filled in on-demand during shot
  and are used to track bounding box and UV extents as rays require
  additional surface subdivision.  it should be possible to construct
  an extents container such that for a given depth, a ray will only
  calculate further depths as needed with minimal locking:

  0) prep: organize surfaces into BSP container (kd-tree)
  1) prep: calculate maximum possible subdivision depth
  2) prep: allocate extent container array depths
  3) prep: calculate initial required subdivision(s)
  4) prep: fill initial subdivisions into array
  5) shot: traverse BSP to find surfaces in proximity
  6) shot: traverse subdivision array to lowest initialized level
  7) shot: evaluate surface to determine need for further subdivision
  8) shot: while subdivision needed, calculate subdivision and store
  9) shot: evaluate and return surface hits

  The way to do step 8 with minimal locking involves having an
  initialization / sentinel value that is checked for non-zero and
  only set after array values are already locked, written, and
  unlocked.  Doing this, it is possible for multiple rays to evaluate
  the same subdivisions unnecessarily, but avoids locks entirely in
  the common case and minimizes lock contention.

  [HARD] Combines lock-free concurrency (sentinel array fill), numeric
  derivative-convergence heuristics, and a cache-coherent
  kd-tree/extent-array layout -- all in the hot path at once.
  Research-grade on all three fronts.
  [FAN-OUT: poor for the core algorithm (one expert design); fan-out
  only to prototype/benchmark competing subdivision heuristics.]

* create a BC_Brep class that inherits from ON_Brep so we can cleanly
  extend and implement functions that were intentionally removed from
  openNURBS.

* implement tessellation support.

* tighten up the bounding boxes around nurbs geometry.  seems to be
  bounding the untrimmed surfaces instead of the trimmed edges
  resulting in boxes (hopefully) larger than they need to be.

* update to openNURBS 5.0 (2011-02-02)

* identify useful concepts implemented in the old NURBS code that are
  not present in openNURBS, and port that code to openNURBS data
  structures and routines.  This will eventually allow us to remove
  the old NURBS code.

* implement boolean evaluation of nurbs surfaces

  [HARD] The canonical open problem in solid modeling: robust
  surface-surface intersection, trim-curve generation, and topology
  stitching are what took ACIS/Parasolid teams decades.  No ground
  truth, no shortcut; couples with "implement tessellation support" and
  the trimmed-surface bbox item.
  [FAN-OUT: design only -- a judge panel of independent SSI/trimming
  approaches helps; the implementation itself is serial.]

* NURBS editing command, let you interactively
  add/update/join/split/remove component points, edges, surfaces.


NMG/BoT
-------

* getting some unexpected misses when testing facetization of havoc
  regions.  If the issue is super-thin triangles in raytrace, see if
  we can handle by solving the plane intersection to get a 3D point,
  then returning that if we're within tol distance of the triangle
  edges and we don't get any hits from topological neighbors.  If
  the triangle is thin enough, that should be a reasonable answer
  (at least for a 3D point - the normal may be something else again
  if the 3 points aren't distinct enough to properly calc the plane.)

* bot overlaps when unoriented, when clearly not overlapping

* resolve bot bin sort optimization crash, disabled during release

* rt moss.g facetize rt bot bug

* implement a means to store per object, face, and vertex information
  on BoT mesh geometry.  useful for per-face/vertex shading as well as
  storing analytic information during conversion (e.g., per-face
  fastgen material codes)

* bot bounding box size -- see below

* libbn's tri_specific structure requires user-provided memory for
  normals.. this certainly saves memory if the triangles don't have
  normals but at a rather expensive malloc cost (which is being seen
  on large BoT models) during prep.

* ensure robust and fast nmg->bot conversion

  [HARD] NMG is famously fragile; "make it robust" is a perennial that
  resists closed-form fixes, and the tessellation crashes (ETO /
  metaball / DSP infinite recursion + stack smashing in BUGS) are
  geometry-dependent.  ~231 files reference nmg_*.  See also the NMG
  ray-tracing malloc-per-shot item below.
  [FAN-OUT: yes -- one agent per failing primitive/tess path to build a
  reproducible failure corpus; repairs land serially.]

* facetize creates BoTs crappily by only looking at first region,
  first shell, instead of the whole nmg model.

* nmg_bot() and nmg_from_bot() only work with shells.  verify that all
  callers iterate over all shells or write a model version that does a
  complete conversion correctly.

* refactor all of the nmg processing (back) into its own library so
  that external users can manage mesh geometry without needing to pull
  in everything else in librt.  consider moving other polygonal
  specific logic to libnmg, eventually moving all polygonal logic out
  of librt, libtie, etc., and into libnmg.

* enhance the bot data structure to contain a generic pointer that
  could be used to point back to the NMG it was generated from.  This
  could allow ALL raytracing of polygonal models to use libtie/BoT
  raytracing routines, speeding up NMG raytracing and simplifying the
  raytracing code.

* optimization of NMG ray tracing.  the hitmiss bookkeeping presently
  used has a malloc/free occurring per shot().  allocations need to
  occur during prep only.  the presently render more than an order of
  magnitude slower than tracing that nmg converted to an equivalent
  BoT due to malloc/free calls being made during shot(). Confirmable
  with a simple test case of a sphere converted to an nmg:

    make sph sph ; facetize -n sph.nmg sph

* implement a routine/command to convert from a bot to an nmg
  (similar/related to the nmg-bot tool, but the reverse).

* need a simplified means to programmatically create and edit BoT
  meshes via the command line without resorting to get/put.


RTGL
----

Need before enabling:

Blasting havoc_tail when raytracing havoc doesn't result in a re-set
of the raytracing - it just re-sizes the view to havoc_tail and
continues with the original raytrace.  Track down why - should clear
everything and start over.  (Appears on Linux, not on OSX).

Need general robustness testing - ensure no crashes when switching
display manager types multiple times in multiple locations.

For cleanup:

Move pattern raytracing logic into librt.

Need a way to cache point data so we don't re-raytrace unchanged
geometry over and over.

Job server should be reworked into a general mechanism, instead of
being rtgl specific.

Provide a generic mechanism in MGED run loop to hook in features like
point cloud rendering, instead of hard-coding it.

* consider utilizing something like moodycamel::ConcurrentQueue for
  handling ray dispatch: https://github.com/cameron314/concurrentqueue


INFRASTRUCTURE
--------------

* ensure successful build on mingw

* the binary windows installer is missing headers for our external
  dependencies (Tcl, zlib, and OpenNURBS in particular as the likes of
  bu.h and raytrace.h requires them)

* remove all of the MSVC sections in the CMakeLists.txt files.
  perform proper library/function/flag tests where necessary.

* ensure primary cmake option parity with summary option listing

* investigate ignoring .hidden directories/files from dist packing so
  that internal build directories can be used instead of external ones

  -- is this needed?  what's not working with make package and
     make package_source?

* ensure it's possible to set global CFLAGS/CPPFLAGS/LDFLAGS that are
  in addition to any/all that we automatically set


THESE BREAK PROTOCOL OR ARE BACKWARDS-INCOMPATIBLE
(i.e., v6 database format)
--------------------------------------------------

* have all primitives record a matrix so they may retain a local
  coordinate system even after pushed matrices.  this also will allow
  primitives like the torus to support non-uniform scaling.

  [HARD] On-disk format change rippling through every primitive's
  import/export/xform/raytrace -- and the non-uniform-tor raytrace it
  is meant to enable is itself unsolved.  Requires a v5->v6 migration
  plus full revalidation.
  [FAN-OUT: yes -- one agent per primitive for the import/export/xform
  changes; the format/migration design stays central.]

* change convention of using 'u', '+', and '-' for unions,
  intersections, and subtractions respectively to symbols that
  unambiguously describe the underlying CSG operation.

  '+', 'x', and '-' are the dominant ASCII option or (better) using
  unicode logic symbols for U and upside-down U.

  Union/Disjunction: + ∨ v u (logical OR)
  Intersection/Conjunction: x ∧ ^ . & n (logical AND)
  Subtraction/Difference: - (logical AND NOT)
  Negation/Complement: ! ¬ (logical NOT)

* remove the bspline primitive

* remove the poly primitive

* remove the hf primitive

* a cut feature edit.  implementation could be represented as the cube
  that bounds a geometry object.  eight points somewhere on the edges
  of the cube define an intersection volume on the object.  by
  default, the eight points could be positioned at the corners of the
  cube and would remain constrained to reside on one of the three
  adjoining edges for their respective corner.  this would provide a
  simple user interface where a face could be selected to move a cut
  plane through an object (moving four points along four edges), or an
  edge could be moved to move two points simultaneously, or each
  individual point could be moved along their edges to define the
  intersection object.  allowing the points to be deconstrained so
  they can move into the interior of the bounding volume or into the
  interior of a face could be an advanced option.

* fix the database I/O writing to properly support the addition of new
  primitive types.  this includes modifying the major/minor code or
  combinations/regions and binary objects

* add database support for constraints, expressions, parametric
  values, construction history, and timestamping.

  [HARD] Effectively "make BRL-CAD parametric": a new
  evaluation/dependency engine, construction history, and selectable
  subtree representation baked into the format.  Enormous; assumes the
  ambitious reading (a real parametric kernel, not just storage).
  [FAN-OUT: poor for the kernel; useful only for parallel design
  exploration of competing parametric/constraint models.]

* make struct rt_functab's ft_label bigger and/or dynamic (e.g., vls)

* remove the storage of the never-implemented keypoint parameter for
  extrude objects.

* rename 'part' primitive to 'pill' or remove it entirely in favor of
  a more generalized metaprimitive primitive.

* binary objects need to write out their minor type during export, not
  relying on the raw wrapper to encode it, so that proper
  import/export can be performed without relying on minor_type hacks
  in the API.

* implement support for binary attributes.  the general idea is to
  allow collections of (at a minimum) 64-bit integer, 64-bit floating
  point, and strings.  the type needs to be encoded when written out
  to storage.  there is high-desirability towards using a binary
  encoding format already defined and in popular use like BSON,
  UBJSON, or CBOR.

  It's highly likely that binary attributes can be implemented in a
  backwards-compatible manner.  The v5 spec separately tracks the size
  of attributes and objects from the size of the strings that are
  serialized out into them.  It may be possible to store a
  shortened/empty string, but record a larger attribute/object size,
  allowing for binary data beyond the attribute value '\0' termination.

  [HARD] BSON/CBOR encoding smuggled into the v5 spec's size fields for
  backward compat, plus (paired with the libbu mime-API retirement)
  replacing the static enum mime API with a runtime-populated
  libmagic-style engine.  Format + API redesign with compat traps.
  [FAN-OUT: partial -- parallel survey of encodings and an audit of all
  mime-enum users; the spec/compat work is central.]

* change format of related programs (especially filters) so the
  input/output files are handled identically. two examples of
  different handling:

    png-pix   file.png > file.pix
    pix-bw  < file.pix > file.bw

  (desired style to be determined)


FUNCTIONALITY NEEDED TO SPEED UP RAYTRACING
-------------------------------------------

  [HARD] Re-architecting the ray-primitive interface for bundled/SIMD
  traversal means rewriting every primitive's intersection routine and
  the partitioning core while preserving exact results -- broad,
  perf-critical, and easy to get subtly wrong.  (Applies to this whole
  section: merge shot/vshot, bundles, SIMD, SAH, kdtree.)
  [FAN-OUT: yes -- one agent per primitive to convert shot()->bundle
  with a result-equivalence harness; the kdtree core stays central.]

* merge shot and vshot

* implement bundles shot - array of rays

* separate ray structs - make fit in cache line

* refactor primitive data -  make fit in cache line

* implement SIMD shots

* implement SAH for all primitives (routine that fires a ray at each
  primitive for initial estimate, caches result)

* write and use kdtree - make traversal cache coherent

* replace adrt's kdtree with one that builds faster


GEOMETRY MODELS
---------------

* CSG shaderball

* solid teapot

* studio box

* CSG lightcycle


DOCUMENTATION
-------------

* document rt script commands

* Document a GUI feature list (prioritized).

* Document a CLI feature list (prioritized).

* HTML docs that display in MGED via menu are way out of date and look
  bad per modern standards. Needs to be updated/replaced with doxygen
  docs and/or clean presentation layout with overview, tutorials, and
  reference.

* Need ability to search manual pages

* rename MGED Help->Apropos to Help->Search Commands (apropos)

* BRL-CAD Primitives
	An overview of the various primitive object types in BRL-CAD,
	their range of features, and a description of their input
	parameters.

        Create a catalog of all possible entity types.  Include
        distinct parameterizations with sufficient variety that
        conveys the object's parameterization options (e.g. ell as
        sphere, flat disc, long spike, etc.).  this is necessarily
        defined per object type and possibly programmable.  See
        src/proc-db/csgbrep.cpp for a basic start.

* update the rt* manual pages to note that they can all write out to
  various image formats like png just by specifying an output file
  extension.

* document gqa centroid and moments of inertia options

* document the new NURBS/BREP primitive, capabilities and limitations


  Need to revisit utility of spherical mapping, used by sh_spm and
  sh_points, used for environment mapping (e.g., stars):

    pix-spm
    spm-fb

  These are mged commands that either need to be migrated to libged or replaced/merged with other commands:

    reset        : resets view to 270/90
    rmats        : read matrixes from a savekey(n) file
    rt_gettrees  : full rti command for shooting rays and inspecting geometry, creates new named command object

3rd party tools we control / bundle, but need docs if anyone else is
  to use them or contribute:

    perplex
    re2c

  Needs separate repo:

    ttcp

  Converters that belong in GCV:

    3dm-g
    g-dot
    g-jack
    g-off
    g-step
    g-voxel
    jack-g
    off-g
    raw-g
    shp-g
    step-g
    tgf-g


* write up some documentation on other build tools besides make -
  CMake supports other generators, wouldn't hurt to detail how to
  trigger builds in them (MSVC is partially covered, make sure to
  coverage is complete - others include Eclipse, XCode once we get the
  kinks ironed out there, CodeBlocks.  Ninja build tool and its
  CMake support are worth documenting too.

* all of the rt* tracers share common code and common options, but do
  not share common documentation.  refactor documentation to use
  include directives so that there is one place where all of the
  common options are documented.  update usage statements to reflect
  commonality as well.

* Categorize the entity types from STEP * IGES into geometry,
  relationship definitions, metadata, etc., add any missing types
  of interest (like, say, metaballs) - try to create a comprehensive
  list of things we might need to consider when writing converters.

* gather v&v docs on configuration management process, user manuals,
  process documentation, software documentation, model descriptions.

* BRL-CAD Overview Diagram
	Completed, but not integrated

* BRL-CAD Industry Diagram
	Completed, but not integrated

* BRL-CAD Architecture Diagram

* Technical Papers
	- Fast Malloc
	- STEP Conversion
	- GCV
	- Solid Modeling
	- Representation Methodology / Sensitivity
	- NURBS Ray Tracing

* BRL-CAD Commands Quick Reference
	Partial

* MGED Quick Reference
	Completed, but not integrated

* MGED Interface Reference
	Keybindings, GUI elements, scripting

* Introduction to BRL-CAD Tutorial
	mged, rt, pix-png, rtcheck, rtarea, rtweight, gqa, fbserv,
	nirt.  Succinct overview of less than 10% of the core
	functionality in 10 pages or less (plus pictures).

* Introduction to MGED Tutorial
        This exists, but has not yet been added to the repo.

* Technical Overview of BRL-CAD
	Describes everything in the package succinctly yet
	comprehensively.  Survey of all the major features,
	methodologies, and tools implemented in BRL-CAD with coverage
	on code maturity, library encapsulation, and tool aggregation.

* BRL-CAD Validation and Verification
	Overview of how contributions to BRL-CAD are reviewed and
	tested including regression, performance, and system
	integration testing as well as independent ARL configuration
	review.  This specifically addresses the issue of world-wide
	and potentially anonymous contributions to BRL-CAD and how
	those changes are managed.

* DoD V/L M&S Industry Diagram
	Similar to existing Industry Diagram.  Survey of all the major
	features, methodologies, and tools implemented in BRL-CAD with
	coverage on code maturity, library encapsulation, and tool
	aggregation.  This one is a particularly useful marketing and
	educational visual aid for describing how the various M&S
	codes interoperate in terms of features and scope.

* Commercial CAD Comparison Diagram
	Comparison of how BRL-CAD overlaps feature-wise with various
	major commercial CAD systems.

* Solid Geometry Representation Comparisons
	Describe the implications, tradeoffs, and conversion issues
	involved when converting between different geometry
	representations.  Includes describing implicit geometry,
	explicit polygonal boundary representations, explicit spline
	surface representations, volumetric models, wireframes,
	boolean operations, feature edit operations, and parametric
	modeling.

* BRL-CAD Open Source
	An overview of how BRL-CAD is organized as an open source
	project and community describing the developer meritocracy,
	code reviews, development prioritization, and change
	management.  This introduces and explains the concept and
	philosophy of open source software, its fundamental tenets,
	and the basic "why and how" it works.

* History of BRL-CAD
	Covers the 30-years development history of BRL-CAD, from 1979
	to 2009, documenting the origins of the project, major
	development achievements, the conversion to open source, and
	lesson's learned.

* BRL-CAD Manifesto
	Vision & Scope

* Implementing a BRL-CAD Primitive
	How-To for creating a new primitive in BRL-CAD that can be
	ray-traced, tessellated, plotted, and transformed seamlessly.

* Procedural Geometry in BRL-CAD
	How-To for creating new tools that create geometry.

* Guide to Rendering with BRL-CAD
        Basic overview of all the ray tracers and primary rendering
        options supported.

* BRL-CAD Ray Tracing Shaders
	An overview of the various shaders and shader options
	available in BRL-CAD.  Create a catalog of all
	possible/distinct/useful shader settings.  See
	regress/shaders.sh for a basic start.

* BRL-CAD Ray Tracing Shader Development
	How-To for creating new shaders.

* Geometry Conversion with BRL-CAD
	Overview of the various geometry conversion facilities in
	BRL-CAD and how they related to solid geometry
	representations.

---
See the feature request and bug trackers for more tasks and future
planning efforts: https://sourceforge.net/tracker/?group_id=105292

TODO items should be formatted to column 70 (M-q in emacs), no tabs.
