"Fossies" - the Fresh Open Source Software Archive

Member "brlcad-7.32.4/doc/notes/TODO.shaded_displays" (29 Jul 2021, 4623 Bytes) of package /linux/misc/brlcad-7.32.4.tar.bz2:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 Consolidated from an e-mail thread and several e-mail messages by Sean
    2 to the BRL-CAD developers list in Jun 2013 which includes this message:
    3 
    4 https://sourceforge.net/mailarchive/forum.php?thread_name=02c584af-d1ad-4d23-9837-1412eed14350%40me.com&forum_name=brlcad-devel
    5 
    6 > 4. Finally we will get rid of wireframes. However, we will be able
    7 >    to easily enable or disable shaded geometry or vice versa.
    8 
    9 We're not getting rid of wireframes.  Shaded display geometry becoming
   10 the default, however, is already planned and in the works.  NURBS
   11 surface-surface intersections (Wu's project) are required for that to
   12 happen.
   13 
   14 ...
   15 
   16 Making wireframes not be the default is one of several reasons why
   17 we've been working on NURBS infrastructure.  Not understanding why
   18 this is required given our representation format is usually an
   19 indication that someone does not yet understand the fundamental
   20 problem... which is not meant to be taken in a negative way.  MOST
   21 people don't have experience with our particular problem domain which
   22 is specific to having mathematically-based implicit geometry
   23 representations along with boolean operations.
   24 
   25 When most people say shaded display, they usually think of OpenGL,
   26 Direct3D, games, other modeling systems, etc.  Those systems are
   27 driven by polygons (triangles).  To have that style of shaded display,
   28 you have to have polygons.  We do not have polygons.  We do not have a
   29 robust method for getting polygons.  NURBS gives us a robust method.
   30 
   31 When we can 1) convert any geometry to NURBS, 2) evaluate any
   32 booleans, and 3) tessellate NURBS robustly, it will be possible to
   33 have robust shaded displays for all geometry.  #1 was finished last
   34 year primarily thanks to Cliff and Wu.  #3 was finished just this year
   35 primarily due to Keith.  Work on #2 is underway and is scheduled to be
   36 finished this year..
   37 
   38 It's been a while since I've had to succinctly describe the problem
   39 and solution, so hopefully that is all understandable to everyone.
   40 There are several independent tasks that will need to be completed is
   41 anyone wants to help us get there more quickly.  ;)
   42 
   43 ...
   44 
   45 > Sean, are those tasks grouped somewhere in the TODO list, or?
   46 
   47 Not in such a succinct form because there is a lot of interrelation
   48 with other tasks/projects.  E.g., one can frame reliable STEP NURBS
   49 import is just as important for shaded displays because users usually
   50 want to view their own existing data.  Or once we have robust boolean
   51 evaluation of NURBS, most of our converters will need to be updated to
   52 use the new method ... that's a lot of work. :)
   53 
   54 Some tasks that come to mind related to shaded displays are:
   55 
   56 * library routine for boolean evaluation of NURBS
   57 
   58 * library routine for non-solid NURBS tessellation (capability exists,
   59   but not as formal API)
   60 
   61 * library routine for solid NURBS tessellation (capability exists, but
   62   not as formal API)
   63 
   64 * libgcv routine to perform NURBS boolean evaluation and tessellation
   65 
   66 * connecting "facetize" command to use libgcv (solid tessellation)
   67 
   68 * migrate current converter polygonal mesh boolean evaluation method
   69   of NMG-based converters to libgcv
   70 
   71 * updating all NMG-based exporters to use new libgcv routine, retain
   72   old method as legacy option
   73 
   74 * updating mged/archer to utilize boolean evaluated NURBS as a
   75   visualization mode
   76 
   77 Other useful but maybe not strictly necessary tasks:
   78 
   79 * optimize NURBS prep
   80 
   81 * connecting "E" and "ev" commands to use libgcv (non-solid or solid)
   82 
   83 * implement support for plate-mode NURBS
   84 
   85 * update STEP and 3DM converters to support non-solid NURBS import via
   86   plate-mode
   87 
   88 * libgcv routine to perform NURBS healing (close near-solid NURBS
   89   geometries)
   90 
   91 * update NURBS importers to with option to perform healing on import
   92 
   93 * update NURBS ray tracing to perform reparameterization/healing
   94   during prep
   95 
   96 * update IGES importer to import NURBS directly
   97 
   98 * implement OBJ NURBS import support
   99 
  100 * parallelize single-object NURBS prep (particularly the surface tree
  101   building)
  102 
  103 * parallelize boolean evaluation of NURBS
  104 
  105 * parallelize NURBS tessellation
  106 
  107 * refactor libdm API to better support (polygonal,curve,point) display
  108   lists
  109 
  110 * refactor libdm implementation to re-encapsulate platform-specific
  111   logic (no #ifdefs in public headers)
  112 
  113 * review old bspline NURBS logic, integrate useful portions, then
  114   remove the rest
  115 
  116 * formally document our BREP/NURBS primitive, capabilities and
  117   limitations
  118 
  119 That's just off the top of my head.  There are undoubtedly other tasks
  120 involved but that's a partial list.  Some/many of them are already in
  121 the TODO file, but many are not yet.  Feel free to
  122 expand/incorporate/ignore. ;)