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.
Hi Randy, > Just want to make sure I am proceeding correctly... > I have polyhedral cells defined using a vertex list (x,y,z) and a cell list of > vertex indices (8 per hexahedron, etc.) Am I correct in thinking that VisAD > doesn't have direct support for the defn/display of such shapes, but rather, I > construct them via VisADGeometryArray (using quads, or whatever the case may > be)? Actually, VisAD Sets describe the geometries and topologies of finite point sets in R^n (n-dimensional real spaces). Sets are data objects in their own right (i.e., the Set class implements the Data interface and extends the DataImpl class) and Sets also describe the finite sampling domains of Fields (functions over R^n). For your vertex and cell lists, you would probably use the following constructor: public Irregular3DSet(MathType type, float[][] samples, CoordinateSystem coord_sys, Unit[] units, ErrorEstimate[] errors, Delaunay delan) throws VisADException; with arguments: type - the MathType of the set consisting of the polyhedral cells (e.g., MathType.stringToType("Set(x, y, z)") ) samples - float[3][number_of_vertices] giving the 3-D locations of vertices coord_sys - CoordinateSystem of set (may be null) units - Units of set (may be null) errors - ErrorEstimates of set (may be null) delan - topology of cells (if null this constructor invokes a Delaunay tetrahedralization - very slow) You would construct the 'delan' argument with this constructor: public DelaunayCustom(float[][] samples, int[][] tri) throws VisADException; with arguments: samples - float[3][number_of_vertices] giving the 3-D locations of vertices (same as passed to Irregular3DSet constructor) tri - int[4][number_of_tetrahedra] defining tetrahedra as sets of of 4 vertices (values in the tri array are the indices of vertices in the samples array If your cells form a regular 3-D grid (i.e., a lattice of hexahedral cells) then you can use this more efficient constructor: public Gridded3DSet(MathType type, float[][] samples, int lengthX, int lengthY, int lengthZ, CoordinateSystem coord_sys, Unit[] units, ErrorEstimate[] errors) throws VisADException { with arguments: type - the MathType of the set consisting of the polyhedral cells (e.g., MathType.stringToType("Set(x, y, z)") ) samples - float[3][number_of_vertices] giving the 3-D locations of vertices lengthX, lengthY, lengthZ - the dimensions of the grid (note that lengthX * lengthY * lengthZ = number_of_vertices) coord_sys - CoordinateSystem of set (may be null) units - Units of set (may be null) errors - ErrorEstimates of set (may be null) Note that for a Gridded3DSet the cell topology is implicit in lengthX, lengthY and lengthZ. If 'set' is the constructed Set object, then you could display it as follows: DataReferenceImpl ref = new DataReferenceImpl("set"); ref.setData(set); // link set to ref DisplayImplJ3D display = new DisplayImplJ3D("set display"); RealTupleType tuple = ((SetType) set.getType()).getDomain(); RealType x = (RealType) tuple.getComponent(0); RealType y = (RealType) tuple.getComponent(1); RealType z = (RealType) tuple.getComponent(2); display.addMap(new ScalarMap(x, Display.XAxis)); display.addMap(new ScalarMap(y, Display.XAxis)); display.addMap(new ScalarMap(z, Display.XAxis)); display.addReference(ref); // link ref to display Of course, you are probably using your set as the sampling domain for some Field (i.e., you have some dependent values like temperature at each vertex of your cell complex). In this case, your DataReferenceImpl would be linked to the Field data object and you'd add ScalarMaps for the dependent values (e.g., temperature) to Display.IsoContour and/or to Display.RGB. The VisAD display logic will take care of creating VisADGeometryArrays to depict your data, according to your ScalarMaps. Good luck, and please let me know if you have any further questions or problems. Cheers, Bill ---------------------------------------------------------- Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706 whibbard@xxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738 http://www.ssec.wisc.edu/~billh/vis.html "kill cross-platform Java by growing the polluted Java market" - from an internal Microsoft planning document
visad
archives: