erich@eye.com ( Eric Haines) (10/01/90)
This issue is the longest to date. As such, I've deleted the Usenet postings
from this posting (they're about 55K more characters!) - go to the FTP sites
sometime after October 5th to get the full issue (sorry it can't be sooner,
but my FTP usage is limited). -EAH
_ __ ______ _ __
' ) ) / ' ) )
/--' __. __ , --/ __ __. _. o ____ _, / / _ , , , _
/ \_(_/|_/ (_/_ (_/ / (_(_/|_(__<_/ / <_(_)_ / (_</_(_(_/_/_)_
/ /|
' |/
"Light Makes Right"
October 1, 1990
Volume 3, Number 4
Compiled by Eric Haines, 3D/Eye Inc, 2359 Triphammer Rd, Ithaca, NY 14850
wrath.cs.cornell.edu!eye!erich or erich@eye.com
All contents are US copyright (c) 1990 by the individual authors
Archive locations: anonymous FTP at cs.uoregon.edu [128.223.4.13], /pub/RTNews,
weedeater.math.yale.edu [130.132.23.17], /pub/RTNews, and
freedom.graphics.cornell.edu [128.84.247.85], /pub/RTNews.
UUCP access: Vol 3, No 1 or write Kory Hamzeh (quad.com!avatar!kory) for info.
Contents:
Introduction
New People, Address Changes, etc
Photorealism, and the color Pink (TM), from Andrew Glassner
DKBTrace v2.0 and Ray Tracing BBS Announcement, by David Buck, Aaron Collins
Article Summaries from Eurographics Workshop, by Pete Shirley
Convex Polyhedron Intersection via Kay & Kajiya, by Eric Haines
New Radiosity Bibliography Available, by Eric Haines
A Suggestion for Speeding Up Shadow Testing Using Voxels, by Andrew Pearce
Real3d, passed on by Juhana Kouhia, "Zap" Andersson
Utah Raster Toolkit Patch, by Spencer Thomas
NFF Shell Database, by Thierry Leconte
FTP list update and New Software, by Eric Haines, George Kyriazis
======== USENET cullings follow ========
Humorous Anecdotes, by J. Eric Townsend, Greg Richter, Michael McCool,
Eric Haines
Graphics Interface '91 CFP
Parametric Surface Reference, by Spencer Thomas
Solid Light Sources Reference, by Steve Hollasch, Philip Schneider
Graphics Gems Source Code Available, by Andrew Glassner, David Hook
Graphics Gems Volume 2 CFP, by Sari Kalin
Foley, Van Dam, Feiner and Hughes "Computer Graphics" Bug Reports,
by Steve Feiner
Radiosity via Ray Tracing, by Pete Shirley
Algorithm Order Discussion, by Masataka Ohta, Pete Shirley
Point in Polygon, One More Time..., by Mark Vandewettering, Eric Haines,
Edward John Kalenda, Richard Parent, Sam Uselton, "Zap" Andersson,
and Bruce Holloway
Quadrant Counting Polygon In/Out Testing, by Craig Kolb, Ken McElvain
Computer Graphics Journals, by Juhana Kouhia
-------------------------------------------------------------------------------
Introduction
Well, SIGGRAPH has come and gone, and as usual I ran out of time. There's
just too many people to meet and too much to see and do. Highlights for me
included the SIGGRAPH Trivia Bowl, meeting in a cemetery for lunch with other
renderers after an all night session of Hurtenflurst (don't ask), and getting
my head turned into data at Failure Analysis Associates (still haven't heard
from them, though. Does anyone have the phone number or address for this
company? I'd like to call and find out what is happening with them). At
SIGBowl our Ithaca team was able to lock in third place [of 3 teams] early on
and held it against all comers. Nonetheless, a great time: one of many
favorite moments was:
Pike (the moderator): "Who's biographical sketch reads as follows-"
BUZZ!
Team 1 (with no other information): "Turner Whitted!?"
Pike: "No, wrong. Now let me read the question" and proceeds to read
some biographical data.
BUZZ!
Team 2: "Is it Turner Whitted!?"
Pike: "Still wrong."
Team 3, sadly, did not guess "Turner Whitted?", but, rather, declined to answer.
--------
Does anyone have a nice, compact version of the Teapot? That is, just the
spline description (which I do have) and a tessellator which will turn it into
quads/triangles (which I have, but it's deeply buried in some scary code)?
This would be a nice addition to SPD 3.0, but I don't have one easily
accessible. Here's your chance to get your code distributed in the next
release. I'm willing to massage your code into outputting NFF format.
I'll also announce that there is a new version of the ray tracing bibliography
which I've finished as of today. Many of the new articles listed are due to
the untiring work of Tom Wilson, who says the librarians now hate him. This
new version should be available via FTP by October 5th on
freedom.graphics.cornell.edu and cs.uoregon.edu (see the FTP site list later
in this issue for more information).
Important dates:
Graphics Interface papers due October 31st
Graphics Gems, Volume 2 submissions due November 1st
-------------------------------------------------------------------------------
New People, Address Changes, etc
# Tom Wilson - parallel ray tracing, spatial subdivision
# Center for Parallel Computation
# Department of Computer Science (407-275-2341)
# University of Central Florida
# P.O. Box 25000
# Orlando, FL 32816-0362
alias tom_wilson wilson@ucf-cs.ucf.edu
I am a Ph.D. student at UCF. I am working in the area of parallel processing
with ray tracing as an application. I am working on a nonuniform spatial
subdivision scheme that will eventually be implemented on our BBN Butterfly
GP1000.
--------
# Steve Hollasch - efficiency, algorithms, ray-tracing
# Master's Student in C.S., Arizona State University
# 1437 West 6th Street
# Tempe, AZ 85281-3205
# (602) 829-8758
alias steve_hollasch hollasch@enuxha.eas.asu.edu
I'm working on completing my thesis in December 1990 or January 1991. The
research basically covers viewing 4D objects (as physical entities, not 3D
scalar fields). I'm working on a 4D raytracer right now that handles
hyperspheres and tetrahedrons, and I hope to extend it to hyperellipsoids,
hypercones, hypercylinders and so on. I'd also like to learn how to tessellate
4D solids with tetrahedrons to be able to view arbitrary 4D solids. Practical
uses? I'm still trying to think off something... =^)
--------
# Christophe Vedel - improving radiosity
# LIENS, Ecole Normale Superieure
# 45, rue d'Ulm
# 75230 PARIS Cedex 05 FRANCE
# (33) 1 43 26 59 74
e-mail vedel@ens.ens.fr
vedel@FRULM63.BITNET
I'm interested in improving the radiosity method for finer results or larger
scenes. Spatial subdivision techniques developed for ray tracing should help
to achieve this goal. I'm also working on interactivity with lighting
simulation programs.
--------
# Frederic Asensio - behavioral animation, radiosity
# LIENS, Ecole Normale Superieure
# 45, rue d'Ulm
# 75230 PARIS Cedex 05 FRANCE
# (33) 1 43 26 59 74
e-mail asensio@ens.ens.fr
asensio@FRULM63.BITNET
I am interested in interactive radiosity methods, which could be used in the
design process and in stochastic methods for light sampling with rays.
--------
# Scott Senften - efficiency, scientific visualization
# McDonnell Douglas Corp.
# McDonnell Aircraft Co.
# Mail Code 1065485
# St. Louis, MO 63166
# (314)232-1604
alias scott_senften senften%d314vx.decnet@mdc.com
alias senften_tu senften@tusun2.utulsa.edu
Presently I'm doing research in neural nets. There is a real need in the NN
society for some good scientific visualization. I'm presently doing work in
speech recognition, diagnostics, flight reconfiguration, and signal
processing, as well as graphic visualization of neural networks. My graduate
work was in Ray Tracing efficiency.
--------
Sam Uselton
Internet:
uselton@nas.nasa.gov
Work Home
Phone:
(415) 604-3985 (415) 651-6504
USMail:
Samuel P. Uselton, PhD Sam Uselton
Computer Sciences Corp.
M/S T 045-1 1216 Austin St.
NASA Ames Research Center Fremont, CA 94539
Moffett Field, CA 94035
Ray Tracing interests:
efficiency, accuracy, distributed ray tracing, parallel implementations
At NASA I'm working on volume visualization for computational fluid dynamics.
I've used this as an excuse ( :-) ) to write a ray caster (no bounces) that
integrates through the volume, accelerated by taking advantage of the special
grids, as well as an item buffer-like initial hit finder.
I'm also working with Redner & Lee on extending our distributed ray tracing
work to handle diffuse illumination, caustics, wavelength dependent
refraction, and other realistic effects.
Once these problems are completely solved ( :-) :-) ), there are several
parallel machines here that I would like to wring out.
Oh yes, we (Lee, Steve Stepoway, Scott Senften and myself) have yet another
Acceleration technique we like better than any of the popular ones. (Actually
it can combine with bounding boxes.) It is somewhere between regular space
subdivision (a la medical volume folks and Japanese SEADS..) and the bounding
slabs idea (Kaplan? [no, Kay]). It was written and submitted for pub once,
but we keep thinking of new tweaks, so it is being re-written.
--------
# Juhana Kouhia
# Ylioppilaankatu 10 C 15
# 33720 Tampere
# Finland
alias juhana_kouhia jk87377@tut.fi
I have done my wireframe, scanline and ray tracing programs with Jim Blinn's
modeling language.
[Another renderer with a last name starting with K! There's Kajiya, Kaplan,
Kay, Kirk, Kolb, Kuchkuda, Kyriazis, just to mention a few. --EAH]
--------
# Michael L. Kaufman - speed, ray tracing on a PC, ray tracing fractal images
# Northwestern University
# 2247 Ridge Ave #2k
# Evanston IL, 60201
# (708) 864- 7916
# kaufman@eecs.nwu.edu
I am just getting started in Ray-Tracing. I am interested in coming up with
algorithms that are fast enough to do on a 386 PC. I am also interested in
using Ray-Tracing techniques as a new way of looking at certain types of
fractal images.
--------
Stephen Boyd Gowing - light transmission, motion, art
B.App.Sc (Computing) Undergraduate.
University of Technology, Sydney
4/10 Short St, Glebe 2037 AUSTRALIA (home)
alias stephen_gowing sbgowing@ultima.cs.uts.oz.au
I'm currently half way through a project to study the effect of light passing
through sphere(s). The eventual aim is to produce a short animation showing a
single sphere inverting an image which breaks (unmerges?) into two spheres
one behind the other and study the "flow" of the image through them. At the
moment I am still rewriting the tracer I used for my 2nd-last graphics
assignment last year. I'd like to do it in C++ but this would make things
awkward as we don't have access to a compiler. I'd also like to implement
some sort of shading language into the image description - probably using
something like forth.
--------
# Rick Brownrigg -- efficiency, texturing, visualization, DTM displays
# Kansas Geological Survey
# University of Kansas
# 1930 Constant Avenue
# Lawrence, KS USA 66046
# 913 864 4991
-------------------------------------------------------------------------------
Mail, from Andrew Woo, George Kyriazis, Zap Andersson
from Andrew Woo:
I have gone through many changes in the last year, from graduating with a
M.Sc. at University of Toronto, to working at SAS Institute, to working at
Alias Research - which is my current working address. My e-mail at Alias is
awoo@alias.UUCP.
I checked out your latest RT News. I think David Jevans was a little too hard
on you about not knowing about the ray id for voxel traversal. In fact, in GI
90, one of the authors was unaware of it, too (in the "Approximate Ray
Tracing" paper). So you are not alone. In fact, there is an explicit
mentioning of ray id in an early paper that David did not mention:
John Amanatides, "A Fast Voxel Traversal Algorithm for Ray Tracing",
EuroGraphics, 1987, pp. 1-10.
On the claim that David Jevans made about wasting time on more intersection
culling schemes, I tend to agree. In fact, I have stopped looking for more
clever ways to cull intersections. But I intend to check out another route to
ray tracing savings. Once I get some promising results, I will share the idea
with you (to avoid any embarrassments in case the idea backfires).
On renaming DIstributed Ray Tracing, I am more of a fan of coming up with
amusing acronyms for the algorithms. For Cook's, I thought DiRT might be
interesting. I also came up with an acronym for my paper in GI 90 - Voxel
Occlusion Method as an Intersection-culling Technique, which spells VOMIT.
--------
from George Kyriazis:
I was reading the last RTN issue I received. In there it states about a
program that converts sculpt4d to NFF, and it also commented that Sculpt4D is
an exceptional modeler. Well, I have my doubts. Last spring I was working on
a program to raytrace Scultpt4D files and animations on a Pixel Machine.
Well, the file format is far from being strait-forward. We had to call Byte
by Byte for a few questions and stayed on the phone for more than an hour.
One of the Sculpt4D unwanted 'features' was that it normalized the intensity
of all displayed pixels wrt the brightest. The result on the Pixel Machine
was disastrous! Images were either overexposed or totally black! :-) Well,
this is one of the problems faced, but I don't want to list more...
-------------------------------------------------------------------------------
Photorealism, and the color Pink (TM), from Andrew Glassner
From a Tektronix ad in this month's Advanced Imaging, we learn that it is now
possible to turn real photographs into photorealistic images (presumably
thereby increasing realism):
"Traditional workstations can't handle reality. They create a simulated
world... With Dynamic Visualization, reality and simulation are brought
together by TekImaging (TM), powerful image-processing software... [and now,
the big one -ag] TekImaging lets you transform real-world images into
photo-realistic scenes, complete with light, shadow, and texture."
So now I can take a picture of myself, and using their software make it look
photo-realistic and indistinguishable from a real picture - what a
breakthrough!
--------
Beware of the colors you pick for your images. Here's a footnote in an
Owens-Corning Fiberglas ad in this month's [August?] Popular Science (pg 21):
"* The color Pink is a trademark of Owens-Corning Fiberglas Corp."
I think I'll get a trademark on red before all the good colors are taken...
-------------------------------------------------------------------------------
DKBTrace v2.0 and Ray Tracing BBS Announcement, by David Buck, Aaron Collins
I recently completed version 2.0 of my freely distributable raytracer called
DKBTrace. This raytracer is a project I've been working on (actually, off and
on) for the past five years. The raytracer features:
- primitives for spheres, planes, triangles, and quadrics
- constructive solid geometry
- solid texturing using a Perlin-style noise function
- image mapping (IFF and GIF formats)
- hierarchical bounding boxes
- transparency
- fog
- 24 bit output files
- adaptive anti-aliasing using jittered supersampling
- "quick" previewing options
The raytracer was developed on an Amiga computer, but it is easily portable to
other platforms. The interface to the raytracer raytracer is a scripting
language (sorry, no GUI). The language is quite readable compared to many
other input file formats.
The source and Amiga executables are available by anonymous FTP from
alfred.ccs.carleton.ca [134.117.1.1]. The source and executables are freely
distributable.
As with any raytracer, there are still things that need to be done, added, or
improved with DKBTrace. The image mapping was added at the last minute, so it
only uses a simple projection scheme. This means that the mappings look
bizarre when viewed from the sides or the back. For the most part, however,
the solid textures are quite powerful and can create some very interesting
effects.
To implement transparency, I decided to add the transparency value value to
the color structure. A color contains red, green, blue, and alpha components.
This makes it much easier to use in textures.
The textures also allow you to define your own color map and to have the
colors automatically interpolated from one range to the next. Interpolating
the colours makes the images look much better than just a simple step
function.
Questions and comments concerning the raytracer can be directed to
David_Buck@Carleton.CA on BITNET. The IBM port (and several enhancements)
were done by Aaron Collins. Aaron can be reached on Compuserve.
--------
DKBtrace dox info:
Aaron Collins can be reached on the following BBS'es
Lattice BBS (708) 916-1200
The Information Exchange BBS (708) 945-5575
Stillwaters BBS (708) 403-2826
AAC: As of July of 1990, there will be a Ray-Trace specific BBS in the (708)
Area Code (Chicago suburbia) for all you Traceaholics out there. The phone
number of this new BBS is (708) 358-5611. I will be Co-Sysop of that board.
There is also a new Ray-Trace and Computer-Generated Art specific SIG on
Compuserve, GO COMART. And now, back to the DOCS...
-------------------------------------------------------------------------------
Article Summaries from Eurographics Workshop, by Pete Shirley
(shirley@iuvax.cs.indiana.edu)
[What follows are summaries of ray tracing related articles given during the
Eurographics Workshop on Photosimulation, Realism and Physics in Computer
Graphics in Rennes, France, June 1990. - EAH]
INCREMENTAL RAY TRACING by Murakami and Hirota (Fujitsu)
A extension of Parameterized ray tracing that allowed moving some scene
objects in addition to changing material properties. Used tables of
changed voxels to determine if a ray's interaction with geometry has
changed. Included implementation on multiple CPUs. Also includes
reference to a paper in Japanese by Matsumoto on Octree ray tracing in
1983!
PARAMETRIC SURFACES AND RAY TRACING by Luc Biard (IMAG, France)
Like most parametric patch papers, this one went over my head, but
it seems to be an interesting paper, and includes some implementation results.
A PROGRESSIVE RAY TRACING BASED RADIOSITY WITH GENERAL REFLECTANCE FUNCTIONS
by Le Saec and Schlick (France)
A proposal for general BRDF radiosity (very similar to what I propose in the
paper above). Also includes method for interactive display - display only
non-mirrors until viewer stops, then ray trace (UNC style).
LIGHT SOURCES IN A RAY TRACING ENVIRONMENT by Roelens et al. (France)
A method for showing 'cone of light' effect when there is not very
dense participating media in a room (primary scattering only).
METHODS FOR EFFICIENT SAMPLING OF ARBITRARILY DISTRIBUTED VOLUME DENSITIES
by Hass and Sakas (FRG)
Methods of sampling a volume density along a ray.
-------------------------------------------------------------------------------
Convex Polyhedron Intersection via Kay & Kajiya, by Eric Haines
I like Kay and Kajiya's bounding slabs method [SIGGRAPH 86] a lot. By
thinking about how this algorithm actually works, we can derive a method for
intersecting convex polyhedra. A working definition of a convex polyhedron is
a polyhedron which can have at most two intersection points for any ray.
To review:
Their idea is to form a bounding volume around an object by making slabs. A
slab is the volume between two parallel planes. The intersection of all slabs
is the bounding volume (i.e. the volume which is inside all slabs). The
intersection method works by intersecting each slab and checking out
intersection conditions for it alone, then comparing these results to the
answer for previous slabs. That is, first we get the near and far
intersection points for the ray with the slab. If the far hit is behind the
ray's origin (i.e. negative distance) or the near hit is beyond the maximum
distance (i.e. you might limit how far the ray can travel by keeping track of
the closest object hit so far, or the distance to the light if this is a
shadow ray), then the ray cannot hit the bounding volume.
If the near and far hits are within bounds, then we essentially do a set
operation of this line segment and any previous slab line segments formed.
For example, if this is the second slab tested, we try to find the overlap of
the first slab's hits and this slab's hits. If the two segments do not
overlap, then there is no point along the ray that is inside both slabs. In
other words, there is no point inside the bounding volume, since this volume
is the logical intersection of all slabs. To get the logical intersection of
the slab segments, we merely store the largest of the near hits and the
smallest of the far hits. If this largest near hit is greater than this
smallest far hit, there was no overlap between segments, so the bounding
volume is missed. If near is less than far, this new high-near, low-far
segment is used against successive slab segments. If the ray survives all
segment tests, then the resulting near and far values are the distance along
the ray of the near and far hits on the bounding volume itself.
What's interesting about this test is that it is essentially doing
Constructive Solid Geometry operations between slabs, similar to [Roth 82].
This simple idea can be extended further, allowing you to quickly intersect
convex polyhedra. Another good feature is that the polyhedra can be defined
entirely by the plane equations for the faces, so no vertices have to be
stored.
Imagine that you have defined a convex polyhedron by specifying each face
using a plane equation, Ax + By + Cz + D = 0. Have each face's normal {A,B,C}
point outwards.
To intersect this object with a ray, simply test the ray against each face:
if you hit a plane that faces towards the ray (i.e. the dot product of the
normal and the ray direction is negative), then use this as a hit for near;
if you hit a plane facing away, then use this as a hit for far. Now, instead
of having a line segment for each slab, you have an unbounded ray for each
plane. For example, if you have a hit for a near distance (i.e. you hit a
forward facing plane), then you would first check if this near is beyond your
current maximum distance. If not, then you would store the maximum of this
near value and the previous (if any) near value. If at this point the stored
near value is greater than the stored far value, the ray has missed. This
process continues with each plane until you miss or you run out of planes.
The near and far points are then your intersection points with the polyhedron.
Essentially, this process is an extension of Kay & Kajiya: the ray is tested
against each face and the intersection point is used to form a segment which
is unbounded (infinite) on one end. This segment is tested for validity
against the ray's segment and the polyhedron's current intersection segment.
If the polyhedron's segment is valid at the end of the process, then the ray
hit the polyhedron. Basically, each face of the polyhedron defines a
half-space in which the inside of the polyhedron must lay. The intersection of
these half-spaces is the polyhedron itself.
One minor problem is what happens when the ray is parallel to the plane. You
could use Kay & Kajiya's suggestion of using some epsilon for the divisor,
but I prefer handling this special case separately. If parallel, then we
want to check if the ray origin is inside the half-space: if it is not, then
the ray cannot ever hit the polyhedron (since the ray does not cross into the
volume of valid intersections formed by this half-space). In other words, if
we substitute the origin into the plane equation, the result of the expression
must be negative for the point to be inside the half-space; if not, the ray
must miss the polyhedron.
The pseudo-code:
Maxdist = maximum distance allowed along ray
Tnear = -MAXFLOAT, Tfar = MAXFLOAT
For each plane in the polyhedron:
Compute intersection point T and sidedness
dp = ray.direction DOT plane.normal
do = (ray.origin DOT plane.normal) - plane.d
If ( dp == 0 )
/* ray is parallel to plane - check if ray origin is inside plane's
half-space */
If ( do > 0 )
/* ray is outside half-space */
return MISSED
Else
/* ray not parallel */
T = do / dp
If ( dp < 0 )
/* front face - T is a near point */
If ( T > Maxdist ) return MISSED
If ( T > Tnear )
Tnear = T
Normal = plane.normal
Else
/* back face - T is a far point */
If ( T < 0.0 ) return MISSED
If ( T < Tfar ) Tfar = T
If ( Tnear > Tfar ) return MISSED
endfor
return HIT
At the end, Tnear is the intersection distance and Normal is the surface
normal. Tfar is the exit distance, if needed.
That's it: instead of laborious inside/outside testing of the polygon on each
face (and storing all those vertices), we have a quick plane test for each
face. If the number of planes is large, it might have been better to store
the polygons and use an efficiency scheme. However, the method above is
certainly simpler to code up and is pretty efficient, compact, and robust:
for example, there are no special edge intersection conditions, as there are
no edges!
An aside:
One thing that I hadn't mentioned is how we can better initialize the near and
far hit distances before the slab tests. It turns out that when testing
bounding volumes we can set Tnear (the near distance) to 0 and Tfar to the
maximum ray distance (if any - else set it to "infinity"). This corresponds
to the segment formed by the ray: we consider points between 0 and the
maximum ray distance to be valid points on the ray, and so want to find slab
segments that overlap this segment. Note that these initial conditions gets
rid of some complication for the algorithm: we now don't have to test our
slab segment against the ray's segment and the previous bounding volume
segment, but rather are always testing against a single segment which
represents the intersection of both of these. This idea is not in Kay &
Kajiya's presentation, by the way.
Note that there is one change that occurs if you initialize the near and far
distances in this way: the near and far distances computed when a volume is
hit will not yield the true surface intersections, but rather will give the
first and last points inside the volume. This is useful for bounding volumes,
since we usually just want to know if we hit them and have some idea of the
distance.
-------------------------------------------------------------------------------
New Radiosity Bibliography Available, by Eric Haines
A bibliography of publications related to radiosity is now available at:
freedom.graphics.cornell.edu [128.84.247.85]: /pub/Radiosity
It's a compressed package using "refer" format. Articles related to radiosity
or "non-classical" rendering (soft shadows, caustics, etc) are included here.
This version is significantly improved from the version I posted some months
ago. Many thanks to all who helped update it.
-------------------------------------------------------------------------------
A Suggestion for Speeding Up Shadow Testing Using Voxels, by Andrew Pearce
Requirements:
------------
This method is applicable to any type of spatial subdivision. It is probably
best suited to those of us who tessellate our objects to ray trace them.
Method:
------
I've expanded on Eric Haines' method of storing the last object hit by a
shadow ray with each light source, I now save a pointer to the voxel which
contains the last object hit (or at least the voxel the intersection occurred
in if the object spans multiple voxels). My rationale is that if the shadow
ray does NOT intersect the "last object" which shadowed that light source,
then the likelihood of it hitting something in the neighborhood of that same
object is pretty good. If we save the voxel which the shadowing occurred in
for the previous ray, we can examine the other objects in that voxel for
possible light source occlusion WITHOUT the ray startup and voxel traversal
costs. Now this assumption is likely untrue if you're just tracing spheres
and checker boards (some slight intended :^) but it works quite well for
tessellated objects (NURBS patches in my case).
I NULL my pointers to both the last object and last voxel if no shadow
intersection was found on the last shadow ray to this light.
I store a ray_id with every object to insure that any given ray is tested for
intersection with an object ONLY ONCE even if it spans multiple voxels. Each
ray has a unique id. (I thought, as did David Jevans, that this was a well
known technique). So, even if the shadow ray misses all of the objects in
"last voxel" and must be traced like a regular shadow ray, we are likely not
losing much since if the shadow ray enters the "last voxel" during it's
traversal of the voxels, the ray will see that it has already been intersected
with all of the objects in that voxel, and that voxel will be skipped
relatively quickly (slightly slower than an empty voxel; the time it takes to
compare the ray ID against the ray ID stored with each object).
Pseudo-code:
-----------
/****************************************************************************/
/* Obviously we cannot use the "last object hit" for transparent */
/* objects since multiple objects may be involved in the shadowing process. */
/* The code outlined below assumes that we only store the "last object" and */
/* "last voxel" for shadow rays generated from a primary ray intersection. */
/* What we really should have is a tree indicating what was hit at each */
/* level of recursion. Ie. What object shadowed the intersection point */
/* generated by the last refraction ray, generated from a reflection ray */
/* generated by a primary ray? */
/****************************************************************************/
float check_shadowing(ray, light)
RAY_REC ray; /* ray from shading point to light source */
LIGHT_REC light; /* the light source we are interested in */
{
if (light.last_object != NULL) {
/* intersect_object() marks object as having been */
/* intersected by this ray. */
hit = intersect_object( ray, light.last_object, &object);
if (hit) {
return(1.0); /* full shadowing */
}
if (light.last_voxel != NULL) { /* implied !hit */
/* intersect_object_in_voxel_for_shadows() returns hit = TRUE */
/* on first affirmed intersection with a non-transparent
* object. */
/* It ignores transparent objects altogether. */
hit = intersect_objects_in_voxel_for_shadows( ray,
light.last_voxel,
&object);
if (hit) {
light.last_object = object;
return(1.0);
}
}
}
/* traverse_voxels_for_shadows() DOES intersect transparent objects and */
/* sorts the intersections for proper attenuation of the light intensity. */
/* If it hits multiple objects, the object returned is the transparent one. */
hit = traverse_voxels_for_shadows(ray, &object, &voxel, &shadow_percent);
if (!hit) {
light.last_object = light.last_voxel = NULL;
return(0.0);
}
if (object.transparency_value > 0.0) {
/* the object is transparent */
light.last_object = light.last_voxel = NULL;
}
else {
light.last_object = object;
light.last_voxel = voxel;
}
return ( shadow_percent );
}
Results:
-------
(For the discussion below, "positive occlusion" means we have guaranteed that
the point we are shading is shadowed from the light source.)
The "last object hit" method provided a positive occlusion 52% of the time,
and if the "last object hit" method did not provide positive occlusion, the
"last voxel" method provided a positive occlusion 76% of the time.
I performed a "pixie" of the code with and without this opt. on an SGI
Personal Iris with no other code changes or scene changes, there is ONE light
source in the scene which is casting shadows. The ray tracer with the "last
voxel" optimization used 2% fewer cycles. (Actual system times vary wildly
based on load, but the last voxel version did run about 10% faster using the
UNIX "times()" system call, but I don't trust "times()"). Two percent
doesn't seem like an awful lot, but this is just a quick and dirty hack, and I
would expect to save 2% on EACH light source which casts shadows.
The test scene I'm using is a snare drum with a shadow casting spotlight on
it. See IEEE Computer Graphics & Applications, Sept. 1988, the cover story
includes a tiny reproduction of the image should you wish to see what I'm
playing with, although the image in CG&A was done with a 2D projective
renderer (ray casting), not ray tracing. The reflections in the floor and on
the chrome in that image were realised using two separate cubic environment
maps, the shadows were done with a depth map, the wallpaper is a simple
parametric map and the floor boards have 6 separate solid wood textures
randomly assigned to them.
The test scene contains approximately 60,000 triangles and I'm rendering at
512x512 resolution with no anti-aliasing, and a limit of one recursion level
for both shadow and reflection rays for a total of 638,182 rays. There is
only one light in the scene which casts shadows.
I'll be doing tests on more scenes with various levels of voxel subdivision,
and object distribution. I'll let you know the results, even if they're
negative! (The above results did surprise me a little).
Additional Note: I urge anyone doing ray/triangle intersections to use Didier
Badouel's "An Efficient Ray-Polygon Intersection" (Graphics Gems pp.
390-393). I have implemented both Badouel's method and Snyder/Barr's
barycentric method, and Badouel's method is about 19% faster (I optimized the
snot out of my implementation of the barycentric method, but I used most of
those same opts in Badouel's method as well). This result is from comparing
the same scene ray traced with the two versions.
_________________________________________________________________________
[A second article followed some days later - EAH]
More results from the voxel/shadow optimization:
-----------------------------------------------
One thing I neglected to mention in the previous message was that you should
be sure to NULL out your last object and last voxel hit pointers at the end of
each scanline.
NEW TEST SCENES:
---------------
The test scenes producing the results below are 40x40x40 arrays of polygons
(each polygon is broken down into 8 triangles). The polygons are distributed
at unit distances from each other, and then their orientations are jittered
(rotations) and their positions are jittered (translate of -1. to +1.). Each
polygon is roughly a unit in width and height. The polygons are inside of a
larger box (the room) with 15 shadow casting lights in a 5x3 array just below
the "ceiling". There were no reflection or refraction rays generated. All
images were computed at 645x486 pixels with 4 supersamples per pixel. Every
intersection generated 15 shadow rays. The "sparse" scene had every polygon
scaled by 0.2 in all dimensions. The resulting sparse image looks like an
exploding particle system (due mainly to the 145 degree field of view). In
the dense image, almost no background can be seen.
CHART DESCRIPTION:
-----------------
"Last Voxel" speed up refers to the percentage fewer cycles the "last voxel"
method took to compute the same image. Since this percentage is calculated
based on the number of cycles the entire ray trace took, it is an exact
measure of the speed up. Negative numbers mean that the "last voxel" method
was slower. It is important to note that file read, tessellation and spatial
subdivision time is included in the count of the cycles, so the actual speed
up to the ray tracing alone may be greater than is stated, depending on how
you want to measure things.
Average Hits Per Ray is included as a general measure of the density of the
scene, it is the number of confirmed ray/triangle intersections divided by the
total number of rays (shadow rays included). In the sparse scene it is less
than one since most of the shadow rays made it to the light sources without
hitting anything. The dense scene is greater than one because some confirmed
intersections are abandoned due to nearer intersections being found in the
same voxel.
Average Hits Per Primary Ray is the number of confirmed ray/triangle
intersections divided by the number of primary (eye) rays.
--------------+-----------------+-----------------+
Scene | 64,000 jittered | 64,000 jittered |
Description | polygons (0.2) | polygons (1.0) |
| (sparse) | (dense) |
--------------+-----------------+-----------------+
Number of | 551,408 | 551,408 |
Triangles | | |
--------------+-----------------+-----------------+
Number of | | |
Shadow Casting| 15 | 15 |
Lights | | |
--------------+-----------------+-----------------+
Number of Rays| 11,324,318 | 8,427,904 |
--------------+-----------------+-----------------+
"Last Object" | | |
Success Rate | 50.7% | 90.9% |
--------------+-----------------+-----------------+
"Last Voxel" | | |
Success Rate | 23.4% | 39.3% |
--------------+-----------------+-----------------+
"Last Voxel" | | |
Speed Up | 1.04% | 3.6% |
--------------+-----------------+-----------------+
Average Hits | | |
Per Ray | 0.265 | 1.001 |
--------------+-----------------+-----------------+
Average Hits | | |
Per Primary | 2.363 | 6.638 |
Ray | | |
--------------+-----------------+-----------------+
It is encouraging that there is a speedup even in very sparse scenes (however
slight a speed-up it is). These "random" scenes are not very indicative of
the type of scenes we are generally interested in ray tracing. (Really, these
scenes look like particle systems, I can think of much better ways to render
them with to produce similar images :^). So, here's the same chart for the
snare drum with increasing numbers of lights. The extra lights are scattered
around the "room" and all point towards "Spanky" the snare drum.
--------------+---------+---------+---------+
Scene | Snare 1 | Snare 3 | Snare 6 |
Description | Shadow | Shadow | Shadow |
| Light | Lights | Lights |
--------------+---------+---------+---------+
Number of | 59,692 | 59,692 | 59,692 |
Triangles | | | |
--------------+---------+---------+---------+
Number of | | | |
Shadow Casting| 1 | 3 | 6 |
Lights | | | |
--------------+---------+---------+---------+
Number of Rays| 638,182 |1,097,569|1,737,021|
--------------+---------+---------+---------+
"Last Object" | | | |
Success Rate | 52.6% | 89.0% | 88.7% |
--------------+---------+---------+---------+
"Last Voxel" | | | |
Success Rate | 76.3% | 77.0% | 76.9% |
--------------+---------+---------+---------+
"Last Voxel" | | | |
Speed Up | 1.97% | 3.37% | 4.39% |
--------------+---------+---------+---------+
Average Hits | | | |
Per Ray | 0.75 | 0.67 | 0.59 |
--------------+---------+---------+---------+
Average Hits | | | |
Per Primary | 1.84 | 2.84 | 3.94 |
Ray | | | |
--------------+---------+---------+---------+
Well, the speed-up isn't quite 2% per light as I said in my previous article,
but it is there. The "last voxel" trick has not slowed down the ray tracing
process in any of these tests which is quite encouraging.
------------------------------------------------
Another helpful hint if you are ray tracing tessellated or planar surfaces:
In general when spawning a shadow ray, one must be careful to avoid
intersecting the object just struck. Usually this is done by adding some
small epsilon to the origin of the shadow ray along it's direction of travel.
However, if you store a ray id with every object (triangle) to record if that
object has been tested against the current ray, then you can use that id to
avoid testing your shadow ray against the intersected object which generated
the shadow ray. Before spawning the shadow ray, place the id number of the
shadow ray into the ray id field of the object which has just been
intersected. This method won't work for objects which can self shadow (eg.
parametric or implicit surfaces), but it works fine for planar surfaces (eg.
triangles from surface tessellations).
--------------------------------------------------------
- Andrew Pearce, Alias Research, Toronto, like Downtown
- pearce%alias@csri.utoronto.ca | pearce@alias.UUCP
-------------------------------------------------------------------------------
Real3d, passed on by Juhana Kouhia (jk87377@tut.fi) and "Zap" Andersson
[This was an advertisement on some amiga board.]
Real 3D FEATURES
----------------
Real 3D is design and animation program for producing high quality, realistic
pictures of three dimensional objects. It provides an impressive set of
advanced features including:
Ray Tracing A ray tracing of Real 3D is strongly based on the
physical reality of the real world. Real 3D
produces pictures by simulating the laws of physics,
and consequently they represent reality with
astonishing accuracy.
Speed Innovative methods and new ray tracing algorithms
make Real 3D really fast. When using fastest ray tracing
mode, rendering time is typically from 1 to 15 minutes.
Hierarchical With Real 3D you can create hierarchical objects.
Object This means that objects you create can be made of
Oriented subobjects, and these subobjects may have their
Construction own substructure and so on. This kind of a tree
of Objects structure is well known in the context of disk
operating systems, in which you can create directories
inside directories. In Real 3D counterparts of these
directories are used to collect objects into logical
groups.
This kind of approach makes for example object
modifications extremely easy, because it is possible
to perform operations to logical entities. If you
want to copy a DOS directory, you don't have to
take care of the files and directories inside it.
In the same manner, you can stretch a complex object in
Real 3D as easily as one part of it.
True Solid Real 3D includes a true solid modeler. Solid model is the
Model most sophisticated way to represent three dimensional
objects. This modeling technique requires much computing
power and therefore it has earlier been used only in
environments, which are many times faster than Amiga.
Now it is possible to Amiga owners to reach all the
advantages of solid model, thanks to ultimate
optimizations carried out when developing Real 3D.
Smoothly Curved In addition to plane surfaces, Real 3D includes several
Surfaces curved surfaces, such as ball, cylinder, cone and
hyperboloid. This means that no matter how much you
enlarge a ball created by Real 3D, you don't find
any edges or corners on its surface. Furthermore,
this makes the program much faster. And what is most
important, the produced pictures look really good.
Boolean Solid model allows Boolean operations between objects.
Operations It is possible, for example, to split an object into
two pieces and move the pieces apart so that the inner
structure of the object is revealed.
Operations can also be done so that the properties of
the material of the target object are changed. By using
a brilliant cylinder one can drill a brilliant hole into
a matt object. Operations are a powerful way to create
and modify objects. Especially in modeling technical
objects these Boolean operations are indispensable.
Properties of A user of Real 3D is not restricted to use some basic
Surfaces surface brilliancies such as matt or shiny. Instead,
the light reflection properties can be freely adjusted
from absolute matt to totally mirrorlike, precisely
to the desired level.
Properties of Due to solid model, it is possible to create objects
Materials from different materials, which have suitable physical
properties. Just as surface brilliancy, also transparency
of a material can be adjusted without any restrictions.
Even light refraction properties are freely adjustable
so that it is possible to create optical devices from
glass lenses. These devices act precisely as their
real counterparts: a magnifying glass in Real 3D world
really magnifies!
Texture Mapping The texture mapping properties of Real 3D are not
restricted to a typical chequered pattern: Any IFF
picture can be used to paint objects. You can create
pictures with your favorite painting program as well
as with a video digitizer or a scanner. For example, by
digitizing a wood filament pattern, it is easy to create
wooden objects looking very realistic.
Pictures can be located precisely to desired places,
with desired sizes and directions.
Real 3D offers as many as seven texture mapping methods,
including parallel, cylinder, ball and spiral projections.
Light Sources Unlimited number of light sources of desired color and
brightness. The only restriction is amount of memory.
Animation As well as you can create single pictures, you can
Support create series of pictures, animations. Real 3D includes
also software for representing these animations
interactively. Animation representation can be directed
by a script language from ascii files or even from
keyboard. Instead of looping animations you can define
infinitely many ways to represent your pictures. Therefore
you can create animations from a small number of pictures
by displaying them various ways.
Rendering Real 3D includes several different rendering techniques:
Techniques a real time wireframe model, a hidden line wireframe model,
a high speed one light source ray tracing model,
a non-shadow-casting ray tracing model and a perfect ray
tracing model. You can select either a HAM display mode
with 4096 colors or a grey scale display mode offering
higher resolution. Also version with 16 million color
rendering (24 bits output) will become available during
November 1990.
Availability When writing this document (6.9.1990), marketing of
Real 3D is already started in Europe with a little
lower price than that of Sculpt 4D. The distribution
in the USA is not yet arranged. For further information
of Real 3D, please contact:
REALSOFT KY
KP 9, SF-35700 VILPPULA
FINLAND
Tel. +358-34-48390
--------
from "Zap" Andersson:
REAL3d ('member that?) is available (in Sweden at least) from:
KARLBERG & KARLBERG AB
FLADIE KYRKOVAEG
S-23700 BJARRED
SWEDEN
Phone: +46(0)46-47450
Phax: +46(0)46-47120
-------------------------------------------------------------------------------
Utah Raster Toolkit Patch, by Spencer Thomas
The first patch for the Utah Raster Toolkit version 3.0 is now available. The
patch file is urt-3.0.patch1, and is currently available from cs.utah.edu and
freebie.engin.umich.edu, and will soon be available from our other archive
sites (depending on how quickly the archive maintainers grab the patch file).
There are also slight changes to the files urt-img.tar and urt-doc.tar (in
particular, if you had trouble printing doc/rle.ps, this is fixed).
[p.s. there was also a fix to a getx11 bug for the Sun 4, which is
pub/urt-SUNOS4.1-patch.tar.Z on freebie and weedeater. --EAH]
Here is the description from the patch file:
Fixed core dump in rletogif, compile warnings in giftorle.
Minor update bug in getx11 fixed.
getx11 now exits if all its input files are bogus.
New program: rlestereo, combines two images (left and right eye)
into a red-blue (or green) stereo pair.
Configuration file for Interactive Systems 386/ix.
Minor fix to rleskel: ignore trailing garbage in an input image.
And the list of the current archive sites, from the urt.README file in
the ftp directory:
North America
East coast
weedeater.math.yale.edu 130.132.23.17 (pub/*)
Midwest
freebie.engin.umich.edu 35.2.68.23 (pub/*)
West
cs.utah.edu 128.110.4.21 (pub/*)
Europe
Sweden
alcazar.cd.chalmers.se 129.16.48.100 (pub/urt/urt-3.0.tar.Z)
maeglin.mt.luth.se 130.240.0.25 (pub/Utah-raster/*)
Australia
ftp.adelaide.edu.au 129.127.40.3 (pub/URT/*)
or, if you know what this means:
Fetchfile: sirius.ua.oz in URT
=Spencer W. Thomas EECS Dept, U of Michigan, Ann Arbor, MI 48109
spencer@eecs.umich.edu 313-936-2616 (8-6 E[SD]T M-F)
-------------------------------------------------------------------------------
NFF Shell Database, by Thierry Leconte (Thierry.Leconte@irisa.fr)
[Below is Thierry Leconte's code for an NFF version of the seashell generator
I listed last issue. He added some reasonable lights and a view (which I was
too lazy to do). I'll probably add it to the 3.0 version of the SPD. Setting
"steps" is similar to an SPD SIZE_FACTOR type control. You'll need the SPD to
compile and link this program. -- EAH]
#include <stdio.h>
#include <math.h>
#include "def.h"
#include "lib.h"
main(argc,argv)
int argc; char *argv[];
{
static double gamma = 1.0 ; /* 0.01 to 3 */
static double alpha = 1.1 ; /* > 1 */
static double beta = -2.0 ; /* ~ -2 */
static int steps = 600 ; /* ~number of spheres generated */
static double a = 0.15 ; /* exponent constant */
static double k = 1.0 ; /* relative size */
double r,x,y,z,rad,angle ;
int i ;
COORD4 back_color, obj_color ;
COORD4 center, light ;
COORD4 from, at, up ;
COORD4 sphere;
#define OUTPUT_FORMAT OUTPUT_CURVES
/* output viewpoint */
SET_COORD( from, 6, 60, 35 ) ;
SET_COORD( at, 0.0, 8.0, -15.0 ) ;
SET_COORD( up, 0.0, 0.0, 1.0 ) ;
lib_output_viewpoint( &from, &at, &up, 45.0, 0.5, 512, 512 ) ;
/* output background color - UNC sky blue */
SET_COORD( back_color, 0.078, 0.361, 0.753 ) ;
lib_output_background_color( &back_color ) ;
/* output light sources */
SET_COORD( light, -100.0, -100.0, 100.0 ) ;
lib_output_light( &light ) ;
/* set up sphere color */
SET_COORD( obj_color, 1.0, 0.8, 0.4 ) ;
lib_output_color( &obj_color, 0.8, 0.2, 100.0, 0.0, 1.0 ) ;
for ( i = -steps*2/3; i <= steps/3 ; ++i ) {
angle = 3.0 * 6.0 * M_PI * (double)i / (double)steps ;
r = k * exp( a * angle ) ;
sphere.x = r * sin( angle ) ;
sphere.y = r * cos( angle ) ;
/* alternate formula: z = alpha * angle */
sphere.z = beta * r ;
sphere.w = r / gamma ;
lib_output_sphere( &sphere, OUTPUT_FORMAT ) ;
}
}
-------------------------------------------------------------------------------
FTP list update and New Software, by Eric Haines, George Kyriazis
I posted my FTP site list for ray tracing related stuff, and a few people were
nice enough to write and update this list. The new list is posted after this
note from George Kyriazis at RPI (his site has the friendliest login I've ever
seen):
--------
iear.arts.rpi.edu [128.113.6.10]:
There was an article in IEEE CG&A a while ago from Sandia National Labs (the
guy's name was Mareda I think) that uses fourier transforms and digital
filters to create wave height fields from white noise. What I have in the
directory is an implementation of this algorithm and a program that raytraces
it on the AT&T Pixel Machine.
A list of what exists in there follows:
graphics-gems: source code to Glassner's Graphics Gems book.
ray-tracing-news:What else?
wave: Rendering of ocean waves using fft. (Mareda, et. al.)
coldith: conversion from my image format to sun rasterfiles
and dithering from 32 or 24 bit -> 8 bit rasterfiles.
drt: A ray-tracer from the Netherlands by Marinko Laban
gk: A distributed raytracer by me.
microray: DBW_uRAY by David Wecker
mtv: Well, you know what this is. It probably is an old version.
non-completed-OO-modeler:
Something I was working on. It barely works, but I put
it out there just for the fun of it.
ohta: Masataka Ohta's constant time ray-tracer;
with a few improvements.
pxm-and-vmpxm-ray.etc:
Two raytracers for the AT&T Pixel Machine. The second
one uses some virtual memory code to store more objects.
The VM source is included also.
qrt: Well, QRT!
rayshade: Rayshade 2.21 by Craig Kolb.
I hope I'll have a few anonymous ftp sessions after this.. :-)
--------
Corrected FTP site list for ray tracing related material:
weedeater.math.yale.edu [130.132.23.17]: /pub - *Rayshade 3.0 ray tracer*,
*color quantization code*, RT News, *new Utah raster toolkit*, newer
FBM, *Graphics Gems code*. Craig Kolb <kolb@yale.edu>
cs.uoregon.edu [128.223.4.13]: /pub - *MTV ray tracer*, *RT News*, *RT
bibliography*, other raytracers (including RayShade, QRT, VM_pRAY),
SPD/NFF, OFF objects, musgrave papers, some Netlib polyhedra, Roy Hall
book source code, Hershey fonts, old FBM. Mark VandeWettering
<markv@acm.princeton.edu>
hanauma.stanford.edu [36.51.0.16]: /pub/graphics/Comp.graphics - best of
comp.graphics (very extensive), ray-tracers - DBW, MTV, QRT, and more.
Joe Dellinger <joe@hanauma.stanford.edu>
freedom.graphics.cornell.edu [128.84.247.85]: *RT News back issues, source
code from Roy Hall's book "Illumination and Color in Computer
Generated Imagery", SPD package, Heckbert/Haines ray tracing article
bibliography, Muuss timing papers. [CURRENTLY NOT AVAILABLE]
alfred.ccs.carleton.ca [134.117.1.1]: /pub/dkbtrace - *DKB ray tracer*.
David Buck <david_buck@carleton.ca>
uunet.uu.net [192.48.96.2]: /graphics - RT News back issues (not complete),
other graphics related material.
iear.arts.rpi.edu [128.113.6.10]: /pub - *Kyriazis stochastic Ray Tracer*.
qrt, Ohta's ray tracer, other RT's (including one for the AT&T Pixel
Machine), RT News, Graphics Gems, wave ray tracing using digital
filter method. George Kyriazis <kyriazis@turing.cs.rpi.edu>
life.pawl.rpi.edu [128.113.10.2]: /pub/ray - *Kyriazis stochastic Ray Tracer*.
George Kyriazis <kyriazis@turing.cs.rpi.edu>
xanth.cs.odu.edu [128.82.8.1]: /amiga/dbw.zoo - DBW Render for the Amiga (zoo
format). Tad Guy <tadguy@cs.odu.edu>
munnari.oz.au [128.250.1.21]: */pub/graphics/vort.tar.Z - CSG and algebraic
surface ray tracer*, /pub - DBW, pbmplus. David Hook
<dgh@munnari.oz.au>
cs.utah.edu [128.110.4.21]: /pub - *Utah raster toolkit*. Spencer Thomas
<thomas@cs.utah.edu>
gatekeeper.dec.com [16.1.0.2]: /pub/DEC/off.tar.Z - *OFF objects*,
/pub/misc/graf-bib - *graphics bibliographies (incomplete)*. Randi
Rost <rost@granite.dec.com>
abcfd20.larc.nasa.gov [128.155.23.64]: /amiga - DBW,
/usenet/comp.{sources|binaries}.amiga/volume90/applications -
DKBTrace 2.01. Tad Guy <tadguy@cs.odu.edu>
expo.lcs.mit.edu [18.30.0.212]: contrib - *pbm.tar.Z portable bitmap
package*, *poskbitmaptars bitmap collection*, *Raveling Img*,
xloadimage. Jef Poskanzer <jef@well.sf.ca.us>
venera.isi.edu [128.9.0.32]: */pub/Img.tar.z and img.tar.z - some image
manipulation*, /pub/images - RGB separation photos. Paul Raveling
<raveling@venera.isi.edu>
ftp.ee.lbl.gov [128.3.254.68]: *pbmplus.tar.Z*.
ucsd.edu [128.54.16.1]: /graphics - utah rle toolkit, pbmplus, fbm, databases,
MTV, DBW and other ray tracers, world map, other stuff. Not updated
much recently.
okeeffe.berkeley.edu [128.32.130.3]: /pub - TIFF software and pics. Sam
Leffler <sam@okeeffe.berkeley.edu>
irisa.fr [131.254.2.3]: */iPSC2/VM_pRAY ray tracer*, /NFF - many non-SPD NFF
format scenes. Didier Badouel <badouel@irisa.irisa.fr>
surya.waterloo.edu [129.97.129.72]: /graphics - FBM, ray tracers
vega.hut.fi [128.214.3.82]: /graphics - RTN archive, ray tracers (MTV, QRT,
others), NFF, some models
netlib automatic mail replier: UUCP - research!netlib, Internet -
netlib@ornl.gov. *SPD package*, *polyhedra databases*. Send one
line message "send index" for more info.
UUCP archive: avatar - RT News back issues. For details, write Kory Hamzeh
<kory@avatar.avatar.com>
======== USENET cullings follow ===============================================
[deleted from USENET, since you've probably seen them. Actually, I've added
some anecdotes, some comments, etc etc, so feel free to FTP the full issue
from one of the sites above (the issue is called RTNv3n4) sometime after
October 5th. -EAH]