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


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

* 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

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

* brlcad-config build helper script is not working (not reporting
  -llibs, reporting semicolon list for 'brlcad' lib).  Example working output:
  $ /usr/brlcad/rel-7.18.0/bin/brlcad-config brlcad
  -L/usr/brlcad/rel-7.18.0/lib -m64 -L/usr/local/lib64 -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -fexceptions -ggdb3 -D_FORTIFY_SOURCE=2 -O3 -w -L/usr/brlcad/rel-7.18.0/lib -lbrlcad -lged -lwdb -lrt -lbn -lbu -ltcl8.5 -ldl -lm -lpng14 -lz -lc -lpthread -lregex -lsysv -lopenNURBS -lanalyze

  $ /usr/brlcad/rel-7.18.0/bin/brlcad-config rt
  -L/usr/brlcad/rel-7.18.0/lib -m64 -L/usr/local/lib64 -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -fexceptions -ggdb3 -D_FORTIFY_SOURCE=2 -O3 -w -L/usr/brlcad/rel-7.18.0/lib -lrt -lbn -lbu -ltcl8.5 -ldl -lm -lpng14 -lz -lc -lpthread -lregex -lsysv -lopenNURBS

* OpenCL for enhanced performance boolweave sorting

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

* make sure we can run db_dirbuild() multiple times without creating
  duplicate entries.

* tree command shouldn't infinite loop when encountering a cyclic
  path - need to print a warning and stop walking.  Requries 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/

* 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 -? needs to provide help

* mged> nirt -f fmt doesn't seem to work at all

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

* investigate problems with struct parsing running the MGED
  "vars" command - most visible on OpenBSD, but Linux valgrind can
  also see issues.


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

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

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

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

* MGED's startup directory is inconsistent and sometimes problematic.
  If the current working directory is read-only (e.g., a default
  system install and opening one of the sample .g files), then
  numerous commands the write out to the current path will fail (e.g.,
  "idents file.log").  Review startup path behavior and consider using
  $HOME or some other system path, unless started on the command-line.

* rtwizard's reopening of the database is causing db_dircheck
  "Duplicate of..." errors when opening read-only .g files.

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

* the osgl libdm backend has what appears to be an off-by-one-pixel
  error in the x and y directions with respect to mouse placement.
  Using kmag, can see tha putting the mouse cursor over the center
  yellow dot and center clicking (which should be a no-op, and is
  with ogl) results in the scene shifting slightly.

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

* implement general analyze estimate (perhaps just raytrace it) for
  primitives where values like surface area, volume, or bb are very
  difficult to calculate.

* 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

* rtwizard unit test legitimately failing on mac/windows

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

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

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

* STIX 2.0 fonts are released, using OpenType - check to see whether
  we can upgrade to these for our DocBook processing

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

* Investigate using https://github.com/weiss/c99-snprintf to guarantee
  snprintf cross-platform.  There are potential drawbacks to the current
  MSVC approach pre Visual Studio 2015 (_snprintf doesn't null terminate
  on overflow, and _snprintf_s returns -1 on overflow...)

* 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

* look at components of the Screened Poisson code and figure out where/how
  they would map into BRL-CAD components. (this is partially to see whether
  we can (re)implement this logic in our framework and partially an exercise
  in BRL-CAD library scoping)

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

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

