Hi Bob,
> Does this look like a semi-accurate collaboration graph for
> isosurface generation?:
>
> http://www.cs.unh.edu/~rlaramee/pictures/collaborationGraph.jpg
>
> Are there some holes here e.g. classes missing? Which ones? It helps me
> greatly if i have some sort of a software design to look at. Suggestions
> for improvement would be great!
Two things I notice:
1. 'new DataDisplayLink' is invoked directly in
DisplayImpl.addReference() and addReferences() - I'm not
sure DisplayRenderer enters into it.
2. ShadowType enters as the parent class of
ShadowFunctionOrSetType, rather than being constructed by
makeShadowRealType.
I am travelling and cannot give this diagram the attention
it deserves. Also, unfortunately, I will be out of email
contact for the next few days.
I think you can focus on extending Gridded3DSet, implementing
makeSpatial() and makeIsoSurface(), rather than digging too
deeply into ther diagram of Display classes. Two important
issues:
1. Note that makeSpatial() only has arguments for MathType
and float[][] samples. Your implementation should construct
a new Set of the same class, with the MathType, with null
Units, CoordinateSystems, etc, and assuming the same topology
as 'this',but with sample locations given by 'float[][] samples'.
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.
Cheers,
Bill
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html
