Two new Venus images:

	twins.rle	View across the twin caulderas of an unusual double
			volcano toward Maat Mons, around 195 degrees west
			longitude near the Venus equator.  


	maat.rle	View of Maat Mons, a possibly active volcano near
			195 degrees west longitude at the Venus equator.
			View is from the Southwest.


These images use a technique we've been developing here at the Planetary
Geophysics Laboratory at Southern Methodist University.  The radar data
for these pictures cover about 10 degrees square with a resolution of
225 meters per pixel, (about 64 Megabytes for these particular images.)
The vertical resolution on both images is the JPL "standard" of 22.5,
about which they have received so much grief of late.  The altimetry
samples are of such low resolution that a 1:1 rendering produces essentially
a flat plane.  Same with 2:1, and 5:1 produces some faint detail. 
Terrestrial map-makers routinely use a vertical exaggeration between 10 and 25
when working at these resolutions (sea floor, mountain ranges, etc) so
the JPL value is actually quite moderate.  

The altimetry data used to generate the topography (read "height field")
is something like one data point per 20 kilometers.  Our original technique
used a spline or running Gaussian averages function to interpolate the
topography up to the resolution of the radar.  The new procedure uses the
radar image as a map to control a fractal interpolator.  This in turn is
controlled by the "rho" parameter of the Magellan Altimetry Data Records.
Rho is a measure of the spread of the altimetry pulse and is correlated
with surface roughness, so we map rho -> fractal D.   In essence this gives
us a surface with a continuously varying fractal dimension as a function
of the radar cross-section backscatter data whose range is controlled by the
altimeter pulse spread.   The radar image is also used to modulate the
color-map of the surface.

One difficulty of this technique used with Rayshade is that the data sets
become quite large, 256 Megabytes for these images.  We've modified
rayshade.4.0 to use the UNIX "mmap" function for both image and height field
data.  In this way only the data that are needed at any given time are
actually paged into memory.  Rayshade was further modified to write out
the intermediate height field grids ( which at "level 1" are twice the size
of the raw data) and mmap those arrays also during image generation.

One final problem deals with the height-field resolution in foreground and
background.  In general, height fields viewed from "near the surface" present
a counter-intuitive reduction of resolution in the foreground.  That is,
experience tells us that the surface close to us should have more detail
than the surface further away.  Raytracing a height-field presents the
exact opposite, where detail is defined as the average number of polygons
per pixel.  Further, in terms of rendering speed, the small number of data
points which define the foreground can all be easily held in memory and
the (low detail) rendering cranks along quite nicely.  In the background,
where less detail is required, we may actually be paging in a new hunk of
memory for every pixel, and processing time is beyond the limits of human
patience.  

We have approached this problem in a fairly slippery way, and there may well
be a more elegant solution.  We have modified the "heightfield" primitive
to accept multiple data files and "threshold" values.  The threshold value is
used as a switch at run time to select the appropriate data set based on the
distance from the eye position to the surface.  Then we generate the same
topographic surface at several different resolutions (actually, just two)
and use the high resolution (i.e., massive) data only in the foreground
where it is needed.  After each ray is cast the distance to the surface is
tested against the threshold value and a flag is set for the appropriate
data for the next ray.  The threshold value is adjusted experimentally 
until no "seam" between the two data sets is apparent. ( This usually
shows up as randomly placed polygons on an otherwise smooth surface.)

Using this technique the above images were generated on a SPARC2 with 64 Meg
of memory in about 20 minutes each.  This requires about 300 Meg of disk space.
The code itself is such a mess that I've been hesitant to offer it to any
one, but I can make it available to the stout-hearted on an "as is" basis,
if there is any interest.



11 June 92

David P. Anderson
Dept. of Geological Sciences
Southern Methodist University
dpa@venus.isem.smu.edu