RTrace

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.

File Organization

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.

File Details

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:

Viewing Section

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>

Ambient and Background Section

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>

Lights Section

The Lights section contains a series of lines:

There are three types of light definitions:

Point light

To define a point light, specify the point code (1), a position, and RGB brightness.

Direction light

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).

Extended light

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>

Surfaces Section

The Surfaces section defines all of the surfaces. It consists of a series of lines:

There are two types of surface definitions:

Code 1 definition.

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.

Code 2 definition.

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>

Objects, Textures, and Transformations Section

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

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.htm

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.htm

RTrace images are available at the following:

ftp://asterix.inesc.pt/pub/Rtrace/images/en/
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.

Hosted by uCoz