cnsy@vax5.CIT.CORNELL.EDU (11/21/89)
_ __ ______ _ __
' ) ) / ' ) )
/--' __. __ , --/ __ __. _. o ____ _, / / _ , , , _
/ \_(_/|_/ (_/_ (_/ / (_(_/|_(__<_/ / <_(_)_ / (_</_(_(_/_/_)_
/ /|
' |/
"Light Makes Right"
October 13, 1989
Volume 2, Number 7
Compiled by Eric Haines, 3D/Eye Inc, 2359 Triphammer Rd, Ithaca, NY 14850
NOTE ADDRESS CHANGE: wrath.cs.cornell.edu!eye!erich
[distributed by Michael Cohen <m-cohen@cs.utah.edu>, but send
contributions and subscriptions requests to Eric Haines]
All contents are US copyright (c) 1989 by the individual authors
Archive locations: anonymous FTP at cs.uoregon.edu (128.223.4.1) and at
freedom.graphics.cornell.edu (128.84.247.85), /pub/RTNews
Contents:
Introduction
New People and Address Changes
Solid Surface Modeler Information, by Eric Haines
Minimum Bounding Sphere Program, by Marshall Levine
Parallelism & Modeler Info Request, by Brian Corrie
======== USENET cullings follow ========
Ray Tracer Available, by Craig Kolb
Source from Roy Hall's Book, by Tim O'Connor
More on Texture Mapping by Spatial Position, by Paul Lalonde
Procedural Bump-mapping Query, by Prem Subrahmanyam
Ray Tracer Performance on Machines,
by Gavin A. Bell, Phil Dykstra, Steve Lamont
Projective Mapping Explanation, by Ken "Turk" Turkowski
Intersection Calculation Problem Request, Jari Toivanen
Mathematical Elements for Computer Graphics - Call for Errata,
by David Rogers
Raytracing on NCUBE Request, by Ping Kang Hsiung
Intersection Between a Line and a Polygon (UNDECIDABLE??),
by Dave Baraff, Tom Duff
-------------------------------------------------------------------------------
Introduction
It's October, the time when the air turns chilly, the leaves turn red, and
people's minds turn towards releasing a public domain version of their ray
tracer. Holy smokes there's a lot of them coming out lately! This month
Craig Kolb's ray tracer has become available, along with the first PD ray
tracer from Australia, by David Hook. Paul Lalonde mentions that his will be
coming out soon, and will include spline surfaces. Also, David Kirk and Jim
Arvo have created a ray tracer which they used in their workshop in Australia,
and which may be released to the general public soon. Other code that has
been made available is that printed in Roy Hall's _Illumination and Color in
Computer Generated Imagery_ book.
Next month I hope to collect various timing information from all sorts of
ray tracers on all sorts of machines. I hope to do a "trace-off" sometime
soon, comparing MTV's, Craig's, DBW, QRT, ART, mine, and any others I can get
up and running. If anyone else has any timings or observations on performance
of ray tracers and various machines, please send them to me.
-------------------------------------------------------------------------------
New People and Address Changes
David Hook
dgh@munnari.OZ.AU
Dept. Of Engineering Computer Resources
University Of Melbourne
Parkville, Vic, 3052
Australia
G'day.
Our major area of interest in ray tracing is CSG modeling and we have a
locally developed ray tracer which is a step towards this, as a department we
are also involved with the Faculty of Architecture at this University, so we
are starting to look at special effects somewhat more seriously than before.
This has also led to a greater interest in acceleration techniques.
Personally, I am currently doing a masters degree in the area of CSG and ways
of introducing patches into the model. The rendering technique being used is
ray tracing.
[And a further note from David Hook:]
The mailing list has been set up on munnari, so if you send it to
rtnews@munnari.OZ.AU, it will (should) travel around Oz to the people who want
it. I am asking people who subscribe if they wish to be on the contact list,
etc...
As a bit of additional info, I have written a ray-tracer which does CSG and
renders algebraic surfaces, (ala Pat Hanrahan), although in this case it's
built around Sturm Sequences and we occasionally use CSG to take
cross-sections of the surfaces. The interest in algebraic surfaces began
because a friend of mine was struggling with a 6th order surface known as the
Hunt Surface, getting a good feel for the cusps on it was turning out to be
awful using polygonal subdivision. In any case there is a public domain
version of all this sitting in pub on munnari.OZ.AU (128.250.1.21) which can
be got by anonymous ftp. The file is vort.tar.Z. Knowing a bit more about
the whole business now, it's a bit of an embarrassment! Still it may be of
interest to someone and constructive criticism is always welcome.
[From a README file in his ray tracing distribution:]
By the by, for people who are interested, there are an excellent series of
papers on ray tracing and computer graphics in general published in the NATO
ASI Series of books. The volume in question is in Vol. 40, series F, and is
titled "Theoretical Foundations of Computer Graphics and CAD". It was
published in 1988 Springer-Verlag. Roman Kuchkuda's paper in it "An
Introduction To Ray Tracing", would be the best introductory paper we have
seen to date. Apart from that it was the first paper we found that actually
said what a superquadric was!
--------
NAME: Hench, Stephen D. SNAIL MAIL: 2621-C Stewart Drive
E MAIL: hench@csclea.ncsu.edu Raleigh, NC 27603
BRIEF: Undergrad in Mathematics and Computer Science at NCSU.
Interested in ray tracing (would I want to subscribe
if I wasn't?), radiosity, and rendering in general.
--------
Marshall Levine
136 1937 Hall Wilson College
Princeton University
Princeton, NJ 08544
(609) 734-6061
Home:
Marshall Levine
5212 Louise Avenue
Encino, California 91316
(818) 995-6528
(818) 906-7068
E-mail:
(1) mplevine@phoenix.princeton.edu or:
(2) mplevine@gauguin.princeton.edu or:
(3) mplevine@bogey.princeton.edu
My main interests are helicopters and computer graphics. Within graphics, I
am interested in animation and motion control. While I think it is great to
see a ray-traced magnifying glass sitting on top of a cicuit board, I would
rather see the magnifying glass fly smoothly over a spinning board while the
camera flies smoothly through the scene. I am currently designing a flexible
graphics language with a friend of mine, Chris Williams (Princeton U. '92).
If anyone is interested, I can say more about that later.
--------
Cornell Program of Computer Graphics
A ray tracing mailing list has been set up by Tim O'Connor:
ray-tracing-news@wisdom.graphics.cornell.edu
Program of Computer Graphics
120 Rand Hall
Cornell University
Ithaca, NY 14853
People on this list who've already been intro'ed here include: Roy Hall,
Mark Reichert, Ben Trumbore, and Tim O'Connor.
New people and brief bio sketches:
Wash Wawrzynek - paw@squid.graphics.cornell.edu
Current interest are user interfaces and visualization for computational
mechanics.
--------
Len Wanger - lrw@freedom.graphics.cornell.edu
My sketch is on a piece of paper, but my interests are: I am a graduate
student in the department of computer graphics at Cornell University. I am
interested in modeling and visual perception.
--------
Filippo Tampieri - fxt@freedom.graphics.cornell.edu
Areas of interest: parallel/distributed ray tracing, fast algorithms for ray
tracing.
--------
Ricardo Pomeranz - rxp@venus.graphics.cornell.edu
Interests: constructive solid geometry and rendering
--------
Paul Wanuga - phw@neptune.graphics.cornell.edu
Masters student at Cornell's Computer Graphics Lab. Interests - rendering
realistic complex environments in realistic times.
--------
Kathy Kershaw - kershaw@hope.graphics.cornell.edu
I'm Kathy Kershaw. I did the ray tracing thing once. Maybe it'll have
something to do w/ my master's thesis; maybe not.
--------
Colin Summers - colin@scarpa.graphics.cornell.edu
Just recently interested in computer graphics and heading into the abyss from
the architecture side, I have a background in personal computers and spent a
year out of the design studio to computer consult in Manhattan. Glad to be
back in the world of academia. As soon as someone comes across with a
Macintosh like text processor for xWindows, let me know.
--------
Ted Himlan - thh@squid.Graphics.Cornell.EDU
Color science, radiometric measurement, array camera.
interest: detailed measurements on an environment
for comparison to simulation.
--------
Julie O'Brien Dorsey - job@hope.graphics.cornell.edu
Computer aided design applications, radiosity, lighting design
--------
Francois Sillion - fxs@bruno.graphics.cornell.edu
I am currently on a Post-Doc position at Cornell, after having completed my
PhD at the 'Ecole Normale Superieure' in Paris, France, where my work included
the development of a two-pass method for lighting calculations, combining ray
tracing and radiosity.
My interests are illumination models (local and global), animation and
interactivity.
-------------------------------------------------------------------------------
Solid Surface Modeler Information, by Eric Haines
The Solid Surface Modeler from NASA finally came out. The disappointing news
is that even though it's "a non-profit unit of the University of Georgia," the
thing is priced at $1250 for a cartridge tape and documentation (which is $43
separately). The reason I mention it is this newsletter is that it was used
for some rather elaborate databases that were both modeled and ray traced on
the AT&T Pixel Machine. Unfortunately, it's unclear whether the Pixel Machine
driver program is included in the distribution. The modeler itself sounds
reasonable, source code comes on the tape, and there seems to be no
restrictions on the use of the software. It's a pity that it's pricey when
compared to, say, FSF stuff, but I guess someone has to pay for those glossy
advertisement folders.
From their literature: "SSM was written in standard C with Silicon Graphic's
Iris Graphics Library calls and AT&T PicLib calls.... The program is
available for the Silicon Graphics IRIS workstation running version 3.1 of
IRIX, and a Sun Workstation with AT&T PXM964 running 4.2 BSD."
For more information contact:
COSMIC
The University of Georgia
382 East Broad Street
Athens, GA 30602
(404)-542-3265
-------------------------------------------------------------------------------
Minimum Bounding Sphere Program, by Marshall Levine
I think you will be interested in the following program. It is a
minimum-bounding-sphere program. As the explained in the header comments, the
main algorithm seems to solve the problem in linear time. Please let me know
what you think.
{ clusters.p
Written by Marshall Levine (Princeton University '92)
e-mail: mplevine@phoenix.princeton.edu
Algorithm designed by Marshall Levine and Chris Williams (Princeton U. '92)
This program searches through a 3-dimensional space of randomly distributed
points for a cluster of 10 stars within the smallest radius possible.
I first implemented a "pri" list. This is a linked list of real numbers
(representing distances). The list is kept in order. However, when a number
that would go farther into the list than the number of points per sphere
(NUMINSPHERE) tries to go into the list, the insert procedure stops it. This
is done because the distance is useless. For example, if NUMINSPHERE is 5 and
a number would be inserted into the 7th slot in the list, it is not inserted.
The minimum radius of a sphere with 5 points would be determined by the 5th
element of the list (not including the header), so any number inserted after
the 5th element is useless and is therefore not inserted. If there are not
NUMINSPHERE elements in the pri, then there are not enough points to fill the
sphere.
The brute-force algorithm loops through every point in space. For each point,
the algorithm finds the distance between that point and every other point and
puts that distance into the pri. When all points have been compared against
this point, the NUMINSPHERE'th element is taken to be the minimum radius of a
sphere centered at this point containing NUMINSPHERE points. However, points
are not compared against themselves, so the exact number of comparisons is
N^2-N, making this an N^2 algorithm.
The efficient algorithm designed by Chris Williams and me divides the space
into a 3-dimensional grid. If the grid is divided into NUMPOINTS/NUMINSPHERE
sectors, then at least one of the sectors must have at least NUMINSPHERE
points. Now, make spheres with the same volume as the sectors. At least one
sphere surrounding one point will have at least NUMINSPHERE points. It turns
out that the tradeoff between fewer computations and more overhead is
minimized by choosing the grid to have enough sectors such that each sector is
r/2 on each side (where r is the radius of the aforementioned sphere). Our
algorithm starts with a sphere radius equal to the distance from one corner of
the unit cube to another (3^.5). Given the first point in the list, we
compare that point against every other point in sectors touching the sphere
(In this case, every other point in space!) By storing the distances and then
taking the NUMINSPHERE'th number from the pri list, as in the brute algorithm,
we frequently reduce the size of the sphere. Then, we check the next point
with the new, smaller sphere size and continue in this way until we have
tested every point. As we go along, the minimum sphere size keeps shrinking
until for any given point, we only check a few neighboring sectors, if any.
In practice, this radius shrinks so quickly that the algorithm displays LINEAR
BEHAVIOR!
NOTE: This program was written for clarity, not for efficiency. If it is to
be used in any real applications, there are many ways to speed it up.
Bruteforce: Our algorithm:
(Average of 3 runs)
Points: #Comparisons: comps/points: #Comparisons: comps/points:
50 2450 49.000 958 19.160
75 5550 74.000 1241 16.547
100 9900 99.000 2111 21.110
150 22350 149.000 2785 18.567
200 3689 18.445
250 5120 20.480
300 6010 20.033
350 7149 20.426
400 7658 19.145
600 11404 19.007
800 16781 20.976
1000 20438 20.438
Testing 50 points.
Brute-force:
Best sphere: 0.3067962678
Number of comparisons: 2450
Efficient Algorithm:
Best sphere: 0.3067962678
Number of comparisons: 946
%time cumsecs #call ms/call name
31.6 0.10 1 100.01 _brutecluster <====
10.5 0.18 1 33.34 _elegantcluster <====
5.3 0.25 101 0.17 _clearprilist
5.3 0.27 581 0.03 _insertprilist
5.3 0.28 1 16.67 _makespace
Testing 300 points.
Brute-force:
Best sphere: 0.1569231423
Number of comparisons: 89700
Efficient Algorithm:
Best sphere: 0.1569231423
Number of comparisons: 5617
%time cumsecs #call ms/call name
44.2 3.27 1 3267.00 _brutecluster <====
2.9 6.82 1 216.69 _elegantcluster <====
1.1 7.00 2358 0.04 _insertprilist
0.2 7.33 601 0.03 _clearprilist
0.0 7.38 1 0.00 _makespace
}
{==========================================================================}
program clusters(input,output);
const
MAXNUMPOINTS = 501; { The maximum # of points we can handle }
NUMINSPHERE = 10; { # stars to find inside sphere }
INFINITY = 999999.9; { Larger than largest distance possible }
MAXUSESPACE = 20; { Maximum length per edge of space-grid }
PI = 3.1415926535;
type
datatype = real;
point = record { The type of a point }
x : real;
y : real;
z : real;
data : datatype;
end;
ptr = ^node;
node = record { Linked list for a distances list called "pri" }
data : real;
next : ptr;
end;
sptr = ^spacenode; { Linked list for each sector in the space-grid }
spacenode = record
index : integer; { Stores index of that point in points[] }
next : sptr;
end;
var
rndnm : integer; { Needed for the random number generator }
points : array [1..MAXNUMPOINTS] of point; { All points in space }
listhead : ptr; { List head for distances list called "pri" }
space : array[0..MAXUSESPACE, 0..MAXUSESPACE, 0..MAXUSESPACE] of sptr;
{ The space-grid (hereafter called 'grid') }
spacesize, usespace : integer; { Size per edge of grid }
NUMPOINTS : integer; { The number of points we have in space }
{ **************** Support routines for random generators ************** }
procedure seed; { Seed the random number generator }
begin
writeln('seed:');
readln(rndnm);
end;
function rndom(scale : integer) : real; { Make random real from 0 to scale }
begin
rndnm := abs(abs((rndnm*921+1)) mod 32749);
rndom := (rndnm*scale/32749)
end;
procedure randompoint(var pt : point); { Generate a random point within }
begin { a unit cube. }
pt.x := rndom(1);
pt.y := rndom(1);
pt.z := rndom(1)
end;
procedure generatepoints; { Generate NUMPOINTS points in space }
var x : integer;
begin
for x := 1 to NUMPOINTS do
randompoint(points[x])
end;
{ *************** Support routines for the "pri" list ******************** }
procedure initprilist; { Initialize the pri list }
begin
new(listhead);
listhead^.data := 0.0;
new(listhead^.next);
listhead^.next^.data := INFINITY;
listhead^.next^.next := nil
end;
procedure clearprilist; { Clear the pri list }
var p,oldp : ptr;
begin
p := listhead;
while p <> nil do
begin
oldp := p;
p := p^.next;
dispose(oldp)
end;
new(listhead);
listhead^.data := 0.0;
new(listhead^.next);
listhead^.next^.data := INFINITY;
listhead^.next^.next := nil
end;
procedure insertprilist(r : real); { Insert a distance into pri list }
var p,oldp,temp : ptr; { "pri" is just a linked list of distances }
x : integer; { kept in low -> high order. The catch is }
begin { that if a number should be inserted after }
x := 1; { the NUMINSPHERE'th node, we don't bother }
p := listhead^.next; { inserting it, because it isn't in the }
oldp := listhead; { smallest sphere with NUMINSPHERE points. }
while (r > p^.data) and (x <= NUMINSPHERE) do
begin
oldp := p;
p := p^.next;
x := x + 1
end;
if x <= NUMINSPHERE then
begin
new(temp);
temp^.data := r;
temp^.next := p;
oldp^.next := temp
end
end;
function getbiggestinsphere : real; { Returns value of the NUMINSPHERE'th }
var x : integer; { element in pri list, or INFINITY }
p : ptr; { if the list isn't that long. }
begin
x := 1;
p := listhead^.next;
while (x < NUMINSPHERE) and (p <> nil) do
begin
x := x + 1;
p := p^.next
end;
if (x < NUMINSPHERE) or (p = nil) then getbiggestinsphere := INFINITY
else getbiggestinsphere := p^.data
end;
procedure printprilist; { Print the pri list, for debugging }
var p : ptr;
begin
p := listhead; { DO print the head }
while p <> nil do
begin
writeln(p^.data:15:10);
p := p^.next
end;
writeln('nil')
end;
{ ******************* Miscellaneous support routines ******************** }
procedure printpoint(pt : point); { Print out a point }
begin
writeln('(',pt.x:8:5,',',pt.y:8:5,',',pt.z:8:5,')')
end;
function cube(x : real) : real; { Return cube root of a number }
begin
cube := exp((1/3)*ln(x))
end;
{ *********************** Brute Force algorithm ************************* }
procedure brutecluster; { Find minimum sphere containing NUMINSPHERE }
{ points by testing the distance between }
{ every point. }
var distx,disty,distz,dist : real; { Find distance between two points }
bestsphere,trysphere : real; { Find minimum sphere }
numcomps : integer; { # comparisons }
thispoint,againstpoint : integer; { Counters }
begin
clearprilist; { Kill the priority list }
bestsphere := INFINITY;
numcomps := 0;
for thispoint := 1 to NUMPOINTS do { Test every point... }
begin
clearprilist;
for againstpoint := 1 to NUMPOINTS do { ...against every other point }
if thispoint <> againstpoint then { Don't compare point against self}
begin
distx := points[thispoint].x - points[againstpoint].x;
disty := points[thispoint].y - points[againstpoint].y;
distz := points[thispoint].z - points[againstpoint].z;
dist := sqrt(distx*distx + disty*disty + distz*distz);
numcomps := numcomps + 1;
if dist < bestsphere then { If dist less than smallest sphere,}
insertprilist(dist) { insert distance into pri list }
end;
trysphere := getbiggestinsphere; { Get 'NUMINSPHERE'th item from list }
if trysphere < bestsphere then { If this radius is the smallest yet,}
bestsphere := trysphere; { then remember it. }
end;
writeln('Brute-force:');
writeln(' Best sphere: ',bestsphere:15:10);
writeln(' Number of comparisons: ',numcomps:8)
end;
{ **************************** My algorithm *********************** }
procedure makespace; { Build the space-grid. See documentation at }
var x,y,z : integer; { beginning of program for details. }
temp : sptr;
thispoint : integer;
begin
spacesize := trunc(cube(8*PI*NUMPOINTS/NUMINSPHERE));
usespace := spacesize-1;
if usespace > MAXUSESPACE then writeln('****** NOT ENOUGH MEMORY FOR GRID');
for x := 0 to usespace do
for y := 0 to usespace do
for z := 0 to usespace do
space[x,y,z] := nil; { Clear the grid }
for thispoint := 1 to NUMPOINTS do { Go through every point... }
begin
new(temp);
temp^.index := thispoint;
x := trunc(points[thispoint].x * spacesize);
y := trunc(points[thispoint].y * spacesize);
z := trunc(points[thispoint].z * spacesize);
temp^.next := space[x,y,z]; { Put this point into proper }
space[x,y,z] := temp; { sector in grid. }
end
end;
procedure elegantcluster; { Find smallest sphere containing NUMINSPHERE }
{ points by looping through every point, }
{ checking ROUGHLY only the points within }
{ a radius less than or equal to the }
{ minimum radius found so far. }
var bestsphere,trysphere : real;
xmin,xmax,ymin,ymax,zmin,zmax : integer; { Dimensions of box to check }
thispoint : integer; { The current point to test against }
x,y,z : integer; { The current grid we are testing }
distx,disty,distz,dist : real; { For computing distances }
numcomps : integer; { # comparisons }
cpindex : sptr; { Pointer into point list for a grid sector }
begin
makespace;
bestsphere := 1.732050808; { Start with radius of distance from one }
numcomps := 0; { corner of unit cube to other: 3^.5 }
for thispoint := 1 to NUMPOINTS do { Loop for every point }
begin
clearprilist;
xmin := trunc((points[thispoint].x - bestsphere) * spacesize);
xmax := trunc((points[thispoint].x + bestsphere) * spacesize);
ymin := trunc((points[thispoint].y - bestsphere) * spacesize);
ymax := trunc((points[thispoint].y + bestsphere) * spacesize);
zmin := trunc((points[thispoint].z - bestsphere) * spacesize);
zmax := trunc((points[thispoint].z + bestsphere) * spacesize);
if xmin < 0 then xmin := 0;
if ymin < 0 then ymin := 0; { Get dimensions of box }
if zmin < 0 then zmin := 0; { containing every sector in }
if xmax > usespace then xmax := usespace; { grid that we want to check }
if ymax > usespace then ymax := usespace; { against the current point }
if zmax > usespace then zmax := usespace;
for x := xmin to xmax do
for y := ymin to ymax do
for z := ymin to ymax do { Loop through every sector in this box }
begin
cpindex := space[x,y,z];
while cpindex <> nil do { Test against every point in this sector}
begin
if thispoint <> cpindex^.index then { Don't test point against }
begin { itself. }
distx := points[thispoint].x - points[cpindex^.index].x;
disty := points[thispoint].y - points[cpindex^.index].y;
distz := points[thispoint].z - points[cpindex^.index].z;
dist := sqrt(distx*distx + disty*disty + distz*distz);
numcomps := numcomps + 1;
if dist < bestsphere then { If dist less than smallest sphere}
insertprilist(dist) { insert distance into pri list }
end;
cpindex := cpindex^.next { Get next point in this sector }
end
end;
trysphere := getbiggestinsphere;
if trysphere < bestsphere then
bestsphere := trysphere
end;
writeln('Efficient Algorithm:');
writeln(' Best sphere: ',bestsphere:15:10);
writeln(' Number of comparisons: ',numcomps:8)
end;
begin
seed;
writeln('How many points?');
readln(NUMPOINTS);
if NUMPOINTS < NUMINSPHERE then
writeln('***** Must have at least ',NUMINSPHERE:1,' points.')
else
begin
writeln('Testing ',NUMPOINTS:1,' points.');
initprilist;
generatepoints;
brutecluster;
elegantcluster
end
end.
-------------------------------------------------------------------------------
Parallelism & Modeler Info Request, by Brian Corrie
...!uw-beaver!uvicctr!bcorrie bcorrie@uvicctr.UVic.ca
[soon to be a posting on USENET, but it hadn't reached my node yet.]
Howdy folks....
It's survey time again, and I would appreciate your participation in this
version of twenty questions.
I am interested in parallel algorithms for ray tracing, and I am curious about
a couple of things. Please note that I have most of the "standard references"
that get cited in the literature, but I am interested in some of the OTHER
stuff that is out there.
The papers that I have:
Cleary et al. "Multiprocessor Ray Tracing", Internal Report, 83/128/17,
Department of Computer Science, University of Calgary, Calgary, Alberta,
Canada.
Dippe et al "An Adaptive Subdivision Algorithm and Parallel Architecture for
Realistic Image Synthesis", Computer Graphics, Volume 18, Number 3.
Gaudet et al "Multiprocessor Experiments for High Speed Ray Tracing", ACM
TOG, Volume 7, Number 3.
etc.....
What I am interested in are references to some of the goodies that are out
there in the real world. Are there any papers on the hardware Pixar uses.
How about the AT&T pixel machine, the Connection Machine (there is a piece on
it in Scientific American, Volume 256, Number 6 that I already have), and
other bizarre architectures. Dave Jevans from the University of Calgary (Hi
Dave, remember me? I met you at SIGGRAPH this year) mentioned at one point he
implemented some stuff on a BBN Butterfly (I think). Any more info on that
Dave? Did you write it up? Anybody else doing anything similar?
Here is the info I want....
1) What architecture do you run on?
2) Parallel, vectorized etc?
For parallel systems:
3) How many processors do you use?
4) How tightly coupled are they?
5) Do you perform any load balancing, and if so how?
6) Architectural requirements (memory/node, communications etc)?
7) Anything else you can think of that might be useful.
Thanks in advance for any help you can give me. Replies by email are of
course the best route to take, but I read comp.graphics every morning, so a
reply here will be seen. I will post a summary to the net if I get enough
information.
========
Question number two....
This should be quick and easy. I would like to know what kind of modelling
software people use out there in the real world.
We have all seen the pretty pictures, but how do they get created? I would
appreciate a quick or not so quick review of what kind of software is used at
your site to model 3D scenes.
For those of you in the RT News mailing list and don't read the net like I do,
I will send a copy of both this and the summary to Eric.
Thanks,
Brian
======== USENET cullings follow ===============================================
Ray Tracer Available, by Craig Kolb
From: craig@weedeater.math.yale.edu
Newsgroups: comp.graphics
Organization: Math Department, Yale University
All of this talk of solid texturing and the like has convinced me to pull
together my raytracer for public consumption. Although I'm calling this a
beta release, relatives of this version of rayshade have been making pretty
pictures for about a year now. For examples, see slides 32 and 57 from the
SIGGRAPH '89 technical slide set and slides 67/68 from the stereo slide set.
If there's enough interest, I'll post rayshade to comp.sources.unix once the
bugfixes stop rolling in.
[I would like to add that Craig's ray tracer is fairly nice, and most of the
portability problems and minor bugs have been fixed since its release. Its
input language is much more full featured than NFF (which, I'll say again, was
made only for testing ray tracers, not photorealism) and looks more mainstream
than some of the other public domain ray tracers I've seen. If you're looking
for a reasonable input language, check his out. His latest and greatest
version (i.e. newer that 2.21) might be available via ftp by now. - EAH]
--
Rayshade, a raytracing program, is available for "Beta" testing. Rayshade
reads a multi-line ASCII file describing a scene to be rendered and produces a
Utah Raster RLE format file of the raytraced image.
Features:
Primitives:
boxes
cones
cylinders
height fields
planes
polygons
spheres
triangles (flat- or Phong-shaded)
[he forgot to mention there are also superquadrics! - EAH]
Composite objects
Point, directional, and extended (area) light sources
Solid texturing and bump mapping of primitives, objects, and
individual instances of objects
Antialiasing through adaptive supersampling or "jittered" sampling
Arbitrary linear transformations of primitives,
instances of objects, and texture/bump maps
Use of uniform spatial subdivision and/or hierarchy of
bounding volumes to speed rendering
Options to facilitate rendering of stereo pairs
Support for the Linda parallel programming language
An awk script is provided to translate NFF format scripts to rayshade format.
Rayshade is written in C with parsing support provided through lex and yacc.
The C, lex and yacc files comprise approximately eight thousand lines of
code. Sites without lex and yacc can make use of the C source files produced
by lex and yacc which are included in this distribution.
Rayshade has been tested on a number of UNIX-based machines, including
Vaxes, Sun Workstations, Iris 4D Workstations, Encore Multimax, AT&T 3B2/310,
Cray XMP, and IBM RTs. In addition, support is provided for the Amiga using
the Aztec C compiler.
Rayshade makes use of the Utah Raster toolkit, a package consisting of a
large number of useful image manipulation programs, test images, and a
library to read and write images written using the toolkit's RLE format. The
toolkit is available via anonymous FTP from cs.utah.edu or from
weedeater.math.yale.edu.
Those sites that cannot or do not want to use the Utah Raster toolkit can
make use of a compile-time option to produce images written using a generic
file format identical to that used in Mark VandeWettering's "MTV" raytracer.
This version of rayshade is a "beta" release. The first "real" release will
include an updated manual page and additional documentation as well as
any bugfixes or extensions born out of this release.
Rayshade is copyrighted in a "Gnu-like" manner.
Rayshade is available via anonymous ftp from weedeater.math.yale.edu
(192.26.88.42) in pub/Rayshade.2.21.tar.Z. The Utah Raster toolkit
is available in pub/UtahToolkit.tar.Z.
-------------------------------------------------------------------------------
Source from Roy Hall's Book, by Tim O'Connor
From: toc@batcomputer.tn.cornell.edu
Newsgroups: comp.graphics
Straight from the dragon's mouth (so to speak) comes the source from
"Illumination and Color in Computer Generated Imagery" by Roy Hall. It's now
available via anonymous ftp from:
freedom.graphics.cornell.edu (128.84.247.85)
It's under pub/Hall and comes in two files: 1) README (of course) which also
contains some code necessary to convert 2) code.tar.Z.a which contains the
actual code. So, as always, read README first.
Those of you who do not have ftp access may wish to drop me a short line (a
Subject: of "gimme roy's source" is adequate). If there's enough interest
I'll post to this group, if not I'll (shudder!) attempt to mail it right to
you.
Also of interest on freedom are the Ray Tracing News archives (under
pub/RTNews) and the Xcu Widget Set. (Sorry, this code available only in
stores, no mailing.)
fishing in McElligot's Pool,
to'c
-------------------------------------------------------------------------------
I decided to repost the above two notes again, since they are very worthwhile.
For the rest of the USENET cullings, check the archives.