NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Ooops, replied only to
Bill. Here's it again
for the list.
From:
Tennessee
James
Leeuwenburg
<tjl@xxxxxxxxxx>
To:
Bill Hibbard
<billh@xxxxxxxxxxxxx>
Subject:
Re: Custom
data
renderer /
shadowtype
Date:
Tue, 06 Apr
2004
14:40:11
+1000
> Yes, your DataRenderer extension would override
makeShadowFunctionType()
> to construct and return your extension of ShadowFunctionTypeJ3D. It
> would override the makeContour() method. I think you could start with
> a cut and paste of the implementation in visad.ShadowType (you might
> want to test with that literal cut and paste to see if that has any
> problems). Then figure out what contour cases (e.g. 2-D or 3-D) you
want
> to change, look for the appropriate code section in makeContour(), and
> modify. It calls methods of Set classes like makeIsoSurface() and
> makeIsoLines() to actually compute the geometries (line and
triangles),
> and then add them to the scene graph ('Object group') via calls to
> addToGroup().
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.
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.
> 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.
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.
Cheers,
-T
visad archives: