Also Known As: SFF, SCN
| Type | Scene description |
| Colors | NA |
| Compression | Uncompressed |
| Maximum Image Size | NA |
| Multiple Images Per File | NA |
| Numerical Format | NA |
| Originator | António Costa |
| Platform | All |
| Supporting Applications | RTrace |
| See Also | DKB, NFF, POV, PRT, QRT, Rayshade |
Usage
3D scene description used for ray-trace and other rendering applications.
Comments
RTrace is a simple but well-designed format that could find general use for describing 3D scenes.
Vendor specifications are available for this format.
The RTrace format (called SFF by its author) was created by António Costa and is associated with his ray-trace application, RTrace. Work on both the application and the format date from 1988. The format itself was designed to support the description of 3D scenes. Although it was originally intended for ray-trace applications, it could just as well be used for other renderers. RTrace would be a good format to study if you are in the process of writing yet another ray trace or rendering application.
Contents:
File Organization
File Details
For Further Information
In his program documentation, António Costa mentions, as a motivation for producing a new format, limits embodied in Eric Haines' NFF format.
Like many ray trace formats, RTrace implements the scene description language in its own application. The RTrace format consists of a series of ASCII text lines and is designed to be human-readable and easily edited.
The following information is based on António Costa's documentation, The SFF Ray-Tracing Format, Version 8.
An RTrace (SFF) file is divided into five sections (sometimes six, for compatibility reasons). In each, there are definitions, which may be of several types:
The Viewing section is the first to appear. It has five lines consisting of:
Comments
Eye point
Look point
Up vector
Horizontal and vertical view angles
Each of these items must be on a separate line. Comments can follow up to the end of the 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>
The Ambient and Background section follows the Viewing section. It contains three lines:
Both background color and ambient color are defined in RGB format.
After each item there may be comments up to the end of the 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>
The Lights section contains a series of lines:
There are three types of light definitions:
To define a point light, specify the point code (1), a position, and RGB brightness.
To define a direction light, specify the directional code (2), a position, RGB brightness, direction, angle, and attenuation factor. This kind of light radiates 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 to be negative. Normally, illumination decreases with distance; to make illumination distance-independent, make at least one component of the brightness negative (at least one component).
To define an extended light, specify the extended code (3), a 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 frequency of 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>
The Surfaces section defines all of the surfaces. It consists of a series of lines:
There are two types of surface definitions:
A code 1 surface definition 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 a factor bigger than 10; if the factor is near zero, the surface appears dull). The metalness factor makes the reflected light appear white if it is small (as 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.
A code 2 surface definition has a body RGB color, a smoothness RGB factor, a metalness RGB factor, and a transmission RGB factor. This method is an alternative for defining surfaces, but it 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>
The Objects, Textures, and Transformations section defines the 3D objects, and, optionally, the textures and transformations. It consists of a series of lines, plus one line for each object definition.
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 the data itself.
Example 1:
The object with code 1 is a sphere and has a center point and radius.
1 3 1.0 4 3 2 0.5 - Sphere centered at (4,3,2) radius=0.5 <EOL> *
Example 2:
The object with code 2 is a parallelipiped aligned with the XYZ axis. It requires a center point and three dimensions, for the X, Y, and Z directions.
2 2 1.0 1 0 0 10 1 3 - Box at (1,0,0) with sizes (+-10,+-1,+-3) <EOL>
Example 3:
The object with code 3 is a bicubic patch or a group of bicubic patches. It is followed by a translation vector, three scale factors for X, Y, and Z, and a filename or -. If there is a filename, then the patch's geometry is read from that file; otherwise, it is read from the following lines in the SFF file, ending with an empty line:
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.
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>
Example 4:
The code 4 object is a cone or cylinder. It has an apex center point and radius, followed by a base center point and radius. The apex radius must be less than (in the case of a cone) or equal to (for a cylinder) the base radius. The cone/cylinder are opened objects (i.e., 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>
Example 5:
The code 5 object is a polygon or a group of polygons, similar to patches. It is followed by a translation vector, three 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; otherwise, it is read from the following lines in the RTrace file, ending with an empty line.
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 two parts. In the first part are the number of polygons and the polygon's definitions, using indices into the vertex list. In the second part (after an empty line) is the vertex list, which is terminated by another empty line.
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>
Example 6:
The code 6 object is a triangle or a group of triangles, similar to a polygon but also specifying each vertex normal vector. (These triangles are also known as Phong triangles.) It is followed by a translation vector, three scale factors for X, Y, and Z, and a filename or -. If there is a filename, then the triangle's geometry is read from that file; otherwise, it is read from the following lines in the RTrace file, ending with an empty line.
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: first data and normal vertices, followed by the second data and normal vertices, and finally the third data and normal vertices. It is terminated by another empty line.
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>
Example 7:
The code 7 object is an extruded primitive derived from closed segments composed of 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; otherwise, it is read from the following lines in the RTrace file, ending with an empty line.
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/ António 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 their characters enclosed in a one-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 that contains translations from character names to character codes, which are used to access the character data.
The font keyword specifies a file that 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 by the orientation keyword.
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 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 one. 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 |
For further information about the RTrace format, see the specifications included on the CD-ROM.
The RTrace application is available for downloading at many Internet archive sites and on PC/MS-DOS BBSs. For further information, contact:
ISEP/INESC
Attn: António Costa
Computer Graphics & CAD Group
Largo Mompilher 22
4000 Porto
Portugal
Email: acosta@porto.inesc.pt
You can obtain the latest RTrace codes, scenes, images, and documents from the following Web site:
http://diana.inesc.pt/acc.html
or FTP site:
ftp://asterix.inesc.pt/pub/RTrace/
You can get the SCN specifications in PostScript at:
ftp://asterix.inesc.pt/pub/Rtrace/docs/
or in HTML at:
http://www.cica.indiana.edu/graphics/object_specs/scn/SCN.format.html
RTrace images are available at the following:
ftp://asterix.inesc.pt/pub/Rtrace/images/
ftp://asterix.inesc.pt/pub/Rtrace/images-med/
ftp://asterix.inesc.pt/pub/Rtrace/images-mol/
ftp://asterix.inesc.pt/pub/Rtrace/images-3D/
A Macintosh version (MacRTrace 1.8.4.2) developed by Greg Ferrar (ferrar@uxa.cso.uiuc.edu) is available at:
ftp://asterix.inesc.pt/pub/Rtrace/macintosh/
Also see the ray-tracing homepage at:
http://arachnid.cs.cf.ac.uk/Ray.Tracing/
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.
