Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hi Bill,
> 2. There is a question about how the topology of the octree
> or multi-resolution Set works. Are only the high-resolution
> samples passed in 'float[][] samples', with lower resolutions
> derived? In this case, dependent variable values in Field
> ranges also must have their low-resolution values implicit
> from high-resolution values. An alternative is to include
> both low and high-resolution samples in the 'float[][] samples'
> array, and to make appropriate implementations of topology in
> various Set methods. One easy way to handle indexToValue(),
> valueToIndex(), valueToInterp(), etc would be to include an
> instance variable of a Gridded3DSet that corresponds only to
> the high-resolution samples, and to adapt the methods to this
> instance Gridded3DSet. In a multi-resolution grid where the
> various resolutions apply to non-overlapping regions, you
> could interpret the low and high resolution samples as defining
> a slightly irregular topology corase in some regions and fine
> in others. In the case where they do overlap, it all depends
> on how you want makeIsoSurface() and other methods to behave.
> You could even compute several different versions of the iso-
> surface, and choose the one to display based on how "close"
> the viewer is using a ControlListerner on ProjectionControl -
> doing this would require digging into the display classes and
> I can help more when I return from travel.
These are very good questions you brought up. We are trying to figure out
how to extend your (great) application with our multi-resolution piece.
Our current multi-resolution (MR) implementation is comprised of the
following:
1. A C program that reads the raw data (density) values, i.e. the output
from the CAT scan (http://www.cs.unh.edu/~rlaramee/pictures/head2.jpg)
a outputs an MR representation of the data in the form of cubes.
So, if the raw data set is
128 x 128 x 128 data values, this programs outputs:
128 x 128 x 128 cubes with each cube vertex taking on a data value
64 x 64 x 64 cubes -a coarser resolution representation
32 x 32 x 32 cubes
16 x 16 x 16 cubes
...
1 x 1 x 1 one cube that represents the entire volume
The output is written to a file -a bunch of cubes.
2. Another C program that reads in the output from program (1) and
generates an adaptive resolution (AR) representation of the MR
representation from program (1). This part I haven't mentioned yet.
Essentially, what it does is a search of the MR representation
stored as an octree, and looks for branches of the octree to chop
away. Each cube of the octree stores the minimum and maximum
scalar values of its 8 children (for internal, non-leaf nodes) or 8
vertices (for leaf nodes). If the difference between these
values is less than some arbitrary threshold that we set, the
branch is chopped off. In this way, we can generate an AR
representation of the MR representation in (1).
Again, the output is written to a file -a bunch of cubes. These first
2 programs were written a few years ago by a colleague of mine.
Program 3 is mostly where my job came in.
3. A Java program that reads the output from either program (1) or (2),
a whole bunch of cubes, recreates the octree (MR or AR) and renderers
the tree (just the leaf nodes). It just does a depth-first-search
of the octree and renders each cube using the marching cubes
algorithm.
And now we're scratching our heads on how we're going to add our stuff to
yours. You pointed out a key point in that the
Gridded3DSet.makeIsoSurface() method takes a set of floats. This is
something we're going to have to think about. At this stage, we're still
trying to figure out how your application works. I'm trying to update the
collaboration graph
(http://www.cs.unh.edu/~rlaramee/pictures/collaborationGraph.jpg) but it's
still fuzzy. One area that is still fuzzy is the call to
ShadowFunctionOrSetType3D.doTransform(). Where is this method called
from? Also the link between the ContourWidget and the Cell computation is
still unclear to me. Does anyone know which class relates those? Thank
you for you time.
-cheers, bob
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
visad archives: