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.
Allen P. Hild Lockheed Martin PH: 303.977.7147 PG: 888.307.4688 allen.hild@xxxxxxxx Major e longinquo reverentia - Tacitus -----Original Message----- From: owner-visaddigest@xxxxxxxxxxxxxxxx [mailto:owner-visaddigest@xxxxxxxxxxxxxxxx] Sent: Monday, November 21, 2005 9:25 PM To: visaddigest@xxxxxxxxxxxxxxxx Subject: visaddigest V1 #261 visaddigest Monday, November 21 2005 Volume 01 : Number 261 ---------------------------------------------------------------------- Date: Mon, 21 Nov 2005 09:25:11 +0100 From: Ugo Taddei <taddei@xxxxxxxxxx> Subject: Re: The random colour changing bug Hello, Andrew Donaldson wrote: > Hi, > > For some time many of us here at the Bureau of Meteorology have > been aware of our VisAD apps changing colour for an unknown reason. > I vaguely recall showing this to Bill when he last visited, but I > am uncertain of this. > > It has recently become a problem, with some of our operational people > wanting to choose specific colours, only to have them changed by > our applications. > > On every computer we have tried it on (including Linux nvidia, windows > opengl and windows directx) the fault occurs. > > Attached is a simple program which displays a yellow box. If you click > with your middle mouse button, the yellow box becomes darker. I've seen this too and reported on: http://www.unidata.ucar.edu/cgi-bin/getfile?file=/content/support/help/M ailArchives/visad-list/msg05512.html (see also other emails on the same thread) but dismissed because I thought it had to do with other native j3D objects I was adding to the display (via dispRendenerer.getTrans().addChild()) Cheers, Ugo > This > thought to be the same problem that our applications have. The sample > program does not have any code to respond to a mouse button or change > colours. > > Any help would be very greatly appreciated. > > I think we first need to work out if the problem is with java3d or > VisAD. I don't have a good understanding of all the things that happen > when the middle mouse button is pressed, hopefully someone else can > add to this! > > thanks, > > Andrew. > > > >----------------------------------------------------------------------- - > >import java.awt.*; >import java.awt.event.*; >import javax.swing.*; >import java.net.URL; >import java.rmi.RemoteException; >import visad.*; >import visad.bom.*; >import visad.java3d.*; > >public class ColourBug >{ > private DataReferenceImpl dataReference; > > public ColourBug() > throws Exception > { > DisplayImplJ3D display; > ScalarMap latMap, lonMap; > > visad.java3d.DisplayRendererJ3D displayRenderer > new TwoDDisplayRendererJ3D(); > display = new DisplayImplJ3D("display", displayRenderer); > > lonMap = new ScalarMap(RealType.Longitude, Display.XAxis); > latMap = new ScalarMap(RealType.Latitude, Display.YAxis); > display.addMap(latMap); > display.addMap(lonMap); > > RealType pixel = RealType.getRealType("PIXEL"); > > FunctionType functionType = new FunctionType( > RealTupleType.LatitudeLongitudeTuple, pixel); > Set domainSet = new Integer2DSet( > RealTupleType.LatitudeLongitudeTuple, 2, 2); > > float[][] flat_samples = new float[1][2*2]; > flat_samples[0][0] = 1; > flat_samples[0][1] = 1; > flat_samples[0][2] = 1; > flat_samples[0][3] = 1; > > FlatField vals_ff = new FlatField(functionType, domainSet); > vals_ff.setSamples(flat_samples); > > DataReferenceImpl data_ref = new DataReferenceImpl("data_ref"); > data_ref.setData(vals_ff); > > Color colour = new Color(254,240,179); > ConstantMap[] colourConstantMap = new ConstantMap[3]; > colourConstantMap[0] = new ConstantMap(colour.getRed()/255.0f, > Display.Red); > colourConstantMap[1] = new ConstantMap(colour.getGreen()/255.0f, > Display.Green); > colourConstantMap[2] = new ConstantMap(colour.getBlue()/255.0f, > Display.Blue); > > display.addReference(data_ref, colourConstantMap); > > // Swing stuff > JFrame frame = new JFrame("ColourBug example program"); > frame.getContentPane().add(display.getComponent()); > > frame.setSize(500, 500); > frame.setVisible(true); > } > > public static void main(String[] args) > throws Exception > { > new ColourBug(); > } >} > > > - -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 184960 fax ++49 +228 1849629 http://www.lat-lon.de http://www.deegree.org ------------------------------ Date: Mon, 21 Nov 2005 05:35:28 -0600 (CST) From: Bill Hibbard <billh@xxxxxxxxxxxxx> Subject: Re: The random colour changing bug Hi Andrew, Thanks for the test program. Unfortunately, it does not cause any color change on my home machine (a laptop running Windows NT, JDK 1.2 and some ancient version of Java3D). I looked at the mailing list thread that Ugo recommended (thanks Ugo) and it seems at the time we thought it might be related to ambient light being turned off, and were very puzzled how this could happen. Clearly your test program is not accessing its Java3D scene graph, so that hypothesis is out. Next time I'm in the office I'll try your test program on my office machine (running more recent versions of Java and Java3D). Do any other Wisconsin folks see the color change running Andrew's test program? Its hard to imagine how VisAD is doing this, but of course it isn't impossible. It may be useful to inquire on the Java3D list whether this is a known Java3D bug. Cheers, Bill On Mon, 21 Nov 2005, Andrew Donaldson wrote: > Hi, > > For some time many of us here at the Bureau of Meteorology have > been aware of our VisAD apps changing colour for an unknown reason. > I vaguely recall showing this to Bill when he last visited, but I > am uncertain of this. > > It has recently become a problem, with some of our operational people > wanting to choose specific colours, only to have them changed by > our applications. > > On every computer we have tried it on (including Linux nvidia, windows > opengl and windows directx) the fault occurs. > > Attached is a simple program which displays a yellow box. If you click > with your middle mouse button, the yellow box becomes darker. This > thought to be the same problem that our applications have. The sample > program does not have any code to respond to a mouse button or change > colours. > > Any help would be very greatly appreciated. > > I think we first need to work out if the problem is with java3d or > VisAD. I don't have a good understanding of all the things that happen > when the middle mouse button is pressed, hopefully someone else can > add to this! > > thanks, > > Andrew. ------------------------------ Date: Mon, 21 Nov 2005 11:23:21 -0600 From: Curtis Rueden <ctrueden@xxxxxxxx> Subject: Re: The random colour changing bug Hi, >Do any other Wisconsin folks see the >color change running Andrew's test program? > > I tried it on my machine (Linux running Java 1.4.2_09 and Java3D 1.3.1 with an nVidia graphics card), and saw the bug. The yellow box gets slightly darker once the middle button is pressed and the cursor is moved at all. I tried a few other tests. The problem occurs regardless of texture mapping on or off. It does not occur with Java2D, or with a color mapping to RGB instead of ConstantMaps to Red, Green and Blue. I've included a modified version of the test program that uses a mapping to Display.RGB to avoid the problem. Bill, any ideas how I could continue investigating this issue? I can just dig into the ConstantMap logic, since that seems likely. The fact that you aren't seeing the problem on your machine suggests that it's either specific to newer versions of Java3D, or dependent on graphics card hardware. - -Curtis - ----- import java.awt.*; import javax.swing.*; import visad.*; //import visad.java2d.DisplayImplJ2D; import visad.java3d.*; public class ColourBug { private DataReferenceImpl dataReference; public ColourBug() throws Exception { DisplayImpl display; ScalarMap latMap, lonMap; DisplayRendererJ3D displayRenderer = new TwoDDisplayRendererJ3D(); display = new DisplayImplJ3D("display", displayRenderer); //display = new DisplayImplJ2D("display"); RealType pixel = RealType.getRealType("PIXEL"); lonMap = new ScalarMap(RealType.Longitude, Display.XAxis); latMap = new ScalarMap(RealType.Latitude, Display.YAxis); ScalarMap pixelMap = new ScalarMap(pixel, Display.RGB); // CTR FunctionType functionType = new FunctionType( RealTupleType.LatitudeLongitudeTuple, pixel); Set domainSet = new Integer2DSet( RealTupleType.LatitudeLongitudeTuple, 2, 2); float[][] flatSamples = new float[1][2*2]; flatSamples[0][0] = 1; flatSamples[0][1] = 1; flatSamples[0][2] = 1; flatSamples[0][3] = 1; FlatField ffVals = new FlatField(functionType, domainSet); ffVals.setSamples(flatSamples); DataReferenceImpl dataRef = new DataReferenceImpl("dataRef"); dataRef.setData(ffVals); display.addMap(lonMap); display.addMap(latMap); display.addMap(pixelMap); // CTR // CTR - Why are the ranges -0.5 to 1.5, and why don't they autoscale? // Is this another bug? It doesn't happen with color ConstantMaps. lonMap.setRange(-0.5, 1.5); latMap.setRange(-0.5, 1.5); Color colour = new Color(254,240,179); /* CTR ConstantMap[] colourConstantMap = new ConstantMap[3]; colourConstantMap[0] = new ConstantMap(colour.getRed()/255.0f, Display.Red); colourConstantMap[1] = new ConstantMap(colour.getGreen()/255.0f, Display.Green); colourConstantMap[2] = new ConstantMap(colour.getBlue()/255.0f, Display.Blue); */ ColorControl cc = (ColorControl) pixelMap.getControl(); float[][] table = cc.getTable(); int numColors = table[0].length; table[0][numColors / 2] = colour.getRed()/255.0f; table[1][numColors / 2] = colour.getGreen()/255.0f; table[2][numColors / 2] = colour.getBlue()/255.0f; //java.util.Arrays.fill(table[0], colour.getRed()/255.0f); //java.util.Arrays.fill(table[1], colour.getGreen()/255.0f); //java.util.Arrays.fill(table[2], colour.getBlue()/255.0f); cc.setTable(table); //display.getGraphicsModeControl().setScaleEnable(true); //display.getGraphicsModeControl().setTextureEnable(false); display.addReference(dataRef/*, colourConstantMap*/); // Swing stuff JFrame frame = new JFrame("ColourBug example program"); frame.getContentPane().add(display.getComponent()); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(500, 500); frame.setVisible(true); } public static void main(String[] args) throws Exception { new ColourBug(); } } ------------------------------ Date: Mon, 21 Nov 2005 11:32:48 -0600 (CST) From: Bill Hibbard <billh@xxxxxxxxxxxxx> Subject: Re: The random colour changing bug Hi Andrew, I found one little bit of dumbness in the AmbientLight: the BoundingSphere is created with a radius of 2000000.0 (looks like a throwback to McIDAS and Vis5D). You might experiment with changing: BoundingSphere bounds new BoundingSphere(new Point3d(0.0,0.0,0.0), 2000000.0); to: BoundingSphere bounds new BoundingSphere(new Point3d(0.0,0.0,0.0), Double.MAX_VALUE); or: BoundingSphere bounds new BoundingSphere(new Point3d(0.0,0.0,0.0), Double.POSITIVE_INFINITY); in the createSceneGraph() method of visad/java3d/DefaultDisplayRendererJ3D.java. Please let us know if either change solves your problem. I doubt either will fix the problem because your test program should be well within the 2000000.0 radius of the current BoundingSphere, but nothing about this problem makes sense so its worth a try. Cheers, Bill ------------------------------ Date: Mon, 21 Nov 2005 12:27:57 -0600 (CST) From: Bill Hibbard <billh@xxxxxxxxxxxxx> Subject: Re: The random colour changing bug Hi Curtis, > I tried it on my machine (Linux running Java 1.4.2_09 and Java3D 1.3.1 > with an nVidia graphics card), and saw the bug. The yellow box gets > slightly darker once the middle button is pressed and the cursor is > moved at all. > > I tried a few other tests. The problem occurs regardless of texture > mapping on or off. It does not occur with Java2D, or with a color > mapping to RGB instead of ConstantMaps to Red, Green and Blue. I've > included a modified version of the test program that uses a mapping to > Display.RGB to avoid the problem. Thanks for these experiments. It sounds like a Java3DD problem, but one that we may be able to avoid by some small change. > Bill, any ideas how I could continue investigating this issue? I can > just dig into the ConstantMap logic, since that seems likely. The fact > that you aren't seeing the problem on your machine suggests that it's > either specific to newer versions of Java3D, or dependent on graphics > card hardware. You might try my Bounds suggestion, but I doubt that will fix the problem. I used your modified version of Andrew's test program to see if there were any differences in the calls to staticMakeAppearance() in visad/java3d/ShadowTypeJ3D.java between the ConstantMap to color and the ScalarMap to RGB. But as far as I could tell, in both cases the ColoringAttributes argument was null, the TransparencyAttributes argument was generated from alpha = 0.0, and no_material was false. I guess the thing to do is to determine what could be different between the ConstantMap case and the ScalarMap to RGB case, in either the GeometryArray or the Appearance. Cheers, Bill ------------------------------ Date: Mon, 21 Nov 2005 12:34:05 -0600 (CST) From: Bill Hibbard <billh@xxxxxxxxxxxxx> Subject: Re: The random colour changing bug On Mon, 21 Nov 2005, Bill Hibbard wrote: > Do any other Wisconsin folks see the > color change running Andrew's test program? Tom Rink reports that he doesn't see the problem using Andrew's test program, running Java3D 1.3.2 on a Linux box with an nVidia card. This is sounding more and more like a graphics card dependent problem. But we may be able to find a way to avoid triggering the problem. Bill ------------------------------ Date: Mon, 21 Nov 2005 13:15:47 -0700 From: Don Murray <dmurray@xxxxxxxxxxxxxxxx> Subject: Re: The random colour changing bug Bill- I don't have the problem on my IBM Laptop with ATI Radeon Mobility card. I'm guessing it's a driver/OpenGL issue. Don Bill Hibbard wrote: > On Mon, 21 Nov 2005, Bill Hibbard wrote: > > >>Do any other Wisconsin folks see the >>color change running Andrew's test program? > > > Tom Rink reports that he doesn't see the problem using > Andrew's test program, running Java3D 1.3.2 on a Linux > box with an nVidia card. > > This is sounding more and more like a graphics card > dependent problem. But we may be able to find a way to > avoid triggering the problem. > > Bill - -- ************************************************************* Don Murray UCAR Unidata Program dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm "Time makes everyone interesting, even YOU!" ************************************************************* ------------------------------ Date: Tue, 22 Nov 2005 11:14:46 +1100 From: Andrew Donaldson <A.Donaldson@xxxxxxxxxx> Subject: Re: The random colour changing bug Hi Bill and others, Thanks for having a look at this. I tried changing the BoundingSphere to MAX_VALUE, POSITIVE_INFINITY, - -1.0, 0.0 and 1.0, all of which produced no noticeable difference. We have also now tested on: - - Windows 2000, Matrix G450, Java 1.4.2_05, Java3D 1.3.1 OpenGL - - RedHat Enterprise WS4, ATI Radeon X600, Java 1.4.2_09, Java3D 1.3.1 which also produce the fault. Our previous testing was all with Nvidia cards, all of which had the fault. It is good to see it happening with Nvidia, ATI and Matrox OpenGL implementations on both windows and linux. This problem is affecting our production of Tropical Cyclone warning graphics, which can be issued at any time now that we are in the cyclone season here. Any help fixing it is appreciated. I will look into what is involved in removing the scalar maps, I expect it won't be fun :) thanks, Andrew. Bill Hibbard wrote: > Hi Andrew, > > I found one little bit of dumbness in the AmbientLight: > the BoundingSphere is created with a radius of 2000000.0 > (looks like a throwback to McIDAS and Vis5D). You might > experiment with changing: > > BoundingSphere bounds > new BoundingSphere(new Point3d(0.0,0.0,0.0), 2000000.0); > > to: > > BoundingSphere bounds > new BoundingSphere(new Point3d(0.0,0.0,0.0), Double.MAX_VALUE); > > or: > > BoundingSphere bounds > new BoundingSphere(new Point3d(0.0,0.0,0.0), Double.POSITIVE_INFINITY); > > in the createSceneGraph() method of > visad/java3d/DefaultDisplayRendererJ3D.java. > > Please let us know if either change solves your problem. > I doubt either will fix the problem because your test > program should be well within the 2000000.0 radius of the > current BoundingSphere, but nothing about this problem > makes sense so its worth a try. > > Cheers, > Bill ------------------------------ Date: Mon, 21 Nov 2005 19:31:06 -0600 (CST) From: Bill Hibbard <billh@xxxxxxxxxxxxx> Subject: Re: The random colour changing bug Hi Andrew, > I tried changing the BoundingSphere to MAX_VALUE, POSITIVE_INFINITY, > -1.0, 0.0 and 1.0, all of which produced no noticeable difference. Too bad, but that's what I figured. > We have also now tested on: > - Windows 2000, Matrix G450, Java 1.4.2_05, Java3D 1.3.1 OpenGL > - RedHat Enterprise WS4, ATI Radeon X600, Java 1.4.2_09, Java3D 1.3.1 > which also produce the fault. > > Our previous testing was all with Nvidia cards, all of which had the > fault. > > It is good to see it happening with Nvidia, ATI and Matrox OpenGL > implementations on both windows and linux. Yes, but remember we have seen an absence of the problem on a variety of systems: my Windows NT, JDK 1.2, ATI Rage graphics Don Murray's IBM Laptop with ATI Radeon Mobility (Linux?) Tom Rink's Java3D 1.3.2 on a Linux box with an nVidia card As Don says, its probably related to the OpenGL driver. > This problem is affecting our production of Tropical Cyclone > warning graphics, which can be issued at any time now that we are in > the cyclone season here. Any help fixing it is appreciated. Very sorry to hera about that. > I will look into what is involved in removing the scalar maps, > I expect it won't be fun :) Yes, I think Curtis's observation that it occurs with ConstantMaps but not with ScalarMaps to RGB may be a key to finding a work-around. There must be some difference between the GeometryArray or Appearance produced for these two cases. I dug into this a bit but didn't find the difference. I recall that you had some folks at BOM who could dig into this Java3D level of stuff. Please keep us informed and we will try to advise. Cheers, Bill ------------------------------ Date: Mon, 21 Nov 2005 19:40:07 -0600 From: Thomas D Rink <rink@xxxxxxxxxxxxx> Subject: Re: The random colour changing bug Hi Andrew, Give Java3D 1.3.2 a try: https://java3d.dev.java.net/ Tom Andrew Donaldson wrote: > Hi Bill and others, > > Thanks for having a look at this. > > I tried changing the BoundingSphere to MAX_VALUE, POSITIVE_INFINITY, > -1.0, 0.0 and 1.0, all of which produced no noticeable difference. > > We have also now tested on: > - Windows 2000, Matrix G450, Java 1.4.2_05, Java3D 1.3.1 OpenGL > - RedHat Enterprise WS4, ATI Radeon X600, Java 1.4.2_09, Java3D 1.3.1 > which also produce the fault. > > Our previous testing was all with Nvidia cards, all of which had the > fault. > > It is good to see it happening with Nvidia, ATI and Matrox OpenGL > implementations on both windows and linux. > > This problem is affecting our production of Tropical Cyclone > warning graphics, which can be issued at any time now that we are in > the cyclone season here. Any help fixing it is appreciated. > > I will look into what is involved in removing the scalar maps, > I expect it won't be fun :) > > thanks, > > Andrew. > > > Bill Hibbard wrote: > >> Hi Andrew, >> >> I found one little bit of dumbness in the AmbientLight: >> the BoundingSphere is created with a radius of 2000000.0 >> (looks like a throwback to McIDAS and Vis5D). You might >> experiment with changing: >> >> BoundingSphere bounds >> new BoundingSphere(new Point3d(0.0,0.0,0.0), 2000000.0); >> >> to: >> >> BoundingSphere bounds >> new BoundingSphere(new Point3d(0.0,0.0,0.0), Double.MAX_VALUE); >> >> or: >> >> BoundingSphere bounds >> new BoundingSphere(new Point3d(0.0,0.0,0.0), >> Double.POSITIVE_INFINITY); >> >> in the createSceneGraph() method of >> visad/java3d/DefaultDisplayRendererJ3D.java. >> >> Please let us know if either change solves your problem. >> I doubt either will fix the problem because your test >> program should be well within the 2000000.0 radius of the >> current BoundingSphere, but nothing about this problem >> makes sense so its worth a try. >> >> Cheers, >> Bill > > ------------------------------ Date: Tue, 22 Nov 2005 13:15:28 +1100 From: Andrew Donaldson <A.Donaldson@xxxxxxxxxx> Subject: Re: The random colour changing bug Hi Thomas, That's fixed it on my box. Now to try it on a stack more. I was wondering where you guys were getting 1.3.2 from! thanks, Andrew. Thomas D Rink wrote: > Hi Andrew, > > Give Java3D 1.3.2 a try: > > https://java3d.dev.java.net/ > > Tom > > Andrew Donaldson wrote: > >> Hi Bill and others, >> >> Thanks for having a look at this. >> >> I tried changing the BoundingSphere to MAX_VALUE, POSITIVE_INFINITY, >> -1.0, 0.0 and 1.0, all of which produced no noticeable difference. >> >> We have also now tested on: >> - Windows 2000, Matrix G450, Java 1.4.2_05, Java3D 1.3.1 OpenGL >> - RedHat Enterprise WS4, ATI Radeon X600, Java 1.4.2_09, Java3D 1.3.1 >> which also produce the fault. >> >> Our previous testing was all with Nvidia cards, all of which had the >> fault. >> >> It is good to see it happening with Nvidia, ATI and Matrox OpenGL >> implementations on both windows and linux. >> >> This problem is affecting our production of Tropical Cyclone >> warning graphics, which can be issued at any time now that we are in >> the cyclone season here. Any help fixing it is appreciated. >> >> I will look into what is involved in removing the scalar maps, >> I expect it won't be fun :) >> >> thanks, >> >> Andrew. >> >> >> Bill Hibbard wrote: >> >>> Hi Andrew, >>> >>> I found one little bit of dumbness in the AmbientLight: >>> the BoundingSphere is created with a radius of 2000000.0 >>> (looks like a throwback to McIDAS and Vis5D). You might >>> experiment with changing: >>> >>> BoundingSphere bounds >>> new BoundingSphere(new Point3d(0.0,0.0,0.0), 2000000.0); >>> >>> to: >>> >>> BoundingSphere bounds >>> new BoundingSphere(new Point3d(0.0,0.0,0.0), Double.MAX_VALUE); >>> >>> or: >>> >>> BoundingSphere bounds >>> new BoundingSphere(new Point3d(0.0,0.0,0.0), >>> Double.POSITIVE_INFINITY); >>> >>> in the createSceneGraph() method of >>> visad/java3d/DefaultDisplayRendererJ3D.java. >>> >>> Please let us know if either change solves your problem. >>> I doubt either will fix the problem because your test >>> program should be well within the 2000000.0 radius of the >>> current BoundingSphere, but nothing about this problem >>> makes sense so its worth a try. >>> >>> Cheers, >>> Bill >> >> >> ------------------------------ Date: Mon, 21 Nov 2005 20:32:45 -0600 (CST) From: Bill Hibbard <billh@xxxxxxxxxxxxx> Subject: Re: The random colour changing bug On Mon, 21 Nov 2005, Bill Hibbard wrote: > Yes, I think Curtis's observation that it occurs with > ConstantMaps but not with ScalarMaps to RGB may be a key > to finding a work-around. There must be some difference > between the GeometryArray or Appearance produced for > these two cases. I dug into this a bit but didn't find > the difference. I recall that you had some folks at BOM > who could dig into this Java3D level of stuff. Please > keep us informed and we will try to advise. I just had an inspiration that perhaps the difference may be that the GeometryArray has no colors array with the ConstantMaps, but alas it does have a colors array and its the same length as with the ScalarMaps to RGB (12 in both cases, which is 4 vertices times 3 for R, G & B but no alpha). However, I still think the key to finding a work- around is finding the difference between these two cases of Curtis's modification of your test program. Bill ------------------------------ End of visaddigest V1 #261 **************************
visad archives: