SFF.TXT

SFF.TXT


Remove Frame

----- SFF -----

The SFF ray-tracing format
 
Version 8

Anto'nio Costa, 1993
[email protected]


Table of Contents

Table of Contents 2
1. Introduction 3
2. Overview and Motivations 3
3. Main Sections 3
3.1. Viewing 3
3.2. Ambient and Background 4
3.3. Lights 4
3.4. Surfaces 4
3.5. Objects, Textures and Transformations 5
4. Compatibility 11
5. Examples 12
6. Conclusions 1 3
7. References 13
8. Annexes 14
8.1. Annex 1 - Font formats PPF and PPE 14
8.2. Annex 2 - CSG Example 17
8.3. Annex 3 - Textured Spheres Examples 18
8.4. Annex 4 - Striped Spheres Example 20


1. Introduction

The SFF (Simple File Format) is a simple way of describing geometry 
(3D objects), colors, surfaces and so on. It is mainly used to describe 
environments that are processed by programs called ray-tracers, 
which simulate, at least to a certain extent, the physics of optical
processes and interactions between light and matter.

The ray-tracing algorithm produces images of 3D objects by shooting 
rays from a point in space (called eye point) through a grid of 
points (centered in the look point) and then computing, for each of 
these directions (which correspond basically to a screen pixel), the 
color of the nearest object in that particular direction. For the 
color calculation, the object's surface perpendicular vector (also called 
normal vector) in the point of intersection with the ray is used to 
determine the directions of auxiliary rays such as reflected and 
transmitted rays, along with the light sources contributions. Each of these 
contributions is scaled according to the object's surface characteristics 
and then the pixel color is finally obtained and stored.

2. Overview and Motivations

The first version of the SFF format was defined in late 1988, when 
the first running version of the RTRACE ray-tracer was operational. 
As this program was first written in Pascal, one major goal of SFF 
was simplicity. As the Pascal language is not very good in I/O 
support, the objective was to define it simple enough so that it 
would not be too complicated to parse.

Another simple scene format is NFF (Neutral File Format), invented 
by Eric Haines for his SPD package (Standard Procedural Database - 
a collection of C programs that generates test scenes for any type 
of rendering programs, including ray-tracers). It is widely used, 
but does not support many advanced features. Within the RTRACE package
there is a program to translate NFF scenes to SFF (it runs on UNIX 
and DOS machines).

3. Main Sections

Any SFF file is divided into 5 sections (or 6, for compatibility 
purposes). In each one there are definitions, which can be of several types.

3.1. Viewing

This section is the first one to appear. It has 5 lines, in which 
the first is reserved for comments, and then come eye point, look 
point, up vector and finally horizontal/vertical view angles. Each of 
these items must be in a line. After each one, anything can follow 
up to the end of line.
 
Example:

viewr
8 0 0- Eye<EOL>
0 0 0- Look<EOL>
0 1 0- Up<EOL>
20 20- View angles (horizontal and vertical)<EOL>

3.2. Ambient and Background

After the viewing section comes the Ambient/Background section. It 
has 3 lines, in which the first one is reserved for comments, the 
second defines the background color and the last defines the ambient 
color (in RGB format, both). After each item there may be comments 
up to the end of line. 

Example:

colors<EOL>
0.1 0.5 0.7- Sky blue(red=0.1 green=0.5 blue=0.7)<EOL>
0.2 0.2 0.2- Dark gray(red=0.2 green=0.2 blue=0.2)<EOL>

3.3. Lights

The Lights section defines lights, which can be of 3 types. Normally,
the illumination decreases with distance; to make it distance-
independent, the brightness should be negative (at least one component).
The first line is for comments, and then each line defines a light. 
To end the section, there must be an empty line.
The point light is defined by code 1, a position and RGB brightness.
The directional light is defined by code 2, position, RGB brightness, 
direction, angle and attenuation factor. This kind of light irradiates 
from a point in the specified direction inside the solid 
angle, and the transition may be sharp (factor ~= 1) or soft 
(factor >> 1). A truly directional light may be simulated by 
positioning it far away from the objects and defining its brightness 
negative.  The extended light is defined by code 3, position, 
RGB brightness, radius and samples. This 
kind of light is simulated by a sphere of specified radius, which 
is sampled to calculate the actual illumination (a low value for samples 
produces undesirable effects).

