> I too am a VisAD user wannabe, and I personally applaud your efforts to
> document the VisAD toolkit.
Thanks, but I haven't done much yet. :)
> One question: Are you using the oct-tree approach to reduce memory, or some
> other reason?
The octree approach is ultimately aimed at reducing memory and processing
time. Since our polygon generation is done with the marching cubes
algorithm, and the MC algorithm spends anywhere from 30%-70% of its time
processing empty cubes, we're attempting to use the octree to eliminate
the unnecessary cube processing. Each node in the octree represents a
volume (a cube). The normal MC algorithm takes a brute force approach and
processes all of the cubes. By storing the cubes in an octree we can use
use the information stored in the internal nodes to skip over entire
branches, and hence volume(s), of cubes during processing. Hope this
makes some sense. It's a rather specialized topic.
Also, I have a few questions to add to the mailing list:
The Gridded3DSet.makeIsoSurface() method returns a
VisADTriangleStripArray. When looking at the code here, it's not obvious
how the array is populated. The MC algorithm generates triangles (only).
It would be great to add these triangles, perhaps 1 or more at a time, to
a VisADTriangleStripArray. However, it's not clear how this is done.
Should I be focusing on the merge() method? Perhaps creating many
VisADTriangleStripArrays and merging them together?
I'm also concerned about a few of the other methods that may be involved.
For example, the ShadowFunctionOrSetType.doTransform() and
ShadowType.assembleSpatial() methods are 2,146 lines and 495 lines (of
code) long respectively. Will I have to modify these?
P.S. Thanks to Bill Hibbard for answering my (many) questions so well.
Robert S Laramee tel: (603) 868-1361 (new as of 19 Jan '00)
9 Woodman Ave, #316 office: (603) 862-0350
Durham, NH 03828 URL: http://www.cs.unh.edu/~rlaramee