Revision: 52509
http://brlcad.svn.sourceforge.net/brlcad/?rev=52509&view=rev
Author: brlcad
Date: 2012-09-20 18:12:09 +0000 (Thu, 20 Sep 2012)
Log Message:
-----------
long thought that gqa should be calulating overlap volumes so cleanup work can
be better prioritized. plus, it'd remove a source of confusion. reminded of
the issue by banealis via help forum discussion.
Modified Paths:
--------------
brlcad/trunk/TODO
Modified: brlcad/trunk/TODO
===================================================================
--- brlcad/trunk/TODO 2012-09-20 01:57:19 UTC (rev 52508)
+++ brlcad/trunk/TODO 2012-09-20 18:12:09 UTC (rev 52509)
@@ -531,11 +531,37 @@
* improve compile-time version management -- port brlcad-version to
windows, reconsider providing compile-time header constants.
+* 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/g_qa -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.
+
+* g_qa (gqa in mged) 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.
+
+* refactor .density file and density database reading code in files
+ src/rt/viewweight.c, src/libged/analyze.c and src/libged/gqa.c into
+ common code in src/libanalyze (there may be more candidates around
+ the tree)
+
* 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
@@ -699,11 +725,6 @@
selection in the GUI, area-based selections, and object highlighting
- can replace unpublished 'sphgroup' command with this
-* 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)
-
* refactor the libtclcad go_*() functions and invocation wrappers
(also in mged) into libged where appropriate. the 'png' command
comes to mind.
@@ -746,15 +767,6 @@
* add support to 'rtxray' for outputting inverted pixel values so that
we have pixel values that are directly related to material thickness
-* 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.
-
-* g_qa (gqa in mged) 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.
-
* make color and vectors on pnts work
* mged inconsistently ignores signals. initially allowing mged to be
@@ -1258,11 +1270,6 @@
build tool and its (also experimental) CMake support are promising -
if/when CMake support goes mainstream, document that too.)
-* refactor .density file and density database reading code in files
- src/rt/viewweight.c, src/libged/analyze.c and src/libged/gqa.c into
- common code in src/libanalyze (there may be more candidates around
- the tree)
-
* look into embedding both rgb[3] and complex[n] data types in a union to
allow unification of libmultispectral and liboptical APIs to a single
more general liboptical. Need to be careful about performance and
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