Example:

lights<EOL>  
1  4 5 1  0.9 0.9 0.9- White point light<EOL>
2  0 10 0  0 0 1  0 -1 0  15 5- Blue spot light<EOL>
3  8 1 -3  0 1 0  0.3 8- Green extended light<EOL>
1  1000 1000 1000  -1 -1 -1- Directional light<EOL>
<EOL>

3.4. Surfaces

In this section all the surfaces used must be defined. It starts with a 
line reserved for comments and then a line for each surface, ending in 
an empty line. There are 2 types of surface definitions.

The code 1 defines a surface by body RGB color, diffuse RGB factor, 
specular RGB factor, specular exponent factor, metalness factor and 
transmission RGB factor. The RGB's colors and factors must be in the 
[0,1] range. The diffuse RGB factor defines the quantity of light coming 
from all directions. The specular RGB factor defines the quantity of 
light coming from the ideal reflection direction. The exponent factor 
controls the shininess of the surface (the surface is very shiny with factors 
bigger than 10; if near zero, it appears dull). The metalness factor makes 
the reflected light appear white if it is small (like in plastic) 
or metallic if it is near 1. The transmission RGB factor defines the 
transparency. The sum of diffuse, specular and transparency RGB factors 
should be equal or approximately 1.

The code 2 surface has body RGB color, smoothness RGB factor, metalness 
RGB factor and transmission RGB factor. This is an alternative for 
defining surfaces, but this method is more intuitive. The smoothness 
RGB factor controls the shininess of the surface. 

Example:

surfaces<EOL>
1  1 0 0  1 1 1  0 0 0  0 0  0 0 0    - Matte<EOL>
1  0 1 0  0.5 0.5 0.5  0.5 0.5 0.5  10 0.5   0 0 0<EOL>
1  0 0 1  0.7 0.8 0.9  0.3 0.2 0.1  100 1    0 0 0   - Metallic<EOL>
1  1 1 1  0.1 0.1 0.1  0.1 0.1 0.1  200 0.8  0.8 0.8 0.8<EOL>
2  1 1 0  0 0 0  0 0 0  0 0 0   - Matte<EOL>
2  1 0 1  1 1 1  1 1 1  0 0 0   - Mirror<EOL>
<EOL>

3.5. Objects, Textures and Transformations

This next section defines the 3D objects, and optionally, textures and 
transformations. It starts with a line reserved for comments and then by 
object definitions. All objects are defined by a code, a surface index 
(which specifies one of the previously defined surfaces, starting in 1), 
a refraction index and then specific data.

The object with code 1 is a sphere and has a center point and radius. 

Example:

1  3  1.0  4 3 2  0.5- Sphere centered at (4,3,2) radius=0.5<EOL>

The object with code 2 is a parallelipiped aligned with the XYZ axis. 
It requires a center point and 3 dimensions for X, Y and Z directions. 

Example:

2  2  1.0  1 0 0  10 1 3- Box at (1,0,0) with sizes (+-10,+-1,+-3)<EOL>

The object with code 3 is a bicubic patch or a group of bicubic patches. 
It is followed by a translation vector, 3 scale factors for X, Y and Z, 
and by a filename or "-". If there is a filename, then the patch's 
geometry is read from that file, else it is read from the following lines 
in the SFF file ending with an empty line. 

Example:

3  1  1.0  0 0 0  1 1 1  example.pat- Read from file example.pat<EOL>
3  2  1.0  0 0 0  2 1 1  -  Read from the next lines<EOL>
...

A bicubic patch is defined by 12 points, arranged like in the figure:
 
Points P4, P5, P8 and P9 define the patch corners. The other points are 
used in the definition of the frontiers and curvature of the patch. The 
patch normal points outwards the screen (in P4-P8-P9-P5 counterclockwise 
order, similar to the Right Hand rule). A file with patches is composed 
of 2 parts. In the first come the patch's definitions using indices 
into the vertex list, which is separated by a line and comes next 
(and terminates by another empty line). 

Example:

