rtini - Right Triangulated Irregular Network Surface Approximation

Overview

A vectorized adaption of Vladimir Agafonkin’s MARTINI implementation of the Evans etal. Right-Triangulated Irregular Networks (RTIN) surface approximation algorithm. This implementation supports a broader range of dimensions and should also be faster in many use cases[1].

The workhorse functions are rtini_error() and rtini_mesh(). The former computes the surface approximation error at all levels of approximation, and the latter extract mesh triangles subject to an error tolerance.

This is package is experimental, lightly tested, and not intended for production use. It is unlikely this package will ever be posted on CRAN, but if you are interested in the functionality and know of a GPL licensed home for it do let me know.

library(rtini)

err <- rtini_error(volcano)

library(rgl)
par3d(windowRect=c(100,100,800,400))
mfrow3d(nr=1, nc=3, sharedMouse=TRUE)
for(tol in c(2, 10, 30)){
  next3d()
  ids <- rtini_extract(err, tol)
  xyz <- id_to_coord(ids, volcano)
  triangles3d(xyz, color='grey50')
}

This implementation works for any elevation map with odd number of rows and columns, but works best when the dimensions are (2^k + 1, n * 2^k + 1) as otherwise many tiles must be split just to get them to conform with each other, as can be seen here with volcano along the bottom and right edges.

Installation

This package is only available on github. Use your favorite package installer or:

f.dl <- tempfile()
f.uz <- tempfile()
github.url <- 'https://github.com/brodieG/rtini/archive/master.zip'
download.file(github.url, f.dl)
unzip(f.dl, exdir=f.uz)
install.packages(file.path(f.uz, 'rtini-master'), repos=NULL, type='source')
unlink(c(f.dl, f.uz))

Acknowledgments

• Vladimir Agafonkin for the implementation of and wonderful post on the topic.
• William Evans, David Kirkpatrick, and Gregg Townsend for the original paper.
• Daniel Adler, Duncan Murdoch, etal. for rgl with which we made the image in this README.
• R Core for developing and maintaining such a wonderful language.

[1] Error calculation should be generally faster, and mesh extraction should be comparable except when the reduced mesh has very large numbers of triangles, in which case the JavaScript implementation is faster.