Re: how to fill in pixels

A new DisplayRealType for use in ConstantMaps for per
DataRenderer control of texture mapping, similar to
PointSize, LineWidth and LineStyle, would certainly be
useful. Something for the wish list.


On Thu, 22 Aug 2002, Don Murray wrote:

> Bill-
>
> This fixes the ArrayIndexOutOfBoundsException and now displays
> "blocky" images.  I'm not sure if this is good or bad since it
> effectively changes the look of all the color shaded images
> in our applications.  What used to be nice smooth color shading
> is now blocky.  Is there a way that the texture enabling can be
> done on a per DataReference basis rather than the entire display?
> For example, I might want some displays have nice smooth shading
> and others have the blocky appearance.  Could this be a new
> DisplayRealType (like how Curtis added line style, etc which used
> to be global) that could be added as a ConstantMap with a
> DataReference?
>
> Before and after pictures of 500 mb temperature can be found at:
>
> http://www.unidata.ucar.edu/staff/donm/visad/colorshades.html
>
> Don
>
> Bill Hibbard wrote:
>
>
> >>Using this new version of ShadowFunctionOrSetType, what once
> >>used to (sort of) work, now doesn't.  I'm using the
> >>Radar3DCoordinateSystem and now get an ArrayOutOfBoundsException:
> >>
> >>java.lang.ArrayIndexOutOfBoundsException
> >>         at
> >>ucar.visad.RadarGridCoordinateSystem.toReference(RadarGridCoordinateS
> >>ystem.java:91)
> >>         at
> >>visad.CachingCoordinateSystem.toReference(CachingCoordinateSystem.jav
> >>a:78)
> >>         at visad.CoordinateSystem.toReference(CoordinateSystem.java:525)
> >>         at
> >>visad.CoordinateSystem.transformCoordinatesFreeUnits(CoordinateSystem
> >>.java:360)
> >>         at
> >>visad.CoordinateSystem.transformCoordinatesFreeUnits(CoordinateSystem
> >>.java:500)
> >>         at
> >>visad.CoordinateSystem.transformCoordinates(CoordinateSystem.java:439
> >>)
> >>         at
> >>visad.ShadowFunctionOrSetType.doTransform(ShadowFunctionOrSetType.jav
> >>a:1240)
> >>         at
> >>visad.java3d.ShadowFunctionOrSetTypeJ3D.doTransform(ShadowFunctionOrS
> >>etTypeJ3D.java:100)
> >>         at
> >>visad.java3d.ShadowFunctionOrSetTypeJ3D.recurseRange(ShadowFunctionOr
> >>SetTypeJ3D.java:986)
> >>         at
> >>visad.ShadowFunctionOrSetType.doTransform(ShadowFunctionOrSetType.jav
> >>a:2914)
> >>         at
> >>visad.java3d.ShadowFunctionOrSetTypeJ3D.doTransform(ShadowFunctionOrS
> >>etTypeJ3D.java:100)
> >>         at
> >>visad.java3d.DefaultRendererJ3D.doTransform(DefaultRendererJ3D.java:9
> >>8)
> >>         at visad.java3d.RendererJ3D.doAction(RendererJ3D.java:177)
> >>         at visad.DisplayImpl.doAction(DisplayImpl.java:1504)
> >>         at visad.ActionImpl.run(ActionImpl.java:303)
> >>         at visad.util.ThreadPool$ThreadMinnow.run(ThreadPool.java:95)
> >>
> >>If I revert back to the previous version, it works fine (except
> >>for the textureMapping not working correctly). RadarGridCoordinateSystem
> >>is attached.  It looks like the 3 dimensional array it is expecting
> >>(lat, lon, elevation) is coming in as a 2 dimensional array (lat, lon)?
> >>
> >>I always wondered why the textureMapping didn't work for this data, so
> >>now I guess I know why.
> >>
> >
> > Oops, this problem is deeper than I thought. I have put a
> > possible fix at:
> >
> >   ftp://ftp.ssec.wisc.edu/pub/visad-2.0/untested/
> >
> > and also checked it into the CVS. Let me know if it works.
> >
> > Bill
> >
>
>
>