panel.cloud {lattice} | R Documentation |
These are (related to) the default panel functions for cloud
and wireframe
.
panel.cloud(x, y, z, subscripts, groups, distance, xlim, ylim, zlim, panel.3d.cloud, panel.3d.wireframe, rot.mat, aspect, par.box, xlab, ylab, zlab, scales.3d, proportion = 0.6, wireframe = FALSE, scpos = list(x = 1, y = 8, z = 12), ..., col.at, col.regions) panel.wireframe(...) ltransform3dMatrix(screen, R.mat) ltransform3dto3d(x, R.mat, za = 1 , zb = 0, zmin, zmax, dist) panel.3dscatter.old(x, y, z, rot.mat = diag(4), za, zb, zback, zfront, distance, groups = NULL, subpanel = if (is.null(groups)) "panel.xyplot" else "panel.superpose", ...) panel.3dscatter(x, y, z, rot.mat = diag(4), za, zb, zback, zfront, distance, zlim, zero, groups = NULL, subscripts = TRUE, type = 'p', col, col.point, col.line, lty, lwd, cex, pch, ...) panel.3dwire(x, y, z, rot.mat = diag(4), za, zb, minz = 0, maxz = 1, col.at, col.regions, shade = FALSE, shade.colors = palette.shade, light.source = c(1, 0, 0), col = "black", col.groups = superpose.line$col, ...) palette.shade(cosangle, height, saturation = .3, ...)
x, y, z |
numeric vectors (or possibly factors etc for
panel.cloud ), not necessarily of the same
length. x can be a numeric matrix with 3 rows for
ltransform3dto3d |
subscripts |
which points to draw |
distance, par.box |
described in cloud |
xlim, ylim, zlim |
limits |
panel.3d.cloud |
function that draws the data-driven part of the
plot (as opposed to the bounding box and scales) in cloud |
panel.3d.wireframe |
the same for wireframe |
aspect |
aspect as in cloud |
xlab, ylab, zlab |
Labels, have to be lists |
scales.3d |
list defining the scales |
proportion |
Gives the length of arrows as a proportion of the sides |
scpos |
A list with three components x, y and z, describing which of the 12 sides of the cube the scales should be drawn. The defaults should be OK. Valid values are x: 1, 3, 9, 11; y: 8, 5, 7, 6 and z: 4, 2, 10, 12. See comments in panel.cloud |
wireframe |
logical, indicating whether this is a wireframe plot |
col.at, col.regions |
deals with specification of colors when
drape = TRUE in wireframe |
subpanel |
the function used to plot the points in
panel.3dscatter once coordinates of their projections are
computed. subpanel="panel.superpose" along with the
groups argument can be used to create grouped displays. |
screen |
list, as described in cloud |
R.mat, rot.mat |
4x4 transformation matrix in homogeneous coordinates |
za, zb, zmin, zmax, dist |
controls transformation to account for perspective viewing |
zback, zfront, zero |
same as previous, not for regular use yet |
type |
character string, specifying type of cloud plot. Can be ``p'', ``l'', ``h'' |
groups |
specification of a grouping variable, passed down from the high level functions. |
shade |
logical, whether lighting is to be used |
shade.colors |
a function that takes 2 arguments, the cosine of twice the angle of between the viewing direction and the direction of the light source, and a height between 0 and 1, and returns an appropriate color |
cosangle, height |
as described above |
saturation |
used as s in hsv inside
palette.shade |
light.source |
any vector (cartesian coordinates) in the direction of the light source. This is relative to the viewing point in the direction of (0,0,1) |
minz, maxz, col.groups |
miscellaneous other arguments. |
col, col.point, col.line, lty, lwd, cex, pch |
graphical parameters |
... |
other parameters, passed down when appropriate |
These functions together deal with the content drawn inside each panel
in cloud
and wireframe
. panel.wireframe
is the
same as panel.cloud
, which does the actual work.
panel.cloud
is responsible for drawing the content that does
not depend on the data, namely, the bounding box, the arrows/scales,
etc. At some point, depending on whether wireframe
is TRUE, it
calls either panel.3d.wireframe
or panel.3d.cloud
, which
draws the data-driven part of the plot.
The arguments accepted by these two functions are different, since
they have essentially different purposes. For cloud, the data is
unstructured, and x, y, z
are all passed to the
panel.3d.cloud
function. For wireframe, on the other hand,
x
and y
are increasing vectors with unique values,
defining a rectangular. z
must be a matrix with length(x)
* length(y)
rows, and as many columns as the number of groups.
panel.3dscatter
is the default panel.3d.cloud
function,
which computes the projection of the points and calls the
subpanel
function to draw the points in 2-D. (It's a very
simple function, and could serve as a model for customizing the
contents of the panels in cloud
.)
panel.3dscatter.new
is intended as a replacement for
panel.3dscatter
in future versions. Has a type
argument
to control type of plot. Has some nice properties, but is still in an
experimental stage.
panel.3dwire
is the default panel.3d.wireframe
function. If shade = TRUE
, it attempts to color the surface as
being illuminated from a light source at infinite distance, in the
direction given by light.source
. palette.shade
is a
simple function that returns the apropriate colors required for
shading given the cosine of twice the angle of between the viewing
direction and the direction of the light source, and a height between
0 and 1. (No shadows are formed, though.) Multiple surfaces are drawn
if groups
is non-null in the call to wireframe
, however,
the algorithm is not sophisticated enough to render intersecting
surfaces correctly.
ltransform3dMatrix
and ltransform3dto3d
are utility
functions to help computation of projections. The first function takes
a list of the form of the screen
argument in cloud
and
wireframe
and a R.mat
, a 4x4 transformation matrix in
homogeneous coordinates, to return a new 4x4 transformation matrix that
is the result of applying R.mat
followed by the rotations in
screen
. The second function applies a 4x4 transformation matrix
in homogeneous coordinates to a 3xn matrix representing points in 3-D
space, and optionally does some perspective computations. (There has
been no testing with non-trivial transformation matrices, and my
knowledge of the homogeneous coordinate system is very limited, so
there might be bugs here.)
Deepayan Sarkar deepayan@stat.wisc.edu