-
Notifications
You must be signed in to change notification settings - Fork 0
/
Readme.txt
703 lines (579 loc) · 36.3 KB
/
Readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
STANDARD PROCEDURAL DATABASES, by Eric Haines
[Created while under contract to Hewlett-Packard FSD and HP Laboratories]
Version 3.15, as of 1 December 2012
(modified & released by Sam [sbt] Thompson - spd2012@samthompson.com)
address: Autodesk, 10 Brown Road, Ithaca, NY 14850
email: erich@acm.org
{This software package is not copyrighted and can be used freely.}
The basic idea of this package is that you can use it to create arbitrarily
complex 3D scenes from programs. Originally the intent was to test ray tracing
efficiency, but there are other uses for these programs as well. Models can be
output to a wide variety of formats, and there are also programs to convert
NFF, DXF, and OBJ format files to these other formats. The "standard" models
which can be produced are are: fractal balls (sphereflake), gear set, fractal
mountain, linked rings, the famous teapot, a recursive tetrahedron, and a tree.
The advantages to having the models be generated by procedures are many.
First, the description of the model is compact: the C code for a typical model
is much smaller than the data file generated for that model. By allowing the
amount of data output to be controlled by a size factor for each program, the
models are also scalable and can become arbitrarily complex. This feature is
useful as machines get faster and have more memory available. Finally, the
procedural description can be modified and new models generated; for example,
by changing variables in the tree.c program, different types of tree shapes can
be generated. Finally, because the models exist as entities at a higher level
than simply a collection of polygonal surfaces, various translators to other
formats can be made part of the programs.
Quick Start
-----------
Compile and link the files. If you can't use a makefile, just look at one
and you'll see what files each executable needs.
Typically the order of the command line options is:
prog [-s size_factor] [-r renderer] [-c|-t] [-?]
i.e. "balls -s 2 -r 1 > balls.nff" generates a level 2 sphereflake in MTV's
native format (NFF). The meaning of "size_factor" varies from program to
program, but basically indicates the complexity of the database that will be
generated. The "renderer" option corresponds to the definitions in "def.h"
for the various supported renderers. (i.e. 0 means display on screen, 2
means POV-Ray 1.0, ...) The [-c|-t] determines the output format, -c means
output curved object primitives, -t means output polygonal patches in a mesh
for curved surfaces. By default NFF is output, though this is easily changed
by changing OUTPUT_RT_DEFAULT in the code. Also, typing "prog -?" gives you
the options available.
If you just want to see what a model looks like, try exporting to
VRML 2.0 and viewing the resulting file in your web browser.
The DXF displayer/converter "readdxf" works as follows:
readdxf [-r renderer] filename
"-r 0" means display on screen, the others convert, etc. The converters
"readnff" and "readobj" work similarly.
Two sample models, skull.dxf and f117.dxf, are provided as examples for use
with readdxf. These were created with the HyperSpace(tm) 3-D digitizing system
from Mira Imaging, Inc.
Goals
-----
This software is meant to act as a set of basic test images for ray tracing
algorithms. The programs generate databases of objects which are fairly
familiar and "standard" to the graphics community, such as the teapot, a
fractal mountain, a tree, a recursively built tetrahedral structure, etc. I
originally created them for my own testing of ray tracing efficiency schemes.
Since their first release other researchers have used them to test new
algorithms. In this way, research on algorithmic improvements can be compared
in a more standardized way. If one researcher ray-traces a car, another a
tree, the question arises, "How many cars to the tree?" With these databases
we may be comparing oranges and apples, but it's better than comparing oranges
and orangutans. In addition, this document outlines some statistics that are
more meaningful to researchers than raw timing tests. Using these statistics
along with the same scenes allows us to compare results in a more meaningful
way.
Another interesting use for the SPD has been noted: debugging. By
comparing the images and the statistics with the output of your own ray tracer,
you can detect program errors. For example, "mount" is useful for checking if
refraction rays are generated correctly, and "balls" can check for the
correctness of eye and reflection rays.
The images for these databases and other information about them can be
found in "A Proposal for Standard Graphics Environments," IEEE Computer
Graphics and Applications, vol. 7, no. 11, November 1987, pp. 3-5. See
IEEE CG&A, vol. 8, no. 1, January 1988, p. 18 for the correct image of the
tree database (the only difference is that the sky is blue, not orange). The
teapot database was added later, and consists of a shiny teapot on a shiny
checkerboard.
The SPD package is available from:
http://www.acm.org/tog/resources/SPD
among others. The "overview.htm" file in the SPD distribution is this page -
it's better to read the online version, because it has images and is more up to
date.
SPD Export
----------
The SPD package originally exported its data only to NFF (Neutral
File Format, not to be confused with Sense8's format with the same acronym).
See NFF.txt for more about this format.
Alexander Enzmann (xander@mitre.org) expanded the SPD package to export
other formats, and other programmers (see History, at end) joined in to add
more and correct bugs. The formats currently exported are:
NFF - MTV
POV-Ray 1.0
Polyray v1.4, v1.5
Vivid 2.0
QRT 1.5
Rayshade
POV-Ray 2.0
RTrace 8.0.0
PLG format for use with rend386
Raw triangle output
art 2.3
RenderMan RIB format
Autodesk DXF format (3DFACE polygons only)
Wavefront OBJ format (polygons only)
RenderWare RWX script file
3D Metafile (Apple Quickdraw 3D text format)
VRML 2.0 (Virtual Reality Modeling Language)
There are also a few converters which read in a format and can convert it
to any of the formats listed. These programs are:
readdxf: reads DXF (3DFACEs) and converts (sorry, no color conversion)
readnff: reads an NFF file and fully converts it
readobj: reads a Wavefront OBJ file and converts it
In addition, there is a program nff2rad.c which converts NFF data to
Radiance format (if anyone feels like folding this code into lib.c, please
do). Note that this converter is not listed in the makefile since it is
special purpose (and standalone, so it's trivial to compile).
Simple display drivers have been included various flavors for the IBM
PC (VGA, Gnu C, etc), Apple Macintosh, X11R6, and HP Starbase. Drivers are
very simple to write: you just need a display initialization routine, a
display close routine, and a line drawing routine. For Unix systems, for
example, just copy and fill in drv_null.c (the default driver). There
is also a routine kbhit() for allowing display interrupt from the keyboard, if
needed. If you don't have access to display drivers for your machine, simply
compile with "drv_null.c" - all display calls will then be ignored.
Post-it Notes
-------------
- POV-Ray does not support arbitrary polygons, you get lots of triangles.
- RTrace does not support Phong highlights separately from reflections. It
is difficult to get RTrace surfaces to look like other renderers
- Polygons in PLG format will typically need to be scaled way up.
- Rayshade if compiled right out of the box won't take CR/LF pairs in files,
end of lines must be a single LF.
- QRT has bad refraction code and doesn't support arbitrary polygons.
- See the web site http://www.acm.org/tog/resources/SPD/ for a link to
Eduard Schwan's Macintosh port of the SPD.
File Structure
--------------
Various different procedural database generators are included. The
original programs were: balls, gears, mount, rings, tetra, and tree, and so
these are more commonly used for performance testing. The teapot generator
was added due to popular request (what with it being the sixth platonic solid
and all). These models were designed to span a fair range of primitives,
modeling structures, lighting and surface parameters, background conditions,
and other factors. There are also shell and lattice generators just for
amusement, and a sombrero heightfield generator (which can easily be modified
to produce other height fields, as you wish). Also, the nurbtst program shows
how NURBS can be generated and tessellated. A complexity factor is provided
within most programs to control the size of the database generated. See the
Manifest.txt for a description of each file.
The compiled and linked programs will output a database in ASCII to stdout
containing viewing parameters, lighting conditions, material properties, and
geometric information. The data format is called the 'neutral file format'
(or NFF) and is described in the `NFF.txt' file. This format is meant to be
minimal and easy to attach to a user-written filter program which will convert
the output into a file format of your choosing.
Either of two sets of primitives can be selected for output. If
OUTPUT_FORMAT is defined as OUTPUT_CURVES, the primitives are spheres, cones,
cylinders, and polygons. If OUTPUT_FORMAT is set to OUTPUT_PATCHES, the
primitives are output as polygonal patches and polygons (i.e. all other
primitives are polygonalized). In this case OUTPUT_RESOLUTION is used to set
the amount of polygonalization of non-polygonal primitives. In general,
OUTPUT_CURVES is used for ray-trace timing tests, and OUTPUT_PATCHES for
polygon-based algorithm timings. Note that sphere primitives are not
polygonalized using the simple longitude/latitude tessellation, but rather are
chopped along the six faces of a cube projected onto the sphere. This
tessellation avoids generation of the cusp points at the sphere's poles and so
eliminates discontinuities due to them.
The size factor is used to control the overall size of the database.
Default values have been chosen such that the maximum number of primitives
less than 10,000 is output. One purpose of the size factor is to avoid
limiting the uses of these databases. Depending on the research being done
and the computing facilities available, a larger or smaller number of
primitives may be desired. The size factor can also be used to show how an
algorithm's time changes as the complexity increases. See the header of the
database C file (e.g. "balls.c") for how the size factor affects the output.
Other parameters in the code itself (for example, branching angles for
"tree.c" and the fractal dimension in "mount.c") are included for your own
enjoyment, and so normally should not be changed if the database is used for
timing tests. Because the hashing function in the original release of
"mount.c" is not very good (at low resolutions there is patterning), there is
a better hashing function provided which can be turned on by defining
JENKINS_HASH. Use the old hashing function (i.e. don't change anything) for
consistency with previously published results, use the new one for better
results.
Since the SPD package is designed to test efficiency, the actual shading
of the images is mostly irrelevant. All that matters is that reflective
surfaces spawn reflection rays and transmitters spawn refraction rays. For
this reason the effect of the other shading parameters is up to the
implementer. Note that light intensities, ambient components, etc. are not
specified. These may be set however you prefer. Feel free to change any
colors you wish (especially the garish colors of `rings'). The thrust of
these databases is the testing of rendering speeds, and so the actual color
should not affect these calculations. An ambient component should be used for
all objects, so that the time to compute it is included in the ray tracing
statistics. A simple formula for a relative intensity (i.e. between 0 and
1) for each light and for the ambient component is the following:
sqrt(# lights) / (# lights * 2).
If you desire a model for a good scene description language, NFF is not
it. Instead, you should look at BMRT, Radiance, POV-Ray, or Rayshade. See
http://www.acm.org/tog/Software.html for links.
The programs all attempt to minimize program size and memory usage, and
generally avoid allocating dynamic memory. As such, many of the programs are
relatively inefficient, regenerating various data again and again instead of
saving intermediate results. This behavior was felt to be unimportant, since
generating the data is a one-time affair which normally takes much less time
than actually rendering the scene.
Database Analysis
-----------------
The databases were designed with the idea of diversity in mind. The
variables considered important were the amount of background visible, the
number of lights, the distribution of sizes of objects, the amount of
reflection and refraction, and the depth complexity (how many objects a ray
from the eye passes through).
balls: This database is sometimes called "sphereflake", as it is generated
like a snowflake curve. This database consists mostly of various sized
spheres. It has no eye rays which hit the background, and the three light
sources cause a large number of shadow rays to be generated.
gears: This database consists of a set of meshed gears. Some of the gears
are transmitters, making this database lengthy to render. The gear faces
each have 144 vertices, and thus tests polygon inside/outside test
efficiency. Depth complexity is medium.
mount: The fractal mountain generator is derived from Loren Carpenter's
method, and the composition with the four glass spheres is inspired by
Peter Watterberg's work. Most objects are tiny (i.e. fractal facets),
but rendering time is dominated by the rendering of the four large
spheres. Depth complexity is low, and there is much background area.
rings: Objects with six pentagonal rings form a pyramid against a background
polygon. With a high amount of interreflection and shadowing, this scene
is fairly lengthy to render. Depth complexity is also high, with
all of the objects partially or fully obscured.
teapot: The famous teapot on a checkerboard. There are a number of
variations on the teapot database, i.e. whether the bottom is included
(the IEEE CG&A article added a bottom), variations in the control points
on the lid (which creates thin, almost degenerate triangles), etc. For
this database generator, the bottom is created, and the degenerate
polygonal patches at the center of the lid and bottom are not output. The
bottom of the teapot is not flat, interestingly enough. The resolution of
the checkerboard shows the resolution of the teapot meshing (with each
teapot quadrilateral cut into two triangles), e.g. an 8x8 checkerboard
means that 8x8x2 triangles are generated per patch. The definitions for
the 32 Bezier patches are a part of the program. All objects are
reflective and there are two light sources. Depth complexity is low.
tetra: A recursive tetrahedral pyramid, first visualized by Benoit Mandelbrot
and Alan Norton. This scene is dominated by background (around 80%). With
the objects not being reflective and there being only one light source,
this database is particularly quick to render, with various forms of
coherency being very useful. Depth complexity is medium, though some
rays must pass by many triangles for some of the background pixels.
tree: A tree formed using Aono and Kunii's tree generation method. With
seven light sources, the emphasis is on shadow testing. Shadow caching
yields little improvement due to the narrow primitives, and many shadow
rays pass through complex areas without hitting any objects. There is a
fair amount of background area. Depth complexity is low.
balls gears mount rings
----- ----- ----- -----
primitives SP P PS YSP
total prim. 7382 9345 8196 8401
poly/patches 1417K 9345 8960 874K
lights 3 5 1 3
background 0% 7% 34% 0%
specular yes yes yes yes
transmitter no yes yes no
eye hit rays 263169 245086 173125 263169
reflect rays 175095 304643 354769 315236
refract rays 0 207564 354769 0
shadow rays 954368 2246955 412922 1085002
teapot tetra tree
------ ----- ----
primitives TP P OSP
total prim. 9264 4096 8191
poly/patches 9264 4096 852K
lights 2 1 7
background 39% 81% 35%
reflector yes no no
transmitter no no no
eye hit rays 161120 49788 169836
reflect rays 225248 0 0
refract rays 0 0 0
shadow rays 407656 46112 1097419
"primitives" are S=sphere, P=polygon, T=polygonal patch, Y=cylinder,
O=cone, listed from most in database to least.
"total prim." is the total number of ray-tracing primitives (polygons,
spheres, cylinders and cones) in the scene. The number of polygons and vectors
generated is a function of the OUTPUT_RESOLUTION. The default value for this
parameter is 4 for all databases.
"poly/patches" is the total number of polygons and polygonal patches
generated when using OUTPUT_PATCHES.
"lights" is simply the number of lights in a scene. "background" is the
percentage of background color (empty space) seen directly by the eye for the
given view. "reflector" tells if there are reflective objects in the scene,
and "transmitter" if there are transparent objects.
"eye hit rays" is the number of rays from the eye which actually hit an
object (i.e. not the background). 513x513 eye rays are assumed to be shot
(i.e. one ray per pixel corner). "reflect rays" is the total number of rays
generated by reflection off of reflecting and transmitting surfaces. "refract
rays" is the number of rays generated by transmitting surfaces. "shadow rays"
is the sum total of rays shot towards the lights. Note that if a surface is
facing away from a light, or the background is hit, a light ray is not formed.
The numbers given can vary noticeably from a given ray tracer, but should all
be within about 10%.
"K" means exactly 1000 (not 1024), with number rounded to the nearest K.
All of the above statistics should be approximately the same for all
classical ray tracers.
Testing Procedures
------------------
Below are listed the requirements for testing various algorithms. These test
conditions should be realizable by most renderers, and are meant to represent
a common mode of operation for each algorithm. Special features which the
software supports (or standard features which it lacks) should be noted in
your statistics.
1) The non-polygon (OUTPUT_CURVES) format should normally be used for
ray-tracing tests.
2) All opaque (non-transmitting) primitives can be considered one-sided
for rendering purposes. Only the outside of primitives are visible in
the scenes. The only exception to this is the "teapot" database, in
which the teapot itself should normally be double sided (this is
necessary because the lid of the teapot does not fit tightly, allowing
the viewer to see back faces).
3) Polygonal patches (which are always triangles in the SPD) should have
smooth shading, if available.
4) Specular highlighting should be performed for surfaces with a
reflective component. The simple Phong distribution model is
sufficient.
5) Light sources are positional. If unavailable, assign the directional
lights a vector given by the light position and the viewing "lookat"
position.
6) Render at a resolution of 512 x 512 pixels, shooting rays at the
corners (meaning that 513 x 513 eye rays will be created). The four
corner contributions are averaged to arrive at a pixel value. If
rendering is done differently, note this fact. No pixel subdivision
is performed.
7) The maximum tree depth is 5 (where the eye ray is of depth 1). Beyond
this depth rays do not have to be spawned.
8) All rays hitting only reflective and transmitting objects spawn
reflection rays, unless the maximum ray depth was reached by the
spawning ray. No adaptive tree depth cutoff is allowed; that is, all
rays must be spawned (adaptive tree depth is a proven time saver and
is also dependent on the color model used - see Roy Hall's work for
details).
9) All rays hitting transmitting objects spawn refraction rays, unless
the maximum ray depth was reached or total internal reflection occurs.
Transmitting rays should be refracted using Snell's Law (i.e. should
not pass straight through an object). If total internal reflection
occurs, a reflection ray should still be generated at this node. Note
that all transmitters in the SPD are also reflective, but this is
not a requirement of the file format itself.
10) A shadow ray is not generated if the surface normal points away from
the light. This is true even on transmitting surfaces. Note any
changes from this condition.
11) Assume no hierarchy is given with the database (for example, color
change cannot be used to note a clustering). The ray tracing program
itself can create its own hierarchy, but this process should be
automatic. Note any exceptions to this (e.g. not including the
background polygon in the efficiency structure, changing the
background polygon into an infinite plane, etc). Such changes can be
critical for the efficiency of some schemes, so an explanation of why
changes were made is important.
12) Timing costs should be separated into at least two areas: preprocessing
and ray-tracing. Preprocessing includes all time spent initializing,
reading the database, and creating data structures needed to ray-trace.
Preprocessing should be all the constant cost operations--those that
do not change with the resolution of the image. Ray-tracing is the
time actually spent tracing the rays (i.e. everything that is not
preprocessing).
13) Other timing costs which would be of interest are in a breakdown of
times spent in preprocessing and during actual ray-tracing. Examples
include time spent reading in the data itself, creating a hierarchy,
octree, or item buffer, and times spent on intersection the various
primitives and on calculating the shade.
14) Time-independent statistics on the performance of the algorithm should
be gathered. Some examples are the number of ray/object intersection
tests, the number of ray/object tests which actually hit objects,
number of octree or grid nodes accessed, and the number of successful
shadow cache hits.
Timings
-------
Rendering time of the ray-traced test set on an HP-835, optimized (512 x 512):
Input Setup Ray-Tracing | Polygon Sphere Cyl/Cone Bounding
(hr:min:sec) | Tests Tests Tests Box Tests
-------------------------------------------------------------------------------
balls 0:14 0:19 24:56 | 822K 6197K 0 51726K
gears 0:56 0:18 1:02:31 | 13703K 0 0 107105K
mount 0:31 0:14 18:49 | 4076K 3978K 0 31106K
rings 0:41 0:33 53:41 | 1045K 5315K 16298K 91591K
teapot 1:02 0:18 25:38 | 7281K 0 0 57050K
tetra 0:15 0:06 3:48 | 965K 0 0 7637K
tree 0:40 0:31 11:36 | 479K 524K 1319K 22002K
Input: time spent reading in the NFF file.
Setup: time spent creating the database and any ray tracing efficiency
structures, and cleaning up after ray trace (does not include "Input" time).
Ray-Tracing: time spent traversing and rendering the pixel grid.
A typical set of ray tracing intersection statistics for the tetra database is:
[these statistics should be the same for all users]
image size: 512 x 512
total number of pixels: 262144 [ 512 x 512 ]
total number of trees generated: 263169 [ 513 x 513 ]
total number of tree rays generated: 263169 [ no rays spawned ]
number of eye rays which hit background: 213381 [ 81% - might vary ]
average number of rays per tree: 1.000000
average number of rays per pixel: 1.003910
total number of shadow rays generated: 46111 [ might vary a bit ]
[these tests vary depending on the ray-tracing algorithm used]
Intersector performance
Bounding box intersections: 7636497 - 26.71 usec/test
Polygon intersections: 964567 - 36.77 usec/test
Ray generation
Eye rays generated: 263169 ( 49788 hit - 18.92% )
Reflection rays generated: 0
Refraction rays generated: 0
Shadow rays generated: 46111
Coherency hits: 3407 - 7.39 % of total
Fully tested: 42704
The ray-tracer which generated these statistics is based on hierarchical
bounding boxes generated using Goldsmith & Salmon's automatic hierarchy method
(see IEEE CG&A May 1987).
One problem worth analyzing when using the SPD for efficiency tests is how
octree, SEADS, and other space dividing algorithms perform when the background
polygon dimensions are changed (thus changing the size of the outermost
enclosing box, which changes the encoding of the environment). One analysis of
the effect of the background polygon on RayShade can be found in "Ray Tracing
News", volume 3, number 1, http://www.acm.org/tog/resources/RTNews/html/
Code Notes
----------
See the Manifest.txt file for a brief listing of what the various code
modules do.
{by Alexander Enzmann, talking about some of his extensions to the code which
are not reflected in the NFF specification}
The biggest changes to the original NFF/SPD code is in the area of surface
shading attributes. Since many raytracers support scale values for more
components of the shading model than are present in NFF, these have been
added. The new components that have to be given in any call to
"lib_output_color" are: Ka (ambient), Shine (Phong specular), Shine angle
(50% falloff angle for Phong spot, in degrees).
The separation of the Phong values from the Ks (specular) value simply
reflects the fact that most renderers don't force you to do both at the same
time (RTrace being an exception). Using a falloff angle for the Phong
highlight may seem odd to you, but it really is sensible. Smaller angles mean
smaller highlights.
Another change in the call to "lib_output_color" is a parameter that allows
the definition of a texture name. Many raytracers support named textures, by
using a non-NULL string, you can specify a predefined texture name (these
things are pretty renderer specific). All of the examples use NULL, which
defaults to plopping the current color into each primitive.
In addition to the sphere, polygon, and cylinder/cone objects that were
supported in the original SPD, support has been added for: boxes, tori,
height fields, and superquadrics. For those raytracers that do not support
these as primitives, the output will be a large number of triangle patches.
Oh, yeah - the coordinate system used in this library is left-handed. This
may seem backwards for those of you used to one renderer vs another, but it is
simple enough to change: always negate the value of just one of the
coordinates and you get right-handed coordinates.
Future Work
-----------
These databases are not meant to be the ultimate in standards, but are
presented as an attempt at providing representative modeled environments. A
number of extensions to the file format could be provided someday, along with
new database generators which use them. The present databases do not contain
polygons with holes, spline patches, polygonal mesh, triangular strip, or
polyhedron data structures. Modeling matrices are not output, and CSG
combined primitives are not included. Light sources are particularly
simplistic. For a richer, more user-friendly scene description language,
take a look at RayShade or RenderMan.
As far as database geometry is concerned, most scenes have a preponderance
of small primitives. If you find that these databases do not reflect the type
of environments you render, please write and explain why (or better yet, write
one or more programs that will generate your "typical" environments--maybe it
will get put in the next release).
Acknowledgements
----------------
I originally heard of the idea of standard scenes from Don Greenberg back
in 1984. Some time earlier he and Ed Catmull had talked over coming up with
some standard databases for testing algorithmic claims, and to them must go
the credit for the basic concept. The idea of making small programs which
generate the data came to me after Tim Kay generously sent huge files of his
tree database via email - I felt there had to be a better way. Adding the
teapot was inspired by the repeated demand on comp.graphics for this database,
certainly the most famous of all.
Many thanks to the reviewers, listed alphabetically: Kells Elmquist, Jeff
Goldsmith, Donald Greenberg, David Hook, Craig Kolb, Susan Spach, Rick Speer,
K.R. Subramanian, J. Eric Townsend, Mark VandeWettering, John Wallace, Greg
Ward, and Louise Watson. Other people who have kindly offered their ideas and
opinions on this project include Brian Barsky, Andrew Glassner, Roy Hall, Chip
Hatfield, Tim Kay, John Recker, Paul Strauss, and Chan Verbeck. These names
are mentioned mostly as a listing of people interested in this idea. They do
not necessarily agree (and in some cases strongly disagree) with the validity
of the concept or the choice of databases.
Your comments and suggestions on these databases are appreciated. Please
do send me any timing results for software and hardware which you test, or any
publications which use the SPD package. If you have made procedural models
which you consider more representative for your application (or are just plain
interesting), please do send them on for inclusion in future versions of the
SPD.
History
-------
Versions 1.0 to 1.5 released February to June, 1987 for testing.
Version 2.0 released July, 1987.
Version 2.1 released August, 1987 - corrected info on speed of the HP 320,
other minor changes to README.
Version 2.2 released November, 1987 - shortened file names to <=12 characters,
procedure names to <= 32 characters, and ensured that all lines are <= 80
characters (including return character).
Version 2.3 released March, 1988 - corrected gears.c to avoid interpenetration,
corrected and added further instructions and global statistics for ray
tracing to README.
Version 2.4 released May, 1988 - fixed hashing function for mountain.c.
Version 2.5 released October, 1988 - added NFF documentation.
Version 2.6 released August, 1989 - lib_output_cylcone fix (start_norm.w was
not initialized).
Version 2.7 released July, 1990 - comment correction in lib.c, NFF file
clarifications.
Version 3.0 released October, 1990 - added teapot.c database, mountain.c
changed to mount.c, additions to def.h and lib.c, changes to README and
NFF, added patchlevel.h file.
Version 3.1 released November, 1992 - minor typo fixes, updated FTP list,
makefile update
Version 3.1a released November, 1993 - readnff added, lib split into multiple
smaller files, mac code updated
Version 3.2 released May, 1994 - added RIB output, readdxf added, more updates
Version 3.3 released June, 1994 - added DXF output, more lib splitting, etc
Version 3.3f4 released August, 1994 - fixes to Mac files (see README.MAC),
error handling for Mac added to readnff program.
Version 3.4 released October, 1994 - Larry Gritz fixed RenderMan output.
Version 3.5 released November, 1994 - Alexander Enzmann fixed PLG output and
added Wavefront OBJ output and RenderWare RWX output, and Wavefront OBJ
reader "readobj". Deleted Mac binary files from distribution (too much
trouble, and a Mac sit version is distributed separately).
Version 3.6 released April, 1995 - vertex order fixes by Enzmann and Michael
Jones, Enzmann added jacks and transformation support, other minor cleanup.
drv_hp.c changed to reflect changes to view transform output.
Version 3.7 released July, 1995 - typo fix in NEW_HASH area of mount.c
Version 3.8 released November, 1995 - polygonalized cones output incorrect
normals; fix to libply.c to correct this.
Version 3.9 released December, 1996 - 3DMF and VRML 2.0 exporters added by
Enzmann, cleanup of documentation files, size now affects sombrero.c.
Added optional control of tessellation to command line (-t #). Corrections
to object tessellators (removed unneeded tessellation, made default
settings better).
Version 3.10 released May, 1997 - X11R6 driver from Bob Kozdemba, and minor
fixes to code for wider compiler compatibility. 3DMF fixes. Documentation
fixes.
Version 3.11 released June, 1997 - fixes to RIB export from Matt Pharr.
Version 3.12 released October, 1998 - added VRML 1.0 export by Aleksandar
Samardzic, added to mount.c much better JENKINS_HASH from Mark
Vandewettering, POVRAY 3.0 export & ANSI headers & Mac fixes from Eduard
Schwan, cleanup of indentation (4 spaces == tab now), VRML shading fixes,
and consolidation and rewrite of READMEs.
Version 3.13 released November, 1999 - Changed lib_output_color interface:
the "ang" code was off by a factor of 2. This means that if you call
the new lib_output_color with old code you will want to multiply your
input "ang" by 2 before passing it down. The database generators were
also changed to their original, 1987 specular power values, in terms of
the half-angle "ang". Changed documentation about "Shine" to be clearer
in the code ("Shine" is the amount the specular highlight contributes to
the surface), and cleaned up code comments. Fixed readnff.c (better
ks_spec value output) and libpr1.c (ang not set below 1.0 if 0.0 is
detected). Better VRML specular highlight output. Gears background color
made blue, to enhance visibility of transparent gears. Better command
line argument checking. Heightfield export improvement (I hope!).
Version 3.14 released February, 2005 - Changed libpr1.c to output correctly
for newer versions of prman to render the SPD models. All changes from
Alfred Young at Tippett Studio. He writes: 1. The shadows are now
raytraced with the "shadowspot" light shader so as to make it a single
render pass. 2. There isn't a particular display driver noted with the
output RIB, and I didn't add it because of the nature of this package.
I'm assuming if anyone wants to render to screen or file, they'll be able
to add the line in themselves, i.e.: Display "balls.tif" "tiff" "rgba"
Version 3.15 (unofficial) released December, 2012 - Changes from Sam Thompson;
A consolidation of patches and fixes applied separately since mid '90s, as
part of support for benchmarking personal RT project "Arise". Added support
for compilation under Windows with more recent VisualC and MinGW
environments as well as clang under MacOSX. Numerous small bug fixes and
tweaks to reduce compiler noise. Larger fixes for issues with torus output
for RIB, sombrero (height field) output for PLG (REND386), delayed output
code for NURBS and discs (affecting RTrace 8.0.0 and PLG formats), texture
instancing for efficiency (affecting RTrace) and database naming/size
globals, in preparation for adding support for Arise's description
language. Loaded versions 3.4, 3.6, 3.12 - 3.14 to DVCS and released on Web.
-end-