PEARLE.PRG
PEARLE.PRG renders 3-dimensional scenes in a world of reflective and
refractive spheres, using ray tracing techniques. Movies formed from
sequences of frames can be generated, showing reflective balls linked and
bouncing in a gravitational field. They resemble a string of bouncing pearles
-- hence the name.
The amount of computation required to produce one ray traced image on
an ST is enormous -- it is measured in hours. To display animated movies,
images must be precomputed in (overnight) batch runs. PEARLE provides the
ability generate sequences of images on disk in Degas PI1 format, for later
replay by BLASTRAM.TTP (also included).
PEARLE.PRG generates a low resolution approximation of each picture first,
followed by refinement to successively higher resolutions. In this way,
a rough image is seen quickly for (somewhat) interactive debug. The size,
position, velocity and optical properties of the balls in the scenes are
specified numerically in the initialization file PEARLE.IN. Scenes can be
changed without recompilation of PEARL.PRG.
The ray tracing heart of PEARLE was taken from net.sources, documented
Fredrich Knauss of University of California, San Diego. I've ported it to
the ST, added animation, (primitive) color, and the various other features
you see here. I place PEARLE in the public domain, for non-comercial use only.
PEARLE.PRG runs only on a color ST in low resolution. 1 Meg is required
if resolutions greater than one ray per pixel or replaying movies from RAM
is desired. Operation with only 512K will produced slightly aliased pictures
(one ray per pixel) which can be displayed staticaly, slowly from floppy,
or from hard disk (if you have a disk blaster program).
The rest of this document contains sections entitled Getting Started,
Configuration File Format, and Checkpointing. The sources are available
upon request. With enough interest I could post them.
GETTING STARTED
The screen must be set to low resolution mode. Once started, type '?' for
help. Keys 'r' reads and 'w' writes the current screen using the current
disk file, whose name is displayed in the upper left corner of the screen.
Key 'e' exits. The average number of rays shot through each pixel
is also displayed in the margin and updated as the computation develops.
After unpacking PEARLE, the first logical thing to do is to start it up
with configuration file PEARLE.IN supplied. After a few minutes, you'll see
the resolution increasing. You might wait 1 to 4 hours to get complete
development, but if you get bored, hit the 'r' key. This will read the one
pre-computed picture PEARL001.PI1 which came in the "arc".
Now put PEARLE aside until you are willing to dedicate about 6 hours of
the ST for making a movie. The configuration file PEARLE.IN will also do
that. When done, you will find the movie in a sequence of disk files
named PEARLxxx.PI1 . Play these using BLASTRAM.TTP, supplying the argument
PEARL in the dialog box. With BLASTRAM running, type '?' for help.
The configuration file PEARLE.IN can be modified to give different
initial ball positions, velocities and optical properties, as well as varying
lighting and viewing perspectives, picture resolution, and gravity.
CONFIGURATION FILE FORMAT
The following section discusses the format of the configuration file,
PEARL.IN, which is performed line at a time at startup. The character in
column 1 specifies the meaning of the rest of each line. Lines may be up
to 200 characters long. Lines beginning with whitespace are comments.
The following other formats are supported:
- - - 'p' Format: - - -
specifies the physical size and velocity of a ball. There are 7 properties
required for each ball, and they must be specified on one line in the
following order:
(1) x coordinate of center (2) x velocity
(3) y coordinate (4) y velocity
(5) z coordinate (6) z velocity
(7) radius
Some Notes:
A) In the coordinate system used, Y is upward, X is to the right, and Z
is depth.
B) Balls will bounce off the floor (the plane Y == 0) and an invisible
viewing port (the plane Z==0). Be sure to start them so that all portions
of the ball are above the floor and farther away than the viewing port.
C) If balls start out overlapping, they will stick together.
This turned out to be a serendipitous bug in the bounce algorithm.
D) The current version is compiled for up to 15 balls maximum.
The first p-format statement in the file defines the "first" ball PEARLE
knows about, the second the second and so on. Here are 6 balls which
form an interesting scene:
(1) (2) (3) (4) (5) (6) (7) (see (1)-(7) above)
p 195.0,-20, 130.0, 0, 250.0, 10, 30.0 these are the 4 linked balls:
p 150.0, -5, 100.0, 20, 250.0, 10, 30.0 "
p 105.0, 5, 70.0, 20, 250.0,-20, 30.0 "
p 60.0, 20, 40.0, 0, 250.0,-20, 30.0 "
p 0.0, -10, 300.0, 20, 600.0, 0, 300.0 this is the big ball
p 200.0, 2, 50.0, 5, 60.0,30, 50.0 a medium size (lone) ball
- - - 'o' Format: - - -
specifies the optical properties of a ball. The following 8 properties
must be put on one line:
(1) index of refraction
(2) amount of refraction
(3) amount of reflection
(4) amount of diffuse light (omnidirectional)
(5) amount of ambient light (from light source)
(6) surface color redness
(7) surface color greenness
(8) surface color blueness
Some notes are in order to make realistic objects:
A) All parameters should be positive or zero.
B) Items (2) through (5) should sum to less than 1.0
C) Surface colors (6) through (8) modulate the affect the diffuse and ambient
reflective properties (4) and (5). None should be greater than 1.0 .
C) Due to the size of the ST's color palette, surface color items (6)
through (8) are constrained to be patterns corresponding to one of the
following three colors:
white: (6) == (7) == (8) == 1.0
red: (6) == (7) == 1.0, (8) == 0.0
blue: (6) == 0.0, (7) == (8) == 1.0
The i'th 'o' Format line refers to the same ball as the i'th 'p' Format line.
Here are the optical properties for the scene:
(1) (2) (3) (4) (5) (6) (7) (8)
o 0.0, 0.0, 0.3, 0.6, 0.1, 1.0,0.0,0.0 diffuse red, somewhat reflective
o 0.0, 0.0, 0.6, 0.3, 0.1, 1.0,1.0,1.0 reflective, somewhat white
o 0.0, 0.0, 0.9, 0.0, 0.1, 1.0,1.0,1.0 reflective, some ambient
o 0.0, 0.0, 0.0, 0.8, 0.2, 1.0,0.0,0.0 diffuse red, some ambient
o 0.0, 0.0, 0.7, 0.1, 0.2, 1.0,1.0,1.0 reflective and ambient (the big one)
o 1.6, 0.8, 0.0, 0.0, 0.2, 1.0,1.0,1.0 refractive
- - - 'v' Format: - - -
specifies the viewpoint of the display. x, y, and z values are required.
v 215.0, 100.0, -550.0
| | z coordinate of viewpoint
| y coordinate of viewpoint
x coordinate of viewpoint
- - - 'l' Format: - - -
specifies the location of the lightsource, and its diameter. Like before
its x, y, and z coordinates, now followed by the diameter of the light.
l 150.0, 950.0, 0.0, 100.0
- - - 'r' Format: - - -
specifies the resolution of the picture to be produced, in Rays projected
through each Pixel, followed by the color schema index, a number from 1
through 3.
r .20, 3
The inputted value of Rays Per Pixel will be rounded up to the next
greater power of 4.0. Thus in the line above, the .20 will be rounded up
to (4.0)**(-1) = .25.
The time to compute images varies linearly with the resolution (Rays Per
Pixel) chosen. The constant of proportionality varies greatly depending on
the complication of the scene, but for the 6-ball scene here on a 520ST:
.0625 rays per pixel 4 min
.25 rays per pixel 15 min
1.0 rays per pixel 1 hr
4.0 rays per pixel 4 hrs
16.0 rays per pixel 16 hrs
The color index specifies how the 16 colors of the low resolution monitor
are divided amongst hues and saturation. Three values are accepted currently:
1: white 16 saturations
2: white, red 8 saturations each
3: white, red, blue 6 saturations each
Although the ray tracing algorithm computes arbitrary red/green/blue hues,
the palate limitations of the ST prohibit their display.
- - - 'g' Format: - - -
specifies the strength of gravity. The following is realistic:
g 32.0
- - - 'f' Format: - - -
specifies the first 5 characters of the filename to be used to save
completed pictures. (The rest of the name is the frame sequence number,
and the suffix .PI1) Also specified are the starting and ending frame
numbers to be computed (positive integers less than 999).
f pearl, 1, 24
generates 24 frames on the disk, labeled PEARLL001.PI1 through PEARL024.PI1.
At 32K per frame, that will just about fill an 820Kb double sided drive.
CHECKPOINTING
Since PEARLE.PRG runs are so long, checkpointing information is generated
following the completion of a frame, so that if the computation of the next
frame is interupted, it may be restarted. The checkpointing information
is written in a file named PEARLE.CKP in the same format as PEARLE.IN.
PEARLE.PRG will use this file instead of PEARLE.IN if the former exists.
BE SURE TO REMOVE PEARLE.CKP FILES IF YOU WANT THE RUN TO START A NEW RUN.
Thats it for now. Tell me of you ventures, send me interesting
configurations you find, and enjoy!
Allen King 1-617-449-3359 evenings
30 Gibson St
Needham Ma. ucbvax!aking@bfly-vax.bbn.com
02192