Ken,
> I tried using contours as in Test 37 as you suggested. In that example I am
> not sure what the FlatField.fillField() is supposed to be doing. (There is
> no Javadoc, and I didn't understand the code, or at least its purpose, with
> a moderate amount of effort.)
fillField() appears to be sort of an internal helper
method, for filling FlatField ranges with random values
for testing purposes. No use to real applications.
> Based on that example, I used the mapping:
>
> ((col, row, intensity) -> data)
>
> with the maps:
>
> ScalarMap colMap = new ScalarMap(colType, Display.XAxis);
> ScalarMap rowMap = new ScalarMap(rowType, Display.YAxis);
> ScalarMap funcMap = new ScalarMap(intensityType, Display.ZAxis);
> ScalarMap rgbMap = new ScalarMap(intensityType, Display.RGB);
> ScalarMap conMap = new ScalarMap(intensityType, Display.IsoContour);
>
> This gives the results attached, one with the conMap and the other without.
> I note:
>
> 1. data is not used and it doesn't make any difference what it is -- all
> zeros or using FlatField.fillField(). Thus, the mapping is somewhat
> meaningless. It is all done in the domain.
Yes, if data is not involved in any ScalarMaps it
will not have any affect on the display.
> 2. Without the conMap the results are the same as for gmc.setCurvedSize(0)
> in my original case. That is, there is shading, and the colors are at a
> consistent height anyway. Setting gmc.setCurvedSize(n) makes no difference
> this time, nor does setTextureEnable(true) (unless I have made a mistake).
>
> 3. With conMap, there is shading *and* distinct contours. These are
> (almost) all at a consistent height. There are a couple points with the
> wrong colors. The basic difference is that the colors are in bands, rather
> than continuously varying. I also always get shading.
This sounds like what you should expect.
> 4. The time and memory requirements make this mode completely impractical
> for my images, which run 2048x2048 or higher.
Oh yeah. Rather than rendering directly from data to
the screen, VisAD produces intermediate geometries
and textures for interactive rendering via Java3D.
The use of sub-sampled geometry with textures maps
is intended to reduce the size of these intermediate
structures. But when you need the full resultion of
your data in the display, they can get very large.
Also, the bleeding of colors vertically that you are
trying to avoid is an artifact of the approximate
interpolation that 3-D rendering uses. In a way these
artifacts give users some important information: that
the data resolution is lower than screen resolution
and so the detail in the display is interpolation
rather than actual data.
> I also did essentially the same thing using:
>
> ((col, row) -> intensity)
>
> using the same maps as above. This is more sensible for what I am doing.
>
> The results look and behave the same. I haven't been able to get it to use
> texture. Consequently, it is too slow and memory intensive to be practical
> for my uses. It does 50x50 plots reasonably fast and with reasonable
> memory, though.
>
> I should note that the contour calculation itself is time consuming for this
> random data. With smooth data and not using FILL, displaying 3D contontours
> is reasonably fast. Thus there are two problems -- contour calculation and
> rendering.
>
> Thus, so far I have fast with inconsistent height vs. color or slow and
> memory intensive with reasonable (but not perfect) height vs. color
> consistency.
This tradeoff sounds about right. For most applications,
this tradeoff isn't such a big problem. But in your case
I'm afraid this is about the best we can do. VisAD does
enable people to write custom DataRenderers, to come up
with clever solutions for special cases. But of course
that involves difficult programming.
Good luck,
Bill
==============================================================================
To unsubscribe visad, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
