Caves, Overhangs, Non-heightfield Elevation
- there is relatively little work yet on modeling caves and overhangs in
3D
- there are a handful of formats for cave data, but no standard file
format
- Carl Anderson [email]
writes:
- "Subterranean cave data is [currently] collected as a series of
vectors with a box for volume at each vertex. Height above point, floor
below point, left wall, and right wall, all collected in the aspect of
the flow on the survey. Using civil engineering techniques a volume can
be generated from the base data. Preserving the base data is very
important as a cave survey project may take years, the longest that I
have worked on lasted from 1966 to 1994. Error detection, Loop closure,
and error reduction through least squares regression take place after
EACH and every trip.
- Some experiments are ongoing to collect volumetric data directly
using laser distance tools to measure the volume in less discrete
slices. This technology is too expensive and too delicate for most
uses. Cave survey may include underwater portions, portions with
passage heights less than 1 foot, extremely muddy, and extremely
vertical passages.
- Caves can be vertical mazes, horizontal mazes, have deep shafts (300
- 1000 feet), have distinct passages overlaying each other vertically,
but separated by tens to 100s of feet.
What [cavers] want to do is to lay geological structures (faults, dikes,
...), geological separations (named rock units) and second order
derivates of LandSat 7 ETM+ data on top of hillsides to try to visualize
the underlying structures. Caves are voids that have exploited the
underlying geological structures (regional to very local).
- As far as raw cave data goes there is a project
RosettaStal
to pull from the most common cave data formats."
- WinKarst Cave
Mapping Software
- shareware for Windows, supports the whole process of surveying
caves, from sketches and notes, through digitizing maps, all the way to
simple 3D visualization of cave passages
- can import geodata from DEM, DLG, SDTS and GeoTIFF, survey data from
many survey formats and GPS
- can export cave data to 3D DXF
- The Survex Project
- open software for surveying and visualizing cave systems, but the
caves are modelled as vectors, not as volumes
-
HadesGL
- I'm not certain, as the site is in French, but it appears to be a
viewer for cave data which uses the .top files generated by related
software. As Jean-Pierre Cassou described it to me, "HadesGL is a
simple viewer for GHTopo software. GHTopo is a powerful software for
cave surveying, using TOPOROBOT methodology and full compatibles file
formats."
- source and binaries for Windows
- site and software are in French
Non-heightfield Terrain Engines & Papers
- Voxlap Cave Demo
- a project of Ken Silverman
and Tom Dobrowolski, demo
released August 2003
- fast, impressive demo (Win32) with attractive procedurally generated
non-heightfield scenery, fully destructible, with a high voxel
resolution
- the demo is fixed at a relatively low screen resolution, and the
surfaces do pixelate up close, though that's likely unavoidable with a
voxel approach
- Geek
[appears to be offline as of 2004]
- a terrain engine for Linux by Jack Strohm, supports arbitrary topology (including any sort of caves) using
volume data as input (latest version uses metaballs)
- Linux demo executable (was) available
- was a Flipcode
IOTD in 2001
and 2002
- Sven Forstmann's
HVox engine
(2004)
- "Uses large voxel volumes to display the landscape. The 3D-Space in
the engine consists currently of 5 Boxes (64x64x64 Pixels), which are
placed around the observer. The size of the first box is 64 pixels, the
next one twice (128) and so on. So i can display a Volume of
2048x2048x2048 at about 12 fps unoptimized."
- has some precompiled example executables for Linux and Windows
- adds details to close-up geometry by using Perlin noise
- Visualization of Large Caved Terrains, 2006
- Sven Forstmann, Jun Ohya, Waseda University
- link to paper?
- Voxelogic Acropora
Pseudo-Voxels
- Although a real voxel [wikipedia]
is a volume element, there was a convention in the game-developer community
in the 1990s to use the term 'voxel' to refer to heightfield rendering,
generally using approximate raycasting for a non-polygonal render. These
were not true voxels, as they were incapable of representing or rendering
actual volumes such as caves or overhangs. Some references to this
mis-named 'voxel' can still be found: