Hi Eugene,
Currently there is no way to move lights or control
lighting parameters. VisAD uses the same policy we
have used for years in Vis5D - the light is at
infinity in the direction of the users eye (along
with a light from 180 degrees away so that we don't
have to worry about the signs of normals).
There are two approaches to represent graphs:
1. Represent your graph as a set of points and edges
in 2-D or 3-D, as an Irregular2DSet or Irregular3DSet,
constructed using a DelaunayCustom (see Section 3.5.5
of the Developers Guide). You can use this Set as the
domain of a Field, with Field values attached to each
vertex (but not to each edge). Also, VisAD currently
does not include a display mode to visualize a set as
its edges. The default visualization will be as faces,
but it can also be visualized as vertices in 'pointMode'.
2. Represent your graph as complex nested Fields with
MathTypes such as:
(vertex -> (list -> edge))
(edge -> (vertex, vertex))
where list is a sort of dummy variable that indexes
the list of edges meeting at a vertex. The current
VisAD displays won't be able to do much with these
fields, though. The second MathType is degenerate
from the display point of view, with vertex occuring
more than once in a RealTuple.
For this second approach to work, you'd need a custom
DataRenderer tuned to work with specific MathTypes
and interpret them as graphs. It would be a bit
tricky. Your DataRenderer would take an array of two
DataReferences, similar to Luz Laemmer's custom
DataRenderer for texture mapping (see the link on the
VisAD web page). You'd want to check the MathTypes
and ScalarMaps to make sure they obeyed the assumptions
of your DataRenderer. You would probably want to
elaborate the MathTypes to something like:
(vertex -> ((x, y, z), (list -> edge),
(vertex_param1, ..., vertex_paramN)))
(edge -> (vertex1, vertex2), (edge_param1, edge_paramN)))
Here (x, y, z) gives the spatial location of a vertex,
the Fields would all have IntegerSet domain sets (so
edge, vertex and list are all RealTypes taking integer
values), vertex1 and vertex2 are two different RealTypes
for vertex to avoid degeneracy, and vertex_param* and
edge_param* are parameters attached to vertices and
edges to be rendered as you desire according to
ScalarMaps.
The custom DataRenderer would probably test to make
that x, y and z are mapped to XAxis, YAXis and ZAxis.
Interpreting ScalarMaps involving vertex_param* and
edge_param* could be a little tricky, depending on
how general yuo want to get. You can always just
throw a BadMappingException of UnimplementedException
if you get ScalarMaps you don't like.
If you decide to try this approach, feel free to ask
us for advice.
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
