So, I've regained the desire to type again a mere month after the SIGGRAPH
course notes deadlines. Not much in the queue, but I thought I'd pass on what
little there is. The most interesting developments which affect ray tracing
are the release of the RenderMan (tm) interface by Pixar and the publication
of Ardent's Dore' (tm) Programmer's Guide and Reference Manual.

Andrew Glassner's hardcopy "RT News" is coming out soon - if you're not on the
mailing list, write him.

SIGGRAPH Ray Tracers Roundtable: in case you don't know, this is an informal
get-together during SIGGRAPH where we talk about ray tracing techniques and
trends. Personally, I'd like to aim for about the same time as last year:
Thursday, sometime after 5 pm (with people then hitting the technical reception
for food afterwards). Same as last year, we'll leave notes at the message
center to all subscribers as to exactly where and when. If you're not planning
to attend SIGGRAPH, please save me some note-writing effort by telling me.
Otherwise, see you there.

I have been working on Ray Tracing since 1984 while I was a graduate
student at The Ohio State University. I am still working on my thesis
for my MSEE on parallelism and algorithm improvements for Ray Tracing.
My areas of Ray Tracing interest include the following:

I was born the son of a poor black sharecropper... wait, wrong story....

I started in the Computer graphics lab at RPI in 1979, got my Master's
in '82 and came to Bell Labs doing graphics for CAD systems. I moved to
Pixel Machines in early 1987 and have been working there since. I am
interested in 3d rendering and animation, and I am currently working on
the Ray tracing library for the Pixel Machine, RAYlib.

What follows is a non-review of RenderMan and Dore'. If you've been looking
for a chance to contribute to the RT News, here's your chance - I'm not
planning on reviewing either of these in depth, but would love to hear others'
opinions (even anonymous ones) of these packages.

I just received a copy of Pixar's "RenderMan" interface. To quote the
preface:

The RenderMan interface is designed so that the information needed to
specify a photorealistic image can be passed to different rendering
programs compactly and efficiently. ... In order to achieve this,
the interface does not specify how a picture is rendered, but instead
what picture is desired. ... The RenderMan interface is a collection
of procedures to transfer the description of a scene to the rendering
program.

The interface for the ray tracer is wonderfully short, as it is simply another
command in Pixar's shading language. I include it here in full:

18.4.5 RAY TRACING

color trace( point R )

"trace" returns the incident light falling on a surface in a given
direction R. If a particular implementation does not support ray
tracing, and cannot compute the incident light arriving from an
arbitrary direction, trace will return 0 (black).

That's it. I don't see any way this command can support shadowing or
filtering, but I haven't read through the document carefully (Pixar seems
to want to go with their "Shadow Depth Maps" instead - SIGGRAPH 87 paper).

Anyway, this interface is "endorsed" by Apollo, DEC, Stellar, Ardent, and
Sun, so it seems to be a happening something. I'm not sure what "endorsement"
means, exactly, but one thing it means is that you should probably check it out.

Dore': well, I received the two preliminary manuals yesterday. As such,
about all I can commit myself to is: "nice packaging - very artsy binders".
Reviews, please?

Paul Heckbert's "Ray Tracing Bibliography" has been updated for May, 1988.
It will appear in the next issue of the hardcopy "Ray Tracing News" and in the
SIGGRAPH '88 "Introduction to Ray Tracing" course notes. If you would like to
see it before then, or would just like to have an electronic version on hand,
please write Eric Haines and I'll mail you the latest version. Also, if you
do get a copy, please tell us of any errata or addenda you may have for it.

I'm collecting information for the "Consumer's and Developer's Guide to Image
Synthesis" course at SIGGRAPH this year - namely, companies selling ray tracers.
The bare bones info is at the end of this issue. I'm in the midst of ordering
manuals, but that's about as far as I'm going. So, I would like to hear from
anyone who knows anything about these packages. I will keep all reviews
confidential, unless you explicitly state otherwise.

Below is a partial list of groups (in alphabetical order) offering ray tracing
packages. If you know of any others, please clue me in (I'm particular
ignorant when it comes to software for animators & advertising, such as
Wavefront. For now, I have left them off the list below). The "Contact"
section first lists the person who I have dealt with, followed by the official
contact address and/or phone number. I believe the only company that won't
have representation on the floor at SIGGRAPH is Ray Tracing Corp (though UCS
probably will, in some form). Oh, just to dispell rumors, "Numerical Designs
Ltd", Turner Whitted's company, is not planning on announcing a ray tracer
by SIGGRAPH 88. Instead, they are marketing a package based on using pipes
and filters for rendering (beyond this, I do not know...).

AT&T, Pixel Machines "RAYlib". Available only on the Pixel Machine.

Cost: ???, manuals available realsoonnow.

Contact: Ken Krause, 201-563-2274.
AT&T Pixel Machines
1-800-544-0097

Ardent, "Dore'". Available on Ardent's Titan superworkstation. Source
available in C, portable to other machines.

United Computer Systems, Inc, "Ray Tracer". Available on Apollo, IBM, and
Mac. Evidentally selling well on Mac and IBM: 4x sales than Apollo
sales since intro post-SIGGRAPH '87. It turns out that this product
is actually made by Ray Tracing Corp.

[This recently appeared in the email newsletter on scientific visualization
that Jeff Goldsmith has been editing. If you're interested in subscribing
and contributing to the SciVi discussion group, contact him at:
jeff@hamlet.caltech.edu . I thought it of interest because of the bounding
box intersector statistics. - EAH]

I did an interesting micro-project this winter/spring. We were
interested in porting some programs to PCs and/or Workstations, so
I compared the performance of a few chunks of graphics code on a bunch
of machines. The code was supposed to represent some of the typical
cpu and I/O intensive things that graphics programs tend to do.

What did I learn from all this? One thing is obvious: if a
FPA is available for your machine and you can afford it (they
are usually cheap) buy it even if you don't do alot of floating
point. It affects all sorts of performance characteristics.
Another important point: it is not possible to evaluated computer
performance as one number. Different computers do different things
well.