> I noticed that, but really didn't understand *why* that code was inside
> the Set classes. It seemed like an unintuitive place for it, as contour
> lines aren't what I would typically think about as a property for a Set.
Contouring algorithms derive the geometry and topology for
contour lines or surfaces from the sampling geometry and
topology of the field being contoured. Since Set classes
describe the sampling geometry and topology, they are the
natural place for contouring algorithms. For example, the
makeIsoSurface() and makeIsoLInes() methods have different
implementations for GriddedSets and IrregularSets, because
of their different kinds of topologies.
> Also, I don't really understand what's in ShadowFunctionType... I don't
> really understand why there are rendering methods in all of these
> things. It's clear that somehow, somewhere, there needs to be a code
> block to rebuild scene graphs when stuff happens like zooming stuff out,
> or something getting made visible etc, but I don't understand why it is
> that the FunctionType classes have anything to do with rendering - as I
> understood it they were used as validity checkers to go through the
> graph of Datas and Functions and so forth. I don't see how that's
> connected to actual rendering. Sorry if this is mentioned someplace, I'm
> just struggling with the learning curve, can't remember everything. It
> just seems odd that it's not all in one place.
The essential thing about VisAD, and the difference between it and
previous visualization systems, is the idea that it figures out
how to render data based on the tree-structured MathType and a
set of ScalarMaps from leaves of the tree (RealTypes and TextTypes).
This is a tricky problem, and it is solved via an algorithm that
recurses over the tree structure (via doTransform() calls in the
tree of ShadowTypes that "shadows" the MathType tree). It is made
even more complex by a software structure that can share the same
code for the algorithm between different graphics APIs (Java3D and
Java2D). This is discussed in the tutorial.
> > If you tell us what changes you have in mind, we can advise you
> > about the most important section of the tutorial, '1.2 How to
> > Avoid Writing Non-Default DataRenderers'. There may be a way to
> > do what you want with a CellImpl and a DisplayImpl, rather than
> > a custom DataRenderer.
>
> Okay, the user problem is that the contour lines look to jagged. They
> would like smoothed contour lines. Let's pretend we've already had the
> argument about whether this is scientifically valid :).
>
> I figured I could just interpolate my field to double-density as a "get
> out of jail free" card, but would like to investigate a less memory/cpu
> intensive option. Contour drawing is already heavy enough (I'm sure a
> good job has been done - I'm being a user here) without making it take
> longer than it needs to. If I can fix the problem by changing the
> contour line algorithm to produce curves rather than lines, then hooray.
Interpolating your Field to higher density would certainly be
an easier approach. But it would be computationally expensive
(how much more expensive than a smoothing contour algorithm
is hard to estimate).
> Doing a little research into contour algorithms (in 2d at least) the
> methods seemed fairly comprehensible insofar as I can sit down with a
> grid and a pencil and draw contour lines according to said algorithms.
> Now, in terms of efficient implementation I could be on shaky ground,
> but I'd like to introduce smoothed contour option - maybe by drawing a
> curve between the two points, based on previous line gradient or
> something like that.
In your override of makeContour(), you want to test for the
case(s) you care about and call super.makeContour(...) for
all other cases. To override makeIsoLines() would be tricky,
so you should instead replace the call to spatial_set.makeIsoLines()
with a call to a static method. You can write this method by
starting with a copy of Gridded3DSet.makeIsoLines() (even if
your data use a 2D Set, spatial_set is your sampling mapped
to 3-D graphics coordinates; note also I am assuming that you
are interested in the gridded rather than irregular case). In
your static method, you will need to replace occurences of
implicit 'this' with 'spatial_set'. The algorithm you want
to change is in Contour2D.contour(). Cut and paste a copy of
it into a new static method in your class, and modify to use
your smoothing contour algorithm.
I am not sure if there will be any complications because of
Tom's dynamic label logic.
Good luck,
Bill
