cnsy@vax5.CIT.CORNELL.EDU (11/21/89)
_ __ ______ _ __
' ) ) / ' ) )
/--' __. __ , --/ __ __. _. o ____ _, / / _ , , , _
/ \_(_/|_/ (_/_ (_/ / (_(_/|_(__<_/ / <_(_)_ / (_</_(_(_/_/_)_
/ /|
' |/
"Light Makes Right"
September 20, 1989
Volume 2, Number 6
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 location: anonymous FTP at cs.uoregon.edu (128.223.4.1), /pub/RTNews
Contents:
Introduction
New People and Address Changes
Q&A on Radiosity Using Ray Tracing, Mark VandeWettering & John Wallace
Dark Bulbs, by Eric Haines
MTV Ray Tracer Update and Bugfix, by Mark VandeWettering
DBW Ray Tracer Description
======== USENET cullings follow ========
Wanted: Easy ray/torus intersection, by Jochen Schwarze
Polygon to Patch NFF Filter, by Didier Badouel
Texture Mapping Resources, by Eric Haines, Prem Subrahmanyam,
Ranjit Bhatnagar, and Jack Ritter
-------------------------------------------------------------------------------
Introduction
There are a lot of new people, with some interesting fields of study.
There's been a lot of talk about texture mapping and the DBW ray tracer on the
net. This discussion will probably continue into next issue, but I felt Jack
Ritter's posting a good way to end it for now. I've also been toying with
texturing again, making my version of "Mount Mandrillbrot" (fractal mountain
with everyone's favorite beasty textured onto it), which some clever person
invented at the University of Waterloo (I think) some years ago (does anyone
know who?). There are also other useful snippets throughout.
However, one major reason that I'm flushing the queue right now is
that the node "hpfcrs" is disappearing off the face of the earth. So, please
note my only valid address is the "wrath" path at the top of the issue.
Thanks!
-------------------------------------------------------------------------------
New People and Address Changes
Panu Rekola, pre@cs.hut.fi
To update my personal information in your files:
Surface mail: Panu Rekola
Mannerheimintie 69 A 7
SF-00250 Helsinki, Finland
Phone: +358-0-4513243 (work), +358-0-413082 (home)
Email: pre@cs.hut.fi
Interests: illumination models, texture mapping, parametric surfaces.
You may remove one of the names you may have in the contact list. Dr. Markku
Tamminen died in the U.S. when he was returning home from SIGGRAPH. How his
project will go on, is still somewhat unclear.
--------
Andrew Pearce, pearce@alias
I wrote my MS thesis on Multiprocessor Ray Tracing, then moved to Alias where
I sped up Mike Sweeney's ray caster. I've just completed writing the Alias
Ray Tracer using a recursive uniform subdivision method (see Dave Jevans paper
in Graphics Interface '89, "Adaptive Voxel Subdivision for Ray Tracing") with
additional bounding box and triangle intersection speed ups.
Right now, I'm fooling around with using the guts of the ray tracer to do
particle/object collision detection with complex environments, and
particle/particle interaction with the search space reduced by the spatial
subdivision. (No, I don't use the ray tracer to render the particles.)
In response to Susan Spach's question about mip mapping, we use mip maps for
our textures, we get the sample size by using a "cone" size parameter which is
based on the field of view, aspect ratio, distance to the surface and angle of
incidence. For secondary rays this size parameter is modified based on the
tangents to the surface and the type of secondary ray it is (reflection or
refraction). This may be difficult to do if you are not ray tracing surfaces
for which the tangent information is readily available (smooth shaded
polygonal meshes?).
- Andrew Pearce
- Alias Research Inc., Toronto, Ontario, Canada.
- pearce%alias@csri.utoronto.ca | pearce@alias.UUCP
- ...{allegra,ihnp4,watmath!utai}!utcsri!alias!pearce
--------
Brian Corrie, bcorrie@uvicctr.uvic.ca
I am a graduate student at the University of Victoria, nearing the
completion of my Masters degree. The topic of my thesis is producing
realistic computer generated images in a distributed network environment.
This consists of two major research areas: providing a distributed (in the
parallel computing sense) system for ray tracing, as well as a workbench for
scene description, and image manipulation. The problems that need to be
addressed by a system for parallel processing in a distributed loosely coupled
system are quite different than those addressed by a tightly coupled parallel
processor system. Because of the (likely) very high cost of communication in
a distributed processing environment, most parallel algorithms currently used
are not feasible (due to the high overhead). The gains of parallel ray
tracing in a distributed environment are: the obvious speedup by bringing
more processing power to bear on the problem, the flexibility of distributed
systems, and the availability of the resources that will become accessible as
distributed systems become more prominent in the computer community.
Whew, what a mouthful. In a nutshell, I am interested in: ray
tracing in general, parallel algorithms, distributed systems for image
synthesis (any one know of any good references), and this new fangled
radiosity stuff.
--------
Joe Cychosz
Purdue University CADLAB
Potter Engineering Center
W. Lafayette, IN 47906
Phone: 317-494-5944
Email: cychosz@ecn.purdue.edu
My interests are in supercomputing and computer graphics. Research work is
Vectorized Ray Tracing. Other interests are: Ray tracing on MIMD tightly
coupled shared memory machines, Algorithm vectorization, Mechanical design
processes, Music synthesis, and Rendering in general.
--------
Jerry Quinn
Department of Math and Computer Science
Bradley Hall
Dartmouth College
Hanover, NH 03755
sunapee.dartmouth.edu!quinn
My interests are currently ray tracing efficiency, parallelism,
animation, radiosity, and whatever else happens to catch my eye at the
given moment.
--------
Marty Barrett - octrees, parametric surfaces, parallelism.
mlb6@psuvm.bitnet
Here is some info about my interests in ray tracing:
I'm interested in efficient storage structures for ray tracing, including
octree representations and hybrid regular subdivision/octree grids. I've
looked at ray tracing of parametric surfaces, in particular Bezier patches and
box spline surfaces, via triangular tessellations. Parallel implementations of
ray tracing are also of interest to me.
--------
Charles A. Clinton
Sierra Geophysics, Inc.
11255 Kirkland Way
Kirkland, WA 98033 USA
Email: ...!uw-beaver!sumax!ole!steven!cac
Voice: (206) 822-5200
Telex: 5106016171
FAX: (206) 827-3893
I am doing scientific visualization of 3D seismic data. To see the kind of
work that I am doing, check out:
'A Rendering Algorithm for Visualizing 3D Scaler Fields'
Paolo Sabella
Schlumberger-Doll Research
Computer Graphics, Vol. 22, Number 4 (SIGGRAPH '88 Conference Proc.)
pp 51-58
In addition, I try to keep up with ray-tracing and computer graphics in
general. I occasionally try my hand at doing some artistic ray-tracing.
(I would like to extend my thanks to Mark VandeWettering for distributing
MTV. It has provided a wonderful platform for experimentation.)
--------
Jochen Schwarze
I've been developing several smaller graphics packages, e.g. a 3D
visualization of turning parts etc. Now I'm implementing the 2nd version of a
ray tracing program that supports modular programming using a description
language, C++ vector analysis and body class hierarchy, CSG trees, texture
functions and mapping, a set of body primitives, including typeface rendering
for logos, and a network ipc component to allow several cpu's to calculate a
single image.
My interests lie - of course :-) - in speedup techniques, and the
simulation of natural phenomena, clouds, water, etc. Just starting with this.
Jochen Schwarze Domain: schwarze@isaak.isa.de
ISA GmbH, Stuttgart, West Germany UUCP: schwarze@isaak.uucp
Bang: ...!uunet!unido!isaak!schwarze
S-Mail: ISA GmbH
c/o Jochen Schwarze
Azenberstr. 35
7000 Stuttgart 1
West Germany
-------------------------------------------------------------------------------
Q&A on Radiosity Using Ray Tracing, Mark VandeWettering & John Wallace
From Mark VandeWettering:
I am currently working on rewriting my ray tracer to employ radiosity-like
effects. Your paper (with Wallace and Elmquist) is very nice, and suggests
a really straightforward implementation. I just have a couple of questions
that you might be able to answer.
When you shoot energy from a source patch, it is collected at a specific
patch vertex. How does this energy get transferred to a given patch for
secondary shooting? In particular, is the vertex shared between multiple
patches, or is each vertex only in a single patch? I can imagine the
solution if each vertex is distinct, but have trouble with the case where
vertices are shared. Any quick insights?
The only other question I have is: HOW DO YOU GET SUCH NICE MODELS TO RENDER?
[We use ME30, HP's Romulus based solids modeler - EAH]
Is there a public domain modeling package that is available for suns or sgi's
that I can use to make more sophisticated models? Something cheap even?
[The BRL modeler and ray tracer runs on a large number of machines, and they
like having universities as users - see Vol.2 No.2 (archive 6). According
to Mike Muuss' write-up, some department in Princeton already has a copy.
The Simple Surface Modeler (SSM) works on SGI equipment. It was developed at
the Johnson Space Center and, since they are not supposed to make any money
off it, is being sold cheap (?) by a commercial distributor. COSMIC, at
404-542-3265, can send you some information on it. It also runs on a Pixel
Machine (which is what I saw it running on at SIGGRAPH 88), though I don't
believe support for this machine will be shipped. It's evidentally not
shipping yet (red tape - the product is done), but should be "realsoonnow".
More information when I get the abstract. Does anyone else know any
resources?]
--------
Reply from John Wallace:
Computing the patch energy in progressive radiosity using ray tracing:
Following a step of progressive radiosity, every mesh vertex in the scene will
have a radiosity. Energy is not actually collected at the mesh vertices.
What is computed at each vertex is the energy per unit area (radiosity)
leaving the surface at that location. The patch radiosity is the average
energy per unit area over the patch. Finally, the patch energy is the patch
radiosity times the patch area (energy per unit area times area).
The vertex radiosities can be considered a sampling of the energy per unit
area at selected points across the patch. To obtain the average energy per
unit area over the patch, take the average of the vertex radiosities. This
assumes that the vertices represent uniform sub-areas of the patch. This is
not necessarily true, and when it is not a more accurate answer is obtained by
taking an area weighted average of the vertex radiosity. The weight given to
a vertex is equal to the area of the patch that it represents. In our work we
used a uniform mesh and weighted all vertices equally.
It doesn't matter whether vertices are shared by neighboring patches, since
we're talking about energy per unit area. Picture four patches that happen to
all share a particular vertex. The energy per unit area leaving any of the
patches at the vertex is not affected by the fact that other patches share
that vertex. If we were somehow collecting energy at the vertex, then it
would have to be portioned out between the patches.
Once the patch radiosity is know, the patch energy is obtained by multiplying
patch radiosity times patch area.
-------------------------------------------------------------------------------
Dark Bulbs, by Eric Haines
An interesting idea mentioned to me by Andrew Glassner was the concept
of "darkbulbs" in computer graphics. This idea is a classic joke technology,
in which the darkbulb sucks light out of an area. For example, if you want
to sleep during the daytime, you simply turn on your negative 100 watt dark
bulb and your bedroom is flooded in darkness. Andrew noted that this
technology is entirely viable in computer graphics, and would even be useful
in obtaining interesting results.
I happened to mention the idea to Roy Hall, and he told me that this
was an undocumented feature of the Wavefront package! Last year Wavefront came
out with an image of two pieces of pottery behind a candle, with wonderful
texturing on the objects. It turns out that the artist had wanted to
tone down the brightness in some parts of the image, and so tried negative
intensity light sources. This turned out to work just fine, and the artist
mentioned this to Roy, who, as an implementer of this part of the package,
had never considered that anyone would try this and so never restricted the
intensity values to be non-negative.
-------------------------------------------------------------------------------
MTV Ray Tracer Update and Bugfix, by Mark VandeWettering
[this was extracted by me from personal mail, with parts appearing on
comp.graphics - EAH]
As was recently pointed out to me by Mike Schoenborn, the cylinder code in the
version of the MTV raytracer is broken somewhat severely. Or at least it
appeared to be so, what actually happens is that I forgot to normalize two
vectors, which leads to interesting distortions and weird looking cylinders.
Anyway, the bug is in cone.c, in the function MakeCone(). After the vectors
cd -> cone_u and cd -> cone_v are created, they should be normalized. A
context diff follows at the end of this. This makes the SPD "tree" look MUCH
better. (And all this time I thought it was Eric's fault :-)
This bugfix will be worked into the next release, and I should also update the
version on cs.uoregon.edu SOMETIME REAL SOON NOW (read, don't hold your breath
TOO anxiously). Hope that this program continues to be of use... :-)
Somebody has some texture mapping code that they are sending me, I will
probably try to integrate it in before I make my next release. I am also
trying to get in spline surfaces, but am having difficulty to the point of
frustration.Any recommendations on implementing them?
*** ../tmp/cone.c Fri Aug 25 20:25:52 1989
--- cone.c Fri Aug 25 21:31:04 1989
***************
*** 240,247 ****
--- 240,251 ----
/* find two axes which are at right angles to cone_w
*/
+
VecCross(cd -> cone_w, tmp, cd -> cone_u) ;
VecCross(cd -> cone_u, cd -> cone_w, cd -> cone_v) ;
+
+ VecNormalize(cd -> cone_u) ;
+ VecNormalize(cd -> cone_v) ;
cd -> cone_min_d = VecDot(cd -> cone_w, cd -> cone_base) ;
cd -> cone_max_d = VecDot(cd -> cone_w, cd -> cone_apex) ;
-------------------------------------------------------------------------------
DBW Ray Tracer Description
[A ray tracer that has been mentioned in these pages (screens?) before is DBW.
Not having an Amiga and not being able to deal with "zoo" files, I never got a
copy. Prem Subrahmanyam has now made it available via anonymous FTP from
geomag.gly.fsu.edu in /pub/pics/DBW.src. Output is four bits for each
channel.
The original program was written by David B. Wecker, translating from a Vax
11/750 to the Amiga, with a conversion to Sun workstations by Ofer Licht
(ofer@gandalf.berkeley.edu). - EAH]
Below is an excerpt from the documentation RAY.DOC:
The RAY program knows how to create images composed of four primitive
geometric objects: spheres, parallelograms, triangles, and flat circular
rings (disks with holes in them). Some of the features of the program are:
Diffuse and specular reflections (with arbitrary levels of gloss or polish).
Rudimentary modeling of object-to-object diffusely reflected light is also
implemented, that among other things accurately simulates color bleed effects
from adjacent contrasting colored objects.
Mirror reflections, including varying levels of mirror smoothness or
perfection.
Refraction and translucency (which is akin to variable microscopic smoothness,
like the surface of etched glass).
Two types of light sources: purely directional (parallel rays from infinity)
of constant intensity, and spherical sources (like light bulbs, which cast
penumbral shadows as a function of radius and distance) where intensity is
determined by the inverse square law.
Photographic depth-of-field. That is, the virtual camera may be focused on a
particular object in the scene, and the virtual camera's aperture can be
manipulated to affect the sharpness of foreground and background objects.
Solid texturing. Normally, a particular object (say a sphere) is considered
to have constant properties (like color) over the entire surface of the
object, often resulting in fake looking objects. Solid texturing is a way to
algorithmically change the surface properties of an object (thus the entire
surface area is no longer of constant nature) to try and model some real world
material. Currently the program has built in rules for modelling wood,
marble, bricks, snow covered scenes, water (with arbitrary wave sources), plus
more abstract things like color blend functions.
Fractals. The program implements what's known as recursive triangle
subdivision, which creates all manners of natural looking surface shapes (like
broken rock, mountains, etc.). The character of the fractal surface (degree
of detail, roughness, etc.) is controlled by parameters fed to the program.
AI heuristics to complete computation of a scene within a user specified
length of time. [???]
======== USENET cullings follow ===============================================
As usual, these are deleted when I post to comp.graphics. Use ftp to get
the whole back issue if you want to see them (they've all appeared here
before).