1 2 4 5 6 7 9 10 11 12 14 15- Patch 1<EOL>
2 3 5 6 7 8 10 11 12 13 15 16- Patch 2<EOL>
<EOL>
0 -0.5 -1- Vertex 1<EOL>
0 0 -2- Vertex 2<EOL>
0 -0.5 -3<EOL>
1 0 0<EOL>
1 0 -1<EOL>
1 0.5 -2<EOL>
1 0 -3<EOL>
1 0 -4<EOL>
2 0 0<EOL>
2 0 -1<EOL>
2 0.5 -2<EOL>
2 0 -3<EOL>
2 0 -4<EOL>
0 -0.25 -1<EOL>
0 0 -2<EOL>
0 0 -3<EOL>
<EOL>

Please note that the vertex list starts in index 1. Using these 2 lists, 
it is possible to save a lot of space by avoiding redundant vertex 
specification, and at the same time with only one definition create 
many of these bicubic patch objects. Next figure is a picture of the 
patch data of the above example.
 
Another example is in the next figure. The vase has 72 vertices and 64 
patches. The main disadvantage of the patch primitive is the complexity 
of finding intersections of rays with its surface. As it uses an 
iterative algorithm with lots of floating-point operations, it takes 
much more time to produce a picture, when compared to spheres and boxes.

The code 4 object is a cone or cylinder. It has an apex center point and 
radius, followed by base center point and radius. The apex radius must 
be less (in this case the object is a cone) or equal (cylinder) to the 
base radius. The cone/cylinder are opened objects, ie, they do not have 
any circular surfaces in the apex or base.

4  1  1.0  0 1 0  0  0 0 0  1- Cone<EOL>
4  1  1.0  0 1 0  1  0 0 0  1- Cylinder<EOL>

The code 5 object is a polygon or a group of polygons, similar to 
patches. It is followed by a translation vector, 3 scale factors for X, 
Y and Z, and by a filename or "-". If there is a filename, then 
the polygon's geometry is read from that file, else it is read from 
the following lines in the SFF file, ending with an empty line. 

Example:

5  1  1.0  0 0 0  1 1 1  example.pol- Read from file example.pol<EOL>
5  2  1.0  0 0 0  1 1 1- Read from the next lines<EOL>
...

A polygon is defined by its vertices in counterclockwise order. A file with 
polygons is composed of 2 parts. In the first come the number of polygons 
and the polygon's definitions using indices into the vertex list, which 
is separated by a line and comes next (and terminates by another empty 
line). 

Example:

5  1 2 3 4 5- polygon 1<EOL>
3  1 6 2- polygon 2<EOL>
<EOL>
0 0 -2- vertex 1<EOL>
1 0 0- vertex 2<EOL>
2 0 -1- vertex 3<EOL>
2 0 -3- vertex 4<EOL>
1 0 -4- vertex 5<EOL>
0.5 2 -1- vertex 6<EOL>
<EOL>

The next figure is an image of the previous 2 polygons. Please note again 
that it is possible to save a lot of disk space with the specification 
of the polygon's list and vertices list in separate. The polygon's 
normal is computed using the first 3 vertices in the following way: 
vector from polygon's vertex #2 to polygon's vertex #1 *  vector from 
polygon's vertex #3 to polygon's vertex #1. In the figure, the normal 
of polygon #2 points to the right and out of the screen (its first 3 
vertices are shown, along with the auxiliary vectors). Polygon's #1 
normal points vertically up.
 
The code 6 object is a triangle or a group of triangles, similar to 
polygons, but specifying also each vertex normal vector (these triangles 
are also known as Phong triangles). It is followed by a translation vector, 
3 scale factors for X, Y and Z, and by a filename or "-". If there is 
a filename, then the triangle's geometry is read from that file, else 
it is read from the following lines in the SFF file, ending with 
an empty line. 

Example:

6  1  1.0  0 0 0  1 1 1  example.tri- Read from file example.tri<EOL>
6  2  1.0  0 0 0  1 1 1- Read from the next lines<EOL>
...

A triangle is defined by its vertices (data and normal) in counterclockwise 
order. A file with triangles is composed of the triangle's definitions 
in each line with first vertex data and normal, followed by the second 
vertex data and normal and finally the third vertex data and normal 
(and terminates by another empty line). 

Example:

0 0 0 0 1 0  1 0 0 0 1 0  1 0 -1 0 1 0- Triangle 1<EOL>
0 0 0 1 1 0  0 1 0 1 0 0  0 1 -1 1 0 1- Triangle 2<EOL>
...

In this example, the first triangle has vertices (0,0,0) (1,0,0) 
and (1,0,-1). The normals at these vertices are (0,1,0) (0,1,0) and 
(0,1,0), ie, they all have the same direction. The second triangle has 
vertices (0,0,0) (0,1,0) and (0,1,-1). Its normals are (1,1,0) 
(1,0,0) and (1,0,1).

The code 7 object is an extruded primitive derived from closed segments 
composed by lines and splines. This object is very well suited to trace 
high quality text, although it may be used for many other purposes. It 
is followed by a filename or "-". If there is a filename, then the 
character's geometry is read from that file, else it is read from 
the following lines in the SFF file, ending with an empty line.

Example:

spacing     0.1<EOL>
orientation 0 0 -1  0 1 0  1 0 0<EOL>
encoding    ascii.ppe<EOL>
font        roman.ppf<EOL>
scale       0.4 0.4 0.2<EOL>
at          1 1 2  "RTrace /copyright/ Antonio Costa 1993"<EOL>
font        times.ppf<EOL>
scale       0.5 0.6 0.3<EOL>
at          0 3 0  "Etc"<EOL>
...

The spacing keyword defines the separation between characters. Most 
of the supplied fonts have its characters enclosed in a 1 unit square. 
The orientation keyword defines how the text appears in the 3D space; 
the first vector defines the text direction, the second the up 
direction and the third the extrusion direction. As these are 
independent, it is possible to slant the text or create more complex 
effects. The encoding keyword specifies a file which contains 
translations from character names to character codes, which are 
used to access the character data. The font keyword specifies a 
file which contains the character's data (number of closed 
segments - lines and splines - and other data for each character). 
The scale keyword defines the scaling for the characters, using the 
directions specified with the orientation keyword. Finally, the at 
keyword specifies the starting baseline position and which 
characters to trace. With the supplied font files, it is possible 
to use POSTSCRIPT names for the characters in almost all languages; in 
this case, the character name must be enclosed in / /.

The next figure is an example of high quality text with textures. Please 
note the use of international characters like c and g, because they 
are supported in the font files. The second line is similar to the first 
except in the scale, which is wider. The fourth line uses a different 
font file. As the characters use a very precise mathematical description 
which is used to trace them, they result much better than approximating 
them with small polygons (which do not produce the same quality and 
increase the tracing time). A description of font files is in Annex 1.
 
The next codes are not used to define primitive objects, but rather 
to associate, transform or texture objects. The code 64 defines a 
texture to be applied to an object, usually the previous none. It is 
followed by a type, an object id, a transformation matrix and local 
data. The supported types are:



Type	Name		Parameters

0	Null

1	Checker		surface

2	Blotch		scale   surface   [file(colormap)]

3	Bump		scale

4	Marble		[file(colormap)]

5	FBM		offset   scale   omega   lambda   threshold   octaves

6	FBM Bump	offset   scale   lambda   octaves

7	Wood		color(red)   color(green)   color(blue)

8	Round		scale

9	Bozo		turbulence   [file(colormap)]

10	Ripples		frequency   phase   scale

11	Waves		frequency   phase   scale

12	Spotted		[file(colormap)]

13	Dents		scale

14	Agate		[file(colormap)]

15	Wrinkles	scale

16	Granite		[file(colormap)]

17	Gradient	turbulence   direction(x)   direction(y)   
			direction(z)   [file(colormap)]

18	Imagemap	turbulence   mode   axis(horizontal)   
			axis(vertical)   file(image)

19	Gloss		scale

20	Bump 3D		scale   size


The object id is a number that identifies a previously defined object 
(the first object has number 1; 0 means the previous object). The 
transformation matrix is a group of 16 real numbers that defines a 
4x4 matrix - the first 4 numbers specify the first column of the 
matrix and so on (the last column usually is 0 0 0 1, but may be different!).

The code 65 defines a transformation to be applied to an object, usually 
the previous none. It is followed by an object id and transformation 
matrix data. The order is X1 Y1 Z1 W1 ... X4 Y4 Z4 
W4. The matrix is like:

X1X2X3X4
Y1Y2Y3Y4
Z1Z2Z3Z4
W1W2W3W4
SUM Wi != 0

The code 66 is used to apply CSG (Computer Solid Geometry) operations to 
the previously defined objects. A CSG operation has always two components 
which are combined into an higher level object. This CSG object can be 
the union, the subtraction or the intersection of two objects. Any CSG 
object can have CSG objects as its components. The main restriction 
is that the components must always define a closed volume in 3D space. 
It is followed by type and type-dependent data like in the table:




Type	Explanation			Parameters

0	Start of left components	surface refraction operation

1	Start of right components

2	End

The CSG operations are union (0), subtraction (1) and intersection (2). 
The surface id may be zero; in this case the color of the CSG object 
is the result of the colors of the its components. 

Example:

66 0 1 1 1 - CSG subtraction<EOL>
1    2 1  0 0 0 1- Sphere at (0,0,0) radius=1<EOL>
66 1- Right component of CSG<EOL>
1    3 1  0 1 0 0.6- Sphere at (0,1,0) radius=0.6<EOL>
2    3 1  1 0 0 0.5 0.5 0.5- Box at (1,0,0) sizes=0.5,0.5,0.5<EOL>
66 2- End of CSG<EOL>

The resulting object is in the next figure. Its SFF description is in 
Annex 2.
 
It is very important not to have aligned faces in the CSG objects (or 
aligned edges too), because the CSG operations are very sensitive to 
numerical inaccuracies.

The code 67 is used to group objects so that the whole set of objects is 
treated like a primitive object. This is mainly used with CSG operations 
so that there are no non-closed objects in the CSG object. It is 
followed by a surface id and refraction. If the surface id is non-zero 
then the list object has a color, which supersedes the individual colors. 

Example:

67 0 0 1- Start of list<EOL>
4 1 1  0 1      0 1     0 0 0 1- Cylinder (opened)<EOL>
4 1 1  0 1.001  0 0.001 0 1 0 1- Cone (very flat)<EOL>
4 1 1  0 -0.001 0 0.001 0 0 0 1- Cone (very flat)<EOL>
67 1- End of list<EOL>

This object (closed cylinder) can be safely used inside any CSG operation; 
otherwise, some errors would appear in the ray traced image.  


4. Compatibility

For compatibility with old SFF files, the textures can be specified 
completely after the objects. In this case, there must be an empty line 
after the objects section and then the textures may be defined. The 
code 64 should not appear in the line. 

Example:

objects<EOL>
1 1 1  0 0 0 1- Sphere<EOL>
2 2 1  0 2 0 1 1 1- Box<EOL>
<EOL>
textures<EOL>
3 1  1 0 0 0  0 1 0 0  0 0 1 0  0 0 0 1  0.4- Bump<EOL>
9 2  2 0 0 0  0 1 0 0  0 0 1 0  0 0 0 1  0.5 bozo.map- Bozo+colormap<EOL>
<EOL>


5. Examples

The supported textures allow for an immense variation of colors, patterns, 
etc. Next there are some examples. The SFF descriptions of these spheres 
is in Annex 3.

  Agate.     Blotch.     Bozo.

Also it is possible to modify the primitive objects using transformations 
like in the next examples.

Sphere stretched in one direction and squashed in another direction. The 
description of the two spheres with textures is like:

1 2 1 0 1 0 1- Top sphere<EOL>
64 0 0 1 0 0 500 0 1 0 500 0 0 1 0 0 0 0 1- Translate texture<EOL>
64 1 0 1000 0 0 0 0 1000 0 0 0 0 0.25 0 0 0 0 1 3 - Scale texture<EOL>
1 2 1 0 -1 0 1- Bottom sphere<EOL>
65 0 0.5 0 0 0 0 1 0 0 0 0 2 0 0 0 0 1- Stretch and squash<EOL>
64 0 0 0.5 0 0 0 0 1 0 0 0 0 2 0 0 0 0 1- Texture on normal sphere<EOL>
64 0 0 1 0 0 500 0 1 0 500 0 0 1 0 0 0 0 1<EOL>
64 1 0 1000 0 0 0 0 1000 0 0 0 0 0.25 0 0 0 0 1 3<EOL>

In this example, a new type of object is created by scaling a sphere 
differently in the 3 axis directions. To apply a texture to an object 
independently of its object transformations (invariant texture), all 
you have to do is to list the transformations as texture transformations 
in reverse order. The full description of this scene is in Annex 3.

