A quad mesh on a regular grid is completely determined by a tiny
recipe: the grid dimension, its extent, and the y orientation.
quad_spec() records that recipe as a plain, serializable list
without materializing any vertices or indexes.
Arguments
- dimension
number of cells in the grid (nx, ny), a single value is recycled
- extent
extent of the grid
c(xmin, xmax, ymin, ymax), default is the unit square- ydown
should the y coordinate be counted from the top, default
FALSE- crs
optional coordinate reference system, stored but not used by textures itself
- texture
optional file path to a PNG image to texture onto the mesh when materialized
- x
a quad_spec object
- ...
ignored, or passed between methods
Value
quad_spec() a list with class 'quad_spec', quad_mesh() a
mesh3d object, the print method returns its input invisibly
Details
quad_mesh() materializes the specification as a 'mesh3d' object
(as used by the 'rgl' package, but constructed without it). If the
spec carries a texture image file path, texture coordinates are
included: these are the extent-normalized vertex coordinates, so
they remain valid for any mesh whose vertices lie in the extent.
With the 'rgl' package installed, as.mesh3d() works directly on a
quad_spec (registered on-demand, 'rgl' is not required).
The mesh density given by dimension is independent of the pixel
dimension of any texture image: a coarse mesh may carry a
full-resolution image, the graphics engine interpolates within each
quad.
A spec can be stored, serialized, and sent where a materialized mesh cannot sensibly be - materialization is deferred to the consumer.
See also
Other textures:
break_mesh(),
quad()