Revision: 56025
http://sourceforge.net/p/brlcad/code/56025
Author: brlcad
Date: 2013-07-12 16:53:43 +0000 (Fri, 12 Jul 2013)
Log Message:
-----------
move shaded-display todo into doc/ subdir with the other existing todo.brep and
reference where it's at in the main TODO file.
Modified Paths:
--------------
brlcad/trunk/CMakeLists.txt
brlcad/trunk/TODO
brlcad/trunk/doc/CMakeLists.txt
Added Paths:
-----------
brlcad/trunk/doc/TODO.shaded_displays
Removed Paths:
-------------
brlcad/trunk/TODO.shaded_displays
Modified: brlcad/trunk/CMakeLists.txt
===================================================================
--- brlcad/trunk/CMakeLists.txt 2013-07-12 16:30:36 UTC (rev 56024)
+++ brlcad/trunk/CMakeLists.txt 2013-07-12 16:53:43 UTC (rev 56025)
@@ -2194,7 +2194,6 @@
BUGS
ChangeLog
TODO
- TODO.shaded_displays
configure
CMakeLists.txt
)
Modified: brlcad/trunk/TODO
===================================================================
--- brlcad/trunk/TODO 2013-07-12 16:30:36 UTC (rev 56024)
+++ brlcad/trunk/TODO 2013-07-12 16:53:43 UTC (rev 56025)
@@ -972,6 +972,12 @@
in BRL-CAD (libraries are BSD licensed: http://ngplant.sourceforge.net)
+SHADED DISPLAYS
+---------------
+
+* See doc/TODO.shaded_displays
+
+
ARCHER
------
Deleted: brlcad/trunk/TODO.shaded_displays
===================================================================
--- brlcad/trunk/TODO.shaded_displays 2013-07-12 16:30:36 UTC (rev 56024)
+++ brlcad/trunk/TODO.shaded_displays 2013-07-12 16:53:43 UTC (rev 56025)
@@ -1,122 +0,0 @@
-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. ;)
Modified: brlcad/trunk/doc/CMakeLists.txt
===================================================================
--- brlcad/trunk/doc/CMakeLists.txt 2013-07-12 16:30:36 UTC (rev 56024)
+++ brlcad/trunk/doc/CMakeLists.txt 2013-07-12 16:53:43 UTC (rev 56025)
@@ -19,6 +19,7 @@
README.VAX
README.Windows
TODO.BREP
+ TODO.shaded_displays
anim.txt
archer_ack.txt
benchmark.tr
Copied: brlcad/trunk/doc/TODO.shaded_displays (from rev 56023,
brlcad/trunk/TODO.shaded_displays)
===================================================================
--- brlcad/trunk/doc/TODO.shaded_displays (rev 0)
+++ brlcad/trunk/doc/TODO.shaded_displays 2013-07-12 16:53:43 UTC (rev
56025)
@@ -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. ;)
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