Box with shear in one direction. The description of the two boxes is like:

2 2 1 0 1 0 1 0.95 1<EOL>
22 2 1 0 -1 0 1 0.95 <EOL>
65 0 1 0 0 0 0 1 0 0 0 -1 1 0 0 0 0 1- Shear matrix<EOL>

The shear is achieved by making the Z axis information dependent of the 
Y coordinate (the -1 creates that effect).


6. Conclusions

This simple format has proved suitable for use in many environments. Even 
so, it is very complicated to use interactively, so a better format (in 
the sense of abstraction and ease of writing) has been developed to 
replace it. It is called SCN (scene format) and makes things much 
more easy to do. The converter from SCN to SFF is called SCN2SFF 
and runs on the same platforms as RTRACE.

To fully understand this format, it is recommended that you read first 
the program's manual so that you have a minimal idea of the options of 
RTRACE and so on.


7. References

Reid Judd, Anto'nio Costa and Greg Ferrar - RTRACE 1.0 for the Macintosh User 
Manual

Pedro Borges, Paulo Almeida, Anto'nio Costa - Extrusion Objects for 3D Text


8. Annexes

8.1. Annex 1 - Font formats PPF and PPE

The PPF files describe objects made from the extrusion of closed lines. 
These closed lines can be straight line segments or cubic Bizier segments. 
The restriction of being closed allows these lines to be specified by 
only 3 points for Bizier and just 1 point for straight segments. The 
last point of one segment is always the starting point of the next.

In the next figure all the control points are showed, and it could be 
used to generate a 'D' letter:
 
The lower left corner is (0,0) and the upper left is (0,23). Its description 
could be something like:

letter 'D'  name
2  number of closed lines
4  number of segments of the 1st line
line0 0  straight line
line0 23
cubic8 23   25 21   23 0  Bezier; starts in (8,23)
line8 0
1  number of segments of the 2nd line
cubic6 15   4 -6   23 17  one Bezier curve only

The actual PPF description is:

/D# name (the slash is mandatory)<EOL>
2# number of closed lines<EOL>
4# number of segments of 1st line<EOL>
l 0 0# start<EOL>
l 0 23# line<EOL>
c 8 23 25 21 23 0# cubic<EOL>
l 8 0# line<EOL>
1# number of segments of 2nd line<EOL>
c 6 15 4 -6 23 17# cubic<EOL>

Any PPF file may contain any number of definitions like the last one 
(the supplied files usually have about 96 character definitions each). 
Any character must have a unique name inside a PPF file (it is a good 
idea to use the names that appear in the Postscript Language Reference 
Manual). To avoid remembering all those names, it is possible to define 
a mapping between character codes and names. 

Characters that do not appear in the mapping file (PPE) may only be 
accessed by its original name. 

Example:

...
64/at# code 64(@) represents 'at'<EOL>
65/A# code 65(A) represents 'A'<EOL>
66/backslash# code 66(B) represents 'backslash'<EOL>
67/copyright# code 67(C) represents 'copyright'<EOL>
68/D# code 68(D) represents 'D'<EOL>
...

A complete example of a tank created with this type of objects follows. 
First, it was necessary to create a specific PPF file (tank.ppf) that 
contains all the tank extruded parts:

# tank<EOL>
/wheels<EOL>
1<EOL>
6<EOL>
l 4 0<EOL>
c 16 0 18 0 20 2<EOL>
c 20 3 20 4 18 4<EOL>
l 16 4<EOL>
c 4 4 2 4 0 3<EOL>
c 0 2 0 1 2 0<EOL>
/body<EOL>
1<EOL>
6<EOL>
l 5 1<EOL>
c 15 1 18 1 18 2<EOL>
c 18 3 18 4 13 5<EOL>
l 12 5<EOL>
c 8 5 5 5 2 4<EOL>
c 2 3 2 2 4 1<EOL>
/tower<EOL>
1<EOL>
4<EOL>
c 10 -10 14 -10 20 -4<EOL>
c 20 0 20 4 14 10<EOL>
c 10 10 6 10 0 10<EOL>
c 0 0 0 -10 6 -10<EOL>
/cannon<EOL>
1<EOL>
2<EOL>
c 1 0 1 1 -1 1<EOL>
c -1 0 -1 -1 1 -1<EOL>