* evaluate OpenMesh (http://www.openmesh.org) and OpenFlipper
  (http://www.openflipper.org) for smoothing, decimation, and
  additional GCV conversion formats.

* GCT decimation assumes no edge is shared by two triangles except
  once in the reversed order (AB, BA).  Needs basic check to avoid
  failures/crashing.

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

* need routine that returns a color given a path, similar to
  rt_comb_get_color() but full path so that inheritance is taken into
  account and colors set correctly.

* 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??)

* investigate updating our fnmatch code to use OpenBSD's non-recursive
  implementation, added starting at revision 1.16:
  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/fnmatch.c

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

* look into whether db_dirbuild should call db_update_nref

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

* Document a GUI feature list (prioritized).

* Document a CLI feature list (prioritized).

* 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

* 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

* BU_SETJUMP/BU_UNSETJUMP into macros

* 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

* add an mk_extrude() routine to libwdb.

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

* rework fbcolor, fbzoom, and fbpoint to not use termlib, instead just
  using regular printing and input reading in a loop.

* See if it is possible to simplify btclsh/bwish code when it comes
  to relying on libtermio - linenoise can do the basics, and for fancier
  keybinding/word based navigation see if launching in Emacs can suffice:

  ;; per https://emacs.stackexchange.com/q/18672
  (defun btclsh ()
    (interactive)
    (require 'term)
    (let* ((cmd "btclsh")
           (termbuf (apply 'make-term "btclsh console" cmd nil nil)))
      (set-buffer termbuf)
      (term-mode)
      (term-line-mode)
      (switch-to-buffer termbuf))) 

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

* fix the redblack tree callback function signatures.  they're
  declared and handled as taking (void) but they actually take a
  pointer and an int.  need to create a proper void* data parameter or
  change the interface to not require so much cast spagettery.

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

* 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 poly2tri's algorithm along the lines
  of what bitfighter did:  https://github.com/raptor/clip2tri
  Some useful notes here: http://stackoverflow.com/a/16115775

* Translate the poly2tri routines into libbg C code

* 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

* provide a viable FindBRLCAD.cmake

* 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 Blender's (OSL-based) Cycles engine:
  http://code.blender.org/index.php/2013/08/cycles-render-engine-released-with-permissive-license/

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

* investigate the possibility of using Appleseed (http://appleseedhq.net/)
  to perform visual image rendering using librt shotline data for input.

* the scale structure in bn_cmd_noise_slice (bn_tcl.c) was never
  initialized. it looks like somebody has planned to extend the
  function but never carried out

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

* use spatial partitioning during boolean processing of polygonal
  meshes.  good approach might be to generalize TIE's kd-tree to
  polygons or even create a new scheme (e.g., an integer-indexed grid
  layout).  data coherence would be nice (but not essential).  current
  approach is at least O(N^2) with large constant time.  New should be
  O(N*log(N)).

* 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

* test/fix patch-g on windows.  the input file read loops assume
  unix-style files resulting in parser errors.

* merge conv-vg2g into dbupgrade

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

* add option to push/xpush to stop at the region level, to stop before
  primitives, to stop after N levels, to stop before N levels.

* make rt_dirbuild()+rt_dirbuild() work without vomiting error
  messages about duplicate geometry.  should be able to open the same
  database multiple times without running into rt_uniresource
  directory duplication

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

* check libbu implementation of red-black trees (see note in bu.h
  referencing an error in the Cormen book used as a basis)

* make libfb 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 libbn/plot3.c 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.

* provide pkgIndex.tcl files for bu, bn, rt, fb, dm so we can properly
  package require the libs without an explicit 'load'

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

* fix the "(type)(size_t)val" hacks (using ints like ptrs, etc.)

* 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

* deprecate dbcp and merge functionality (and improved
  double-buffering) with the buffer tool.

* 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

* bu_cv_optimize() should be using bu_byteorder().

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

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

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

* libfb needs to have the fb_open/close_existing functions refactored
  into the function table and have the #ifdef sections removed.

* 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

* deprecate either orot or rotobj

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

* make bombardier actually send the report somewhere

* hook bombardier in for crash reporting

* modify the new tree traversal code to be generic

* 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

* better/consistent argument processing supporting both long and short
  option names, perhaps using argtable

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

* preserve an arb8 as an arb8 (instead of writing as arb6 or arb5) and
  similarly for the other arb# sizes

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

* Generate plain .zip files for Windows binary releases

* fix the variety of ami.tcl and ampi.tcl tclscript warnings/errors

* run indent.sh on directories (one at a time, validating results)

* configure support to enable/disable framebuffers, display
  managers, geometry converters, and image converters.  consider
  apache's module management as an example.

* review and merge in the rest of the GSI modifications

* display the current mode in mged graphics window

* Optional compile-time support for using GMP or CLN for arbitrary
  exact precision arithmetic computation support

* 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

* add geometry example of building 238

* 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

* 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

* design plugin system to allow domain specific tools (say, for
  example, a tool to create propeller parts) to identify themselves
  and their features to BRL-CAD, and to allow BRL-CAD to incorporate
  those features as an integrated part of interaction environments.

* see if it is possible to use tec/ehy primitives to create a proc-db
  for airfoil/wing shapes.  Interesting possibilities with boolean
  combinations of these primitives, provided their continuity at the
  ends ensures continuity all along "seams" - something to consider.

* we need to define a libbu api for option handling that supports more
  features than getopt:

  - need support for long options (e.g. --help and --color, not just -h
    and -C)

  - 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:

    + should be in C code - will be needed there, and easier to get it
      from there to other formats than vice versa.

    + should 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 snippit
      of text or markup that could be incorporated into the final
      document - e.g. 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 absolute
      most current option listing and short descriptions for the other
      docs.

  - need to allow order dependent options (e.g. <command> inputfile
    outputfile) that become order independent if enough information is
    available, e.g. the above would work and <command> <opt1> -i
    inputfile <opt2> -o outputfile <opt3> would also work.

  - (maybe) incorporate some sort of sanity/bounds checking into the
    option definitions API - i.e. in the C definition of an option,
    there could be optional parameters to indicate the type and bounds
    of valid input to that option.  Won't always be possible, but may
    be a good feature to have if it can save lots of repetitive coding
    of bounds checking in programs.

  *might* be worth taking a look at http://rpm5.org/files/popt/ to see
  if they have any code we could snarf to make life easier, but
  regardless we need a libbu API on top of any other code - at such a
  core level, we can't introduce an external API.

* 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:
  http://ngplant.sourceforge.net)


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

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

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

* fix !!! in src/libged/tables.c where a temporary file is getting
  used.  needs to call bu_temp_file().

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

* translate lc command to libged (discovered in Feb. 2015 to have already
  been done -- need information regarding when this was done and committed).

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

* killall command reports db_lookup failures if the target object
  doesn't exist (maybe we only care about refs).  should keep quiet.

* the new "exists" command is a beautiful corollary to the unix 'test'
  command.  make the usage match, remove options that make no sense
  after you've replaced instances of 'file' with 'object', and add
  options specific to testing geometry (like whether two objects
  overlap, whether an object's volume is greater than some value or
  equal to zero, whether two objects are actually the same object
  (geometrically), etc.).

* 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')

* deprecate dbfind - ensure functionality is fully captured by the
  search and ls commands, make it report a deprecation statement on
  use and utilize ls under the hood.

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

* incorporate some variety of spatial partitioning into the facetize
  command (may involve just rewriting it) to try and realize MUCH
  faster tessellation of CSG geometry.  Current routines are doing a
  lot of unnecessary work that tends to result in explosive completion
  times for worst-case scenarios - try to get closer to the "only do
  the work we need to" ideal.  Once a new idea is proven in that
  command, it should be made into a libgcv routine and
  converters/other commands retargeted to use it.


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

* See doc/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 homogenous 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
  src/other/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.).

* spheroid (quadratic) - special performance case of ell

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

* box-spline blend - blending object that is defined by an arb8
  volume, blending any entities within that volume that intersect

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


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)
enigma     (not ported)
fbcolor    (TERMLIB)
fbed       (TERMLIB)
fbpoint    (TERMLIB)
fbzoom     (TERMLIB)
ir-X       (X11 specific)
irdisp     (X11 specific)
lgt        (TERMLIB)
pl-X       (X11 specific)
pl-dm      (possibly X11 specific)
pp-fb      (TERMLIB)
remrt      (remrt dir commented out for WIN32 in src/CMakeLists.txt)
rtsrv      (remrt dir commented out for WIN32 in src/CMakeLists.txt)
scriptsort (lex)
ttcp       (not ported)

The MGED points support doesn't appear as an executable, but it is
missing on Windows due to needing lex.


CONVERTERS
----------

* add glTF importer/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)

* add support to x3d-g for NURBS entities

* compare libIGES (lgpl, https://github.com/cbernardo/libIGES) as
  potential replacement for our compelx 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)

* see additional TODO items in file './src/other/step/README'


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.

* 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

* plate mode NURBS/BREP objects.  Similar, if not identical, to plate
  mode BoTs, 'brep' objects need the ability to have a thickness
  described so you could automatically handle non-solid NURBS and
  sheet-metal style geometry without requiring surface solidity.

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


NMG/BoT
-------

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

* implement conversion of plate-mode BoT into volume-mode BoT,
  probably as a 'bot' command subcommand.  this basically entails
  implementing the BoT tessellation callback for plate-mode which will
  let boolean evaluation succeed as-is.  might require adding a
  parameter in case we want to dump the mesh as-is.

* ensure robust and fast nmg->bot conversion

* 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

  -- Um.  Not sure this is fully achieveable - we only want to
     summarize a subset of the src/other settings in the summary
     printout, was my (CY) understanding...

* 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

* fix failure disabling IF_X when X11 headers are not found.
  include/fb.h still ends up entering the IF_X section and declaring a
  function that takes a Display and other X11 objects


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

* support matrices over any object, including over top-level combs
  without affecting members and including over primitives so they may
  optionally retain a local coordinate system even after a push
  operation this also will allow primitives like the torus support
  non-uniform scaling.

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

* see the CHANGES file for items that have been marked as deprecated
  or available to be removed as obsolete items.

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

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

* 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


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

* CSG shaderball

* solid teapot

* studio box

* CSG lightcycle


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

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

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

* 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

* Low-hanging fruit, add missing manual pages:

    archer
    bombardier
    bot_fuse (ged)
    damdf
    dauto
    dauto2
    dconv
    ddisp
    dfft
    dmod
    dpeak
    dsel
    dstats
    dwin
    gcv
    ihist
    imod
    isst
    istats
    lowp
    pix3filter
    pixcount
    pixelswap
    pixembed
    plot3stat
    rtsil
    rtsrv
    smod
    step-g
    umod
    ustats

  Shape tools installed without docs.  may absorb into ged as plugins
  or may rename, but still need docs:

    bolt
    fence
    gastank
    handle
    human
    picket_fence
    window
    window_frame
    wire

  User-facing commands reported by 'help' needing docs.  some are
  implemented as Tcl, others to consolidate, but still need docs:

    adjust
    bot_smooth
    cc
    closedb
    dbversion
    dmtype
    dsp
    dump
    e_id
    form
    joint
    labelface
    loadview
    lod
    match
    mirror
    nmg_fix_normals
    png
    put
    relos
    remat
    reset
    rmats
    rt_gettrees
    rtabort
    rtedge
    rtweight
    savekey
    shaded_mode
    unhide

  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

  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

* DocBook: create a DB index.xml to generate a doc listing (with
  hot links) for the html and pdf collection

* DocBook source: add xsl customizations for figure and table title
  positions, float centering, etc.; add automatic figure, table, and
  other similar references; add separate markup for html (role='html')
  and pdf (role='fo') image sizing and placement; remove unnecessary
  image markup; lift child namespaces to each document's root element.

  Particular targets for improvement:

    doc/docbook/presentations/en/brlcad-app-devel.xml
    doc/docbook/presentations/en/intro-to-tcltk.xml
    doc/docbook/specifications/en/BRL_CAD_g_format_V5.xml

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

* document the saveview/loadview options.

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

* 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

* BRL-CAD Taxonomy
	Description of the common terminology used throughout BRL-CAD,
	conventions employed, and tool categorization.

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

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