Revision: 55929
http://sourceforge.net/p/brlcad/code/55929
Author: tbrowder2
Date: 2013-07-02 16:18:17 +0000 (Tue, 02 Jul 2013)
Log Message:
-----------
save Sean's shaded display road map until a better location is found
Added Paths:
-----------
brlcad/trunk/TODO.shaded_displays
Added: brlcad/trunk/TODO.shaded_displays
===================================================================
--- brlcad/trunk/TODO.shaded_displays (rev 0)
+++ brlcad/trunk/TODO.shaded_displays 2013-07-02 16:18:17 UTC (rev 55929)
@@ -0,0 +1,122 @@
+Consolidated from an e-mail thread and several e-mail messages by Sean
+to the BRL-CAD developers list in Jun 2013 which includes this message:
+
+https://sourceforge.net/mailarchive/forum.php?thread_name=02c584af-d1ad-4d23-9837-1412eed14350%40me.com&forum_name=brlcad-devel
+
+> 4. Finally we will get rid of wireframes. However, we will be able
+> to easily enable or disable shaded geometry or vice versa.
+
+We're not getting rid of wireframes. Shaded display geometry becoming
+the default, however, is already planned and in the works. NURBS
+surface-surface intersections (Wu's project) are required for that to
+happen.
+
+...
+
+Making wireframes not be the default is one of several reasons why
+we've been working on NURBS infrastructure. Not understanding why
+this is required given our representation format is usually an
+indication that someone does not yet understand the fundamental
+problem... which is not meant to be taken in a negative way. MOST
+people don't have experience with our particular problem domain which
+is specific to having mathematically-based implicit geometry
+representations along with boolean operations.
+
+When most people say shaded display, they usually think of OpenGL,
+Direct3D, games, other modeling systems, etc. Those systems are
+driven by polygons (triangles). To have that style of shaded display,
+you have to have polygons. We do not have polygons. We do not have a
+robust method for getting polygons. NURBS gives us a robust method.
+
+When we can 1) convert any geometry to NURBS, 2) evaluate any
+booleans, and 3) tessellate NURBS robustly, it will be possible to
+have robust shaded displays for all geometry. #1 was finished last
+year primarily thanks to Cliff and Wu. #3 was finished just this year
+primarily due to Keith. Work on #2 is underway and is scheduled to be
+finished this year..
+
+It's been a while since I've had to succinctly describe the problem
+and solution, so hopefully that is all understandable to everyone.
+There are several independent tasks that will need to be completed is
+anyone wants to help us get there more quickly. ;)
+
+...
+
+> Sean, are those tasks grouped somewhere in the TODO list, or?
+
+Not in such a succinct form because there is a lot of interrelation
+with other tasks/projects. E.g., one can frame reliable STEP NURBS
+import is just as important for shaded displays because users usually
+want to view their own existing data. Or once we have robust boolean
+evaluation of NURBS, most of our converters will need to be updated to
+use the new method ... that's a lot of work. :)
+
+Some tasks that come to mind related to shaded displays are:
+
+* library routine for boolean evaluation of NURBS
+
+* library routine for non-solid NURBS tessellation (capability exists,
+ but not as formal API)
+
+* library routine for solid NURBS tessellation (capability exists, but
+ not as formal API)
+
+* libgcv routine to perform NURBS boolean evaluation and tessellation
+
+* connecting "facetize" command to use libgcv (solid tessellation)
+
+* migrate current converter polygonal mesh boolean evaluation method
+ of NMG-based converters to libgcv
+
+* updating all NMG-based exporters to use new libgcv routine, retain
+ old method as legacy option
+
+* updating mged/archer to utilize boolean evaluated NURBS as a
+ visualization mode
+
+Other useful but maybe not strictly necessary tasks:
+
+* optimize NURBS prep
+
+* connecting "E" and "ev" commands to use libgcv (non-solid or solid)
+
+* implement support for plate-mode NURBS
+
+* update STEP and 3DM converters to support non-solid NURBS import via
+ plate-mode
+
+* libgcv routine to perform NURBS healing (close near-solid NURBS
+ geometries)
+
+* update NURBS importers to with option to perform healing on import
+
+* update NURBS ray tracing to perform reparameterization/healing
+ during prep
+
+* update IGES importer to import NURBS directly
+
+* implement OBJ NURBS import support
+
+* parallelize single-object NURBS prep (particularly the surface tree
+ building)
+
+* parallelize boolean evaluation of NURBS
+
+* parallelize NURBS tessellation
+
+* refactor libdm API to better support (polygonal,curve,point) display
+ lists
+
+* refactor libdm implementation to re-encapsulate platform-specific
+ logic (no #ifdefs in public headers)
+
+* review old bspline NURBS logic, integrate useful portions, then
+ remove the rest
+
+* formally document our BREP/NURBS primitive, capabilities and
+ limitations
+
+That's just off the top of my head. There are undoubtedly other tasks
+involved but that's a partial list. Some/many of them are already in
+the TODO file, but many are not yet. Feel free to
+expand/incorporate/ignore. ;)
Property changes on: brlcad/trunk/TODO.shaded_displays
___________________________________________________________________
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