The SFF file for this example is:

view<EOL>
28 -9 9<EOL>
12.5 5 2<EOL>
0 0 1<EOL>
30 30<EOL>
colors<EOL>
0.1 0.4 0.7<EOL>
0.6 0.6 0.6<EOL>
lights<EOL>
1 20 20 40 1 1 1<EOL>
1 30 -10 10 2 2 2<EOL>
1 -30 -60 10 4 4 4<EOL>
2 -300 400 10 0 0 -1 -1 -1 -1 89.8<EOL>
<EOL>
surfaces<EOL>
1 0.5 0.7 0.5 0.3 0.3 0.3 0.7 0.7 0.7 70 0.7 0 0 0<EOL>
1 0.6 0.4 0.3 1 1 1 0 0 0 0 0 0 0 0<EOL>
<EOL>
objects<EOL>
7 1 1 tank.t3d<EOL>
2 2 1 0 0 0 1000 1000 0.01<EOL>
<EOL>
end<EOL>

Finally, the tank is described in tank.t3d like:

spacing0.1<EOL>
orientation1 0 0 0 0 1 0 1 0<EOL>
fonttank.ppf<EOL>
encodingascii.ppe<EOL>
scale1 1 2<EOL>
at0 0 0 "/wheels/"<EOL>
at0 8 0 "/wheels/"<EOL>
scale1 1 6<EOL>
at0 2 0 "/body/"<EOL>
scale0.4 0.28 2<EOL>
orientation1 0 0 0 1 0 0 0 1<EOL>
at6 5 5 "/tower/"<EOL>
scale0.5 0.5 8<EOL>
orientation0 1 0 0 0 1 1 0 0<EOL>
at10 5 6 "/cannon/"<EOL>

The resulting picture is in the next figure:
 

8.2. Annex 2 - CSG Example

The full description of the CSG scene is:

view<EOL>
3 1 1<EOL>
0 0 0<EOL>
0 1 0<EOL>
20 20<EOL>
colors<EOL>
1 1 1<EOL>
0.2 0.2 0.2<EOL>
lights<EOL>
1 3 2 2 1 1 1<EOL>
<EOL>
surfaces<EOL>
1 0 1 0 1 1 1 0 0 0 0 0 0 0 0<EOL>
1 1 1 1 1 1 1 0 0 0 0 0 0 0 0<EOL>
1 1 1 0 1 1 1 0 0 0 0 0 0 0 0<EOL>
<EOL>
objects<EOL>
66 0 1 1 1 - CSG subtraction<EOL>
1    2 1  0 0 0 1- sphere at (0,0,0) radius=1<EOL>
66 1- right component of CSG<EOL>
1    3 1  0 1 0 0.6- sphere at (0,1,0) radius=0.3<EOL>
2    3 1  1 0 0 0.5 0.5 0.5- box at (1,0,0) sizes=0.5,0.1,0.1<EOL>
66 2- end of CSG<EOL>
<EOL>
end<EOL>


8.3. Annex 3 - Textured Spheres Examples

Agate example:

view<EOL>
1.6 1.6 1.6<EOL>
0 0 0<EOL>
0 1 0<EOL>
22.5 22.5<EOL>
colors<EOL>
0.2 0.5 0.7<EOL>
0.1 0.1 0.1<EOL>
lights<EOL>
1 57735.03 57735.03 -57735.03 -1 -1 -1<EOL>
<EOL>
surfaces<EOL>
1 0.9 0.9 0.9 0.9 0.9 0.9 0.1 0.1 0.1 4 0 0 0 0<EOL>
<EOL>
objects<EOL>
1 1 1 0 0 0 1<EOL>
64 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 earthtones.map<EOL>
<EOL>
end<EOL>

Blotch example:

view<EOL>
1.6 1.6 1.6<EOL>
0 0 0<EOL>
0 1 0<EOL>
22.5 22.5<EOL>
colors<EOL>
0.2 0.5 0.7<EOL>
0.1 0.1 0.1<EOL>
lights<EOL>
1 57735.03 57735.03 -57735.03 -1 -1 -1<EOL>
<EOL>
surfaces<EOL>
1 1 0 0 0.999 0.999 0.999 0 0 0 0 0 0 0 0<EOL>
1 1 1 0 0.999 0.999 0.999 0 0 0 0 0 0 0 0<EOL>
<EOL>
objects<EOL>
1 1 1 0 0 0 1<EOL>
64 2 0 0.1 0 0 0 0 0.1 0 0 0 0 0.1 0 0 0 0 1 0.4 2 -<EOL>
<EOL>
end<EOL>

Bozo example:

view<EOL>
1.6 1.6 1.6<EOL>
0 0 0<EOL>
0 1 0<EOL>
22.5 22.5<EOL>
colors<EOL>
0.2 0.5 0.7<EOL>
0.1 0.1 0.1<EOL>
lights<EOL>
1 57735.03 57735.03 -57735.03 -1 -1 -1<EOL>
<EOL>
surfaces<EOL>
1 0.9 0.9 0.9 0.9 0.9 0.9 0.1 0.1 0.1 4 0 0 0 0<EOL>
<EOL>
objects<EOL>
1 1 1 0 0 0 1<EOL>
64 9 0 2 0 0 0 0 2 0 0 0 0 2 0 0 0 0 1 1 earthtones.map<EOL>
<EOL>
end<EOL>

The color map file used (earthones.map) is:

40 128 200<EOL>
40 128 200<EOL>
41 129 201<EOL>
... + 250 colors ...
254 255 253<EOL>
254 255 253<EOL>
254 255 253<EOL>
<EOL>
Earth Tones<EOL>


8.4. Annex 4 - Striped Spheres Example

This is the full description for the two striped spheres of chapter 5:

view<EOL>
7 3 2<EOL>
0 0 0<EOL>
0 1 0<EOL>
22.5 22.5<EOL>
colors<EOL>
1 1 1<EOL>
0.1 0.1 0.1<EOL>
lights<EOL>
1 6 2 2 1 1 1<EOL>
<EOL>
surfaces<EOL>
1 0.7 0.7 0.7 0.999 0.999 0.999 0 0 0 0 0 0 0 0<EOL>
1 0 1 0 0.999 0.999 0.999 0 0 0 0 0 0 0 0<EOL>
1 1 1 1 0.999 0.999 0.999 0 0 0 0 0 0 0 0<EOL>
<EOL>
objects<EOL>
4 1 1 1.5 1 0 0.05 0 1 0 0.05<EOL>
4 1 1 1.5 1 0 0.1 1.8 1 0 1e-07<EOL>
4 1 1 0 1 1.5 0.05 0 1 0 0.05<EOL>
4 1 1 0 1 1.5 0.1 0 1 1.8 1e-07<EOL>
4 1 1 1.5 -1 0 0.05 0 -1 0 0.05<EOL>
4 1 1 1.5 -1 0 0.1 1.8 -1 0 1e-07<EOL>
4 1 1 0 -1 2.5 0.05 0 -1 0 0.05<EOL>
4 1 1 0 -1 2.5 0.1 0 -1 2.8 1e-07<EOL>
1 2 1 0 1 0 1<EOL>
64 0 0 1 0 0 500 0 1 0 500 0 0 1 0 0 0 0 1<EOL>
64 1 0 1000 0 0 0 0 1000 0 0 0 0 0.25 0 0 0 0 1 3<EOL>
1 2 1 0 -1 0 1<EOL>
65 0 0.5 0 0 0 0 1 0 0 0 0 2 0 0 0 0 1<EOL>
64 0 0 0.5 0 0 0 0 1 0 0 0 0 2 0 0 0 0 1<EOL>
64 0 0 1 0 0 500 0 1 0 500 0 0 1 0 0 0 0 1<EOL>
64 1 0 1000 0 0 0 0 1000 0 0 0 0 0.25 0 0 0 0 1 3<EOL>
<EOL>
end<EOL>

To ray trace these examples and produce the pictures (fast and with low 
quality), assuming the SFF file was called spheres.sff, the ray tracer 
should be executed like:

rtrace t1 O1 m0 spheres.sff spheres.ppm

For an high quality rendering, use instead:

rtrace t1 O1 p2 A0.075 spheres.sff spheres.ppm

 * represents cross-product of two vectors.



----- end of SFF -----