Also Known As: Haines NFF, Neutral File Format
| Type | Scene description |
| Colors | NA |
| Compression | Uncompressed |
| Maximum Image Size | NA |
| Multiple Images Per File | NA |
| Numerical Format | NA |
| Originator | Eric Haines |
| Platform | All |
| Supporting Applications | Standard Procedural Database (SPD), MTV, others |
| See Also | MTV, Pixar RIB, POV, PRT, QRT, Radiance, Rayshade, RTrace |
Usage
Modeling of rendering algorithms, ray-trace applications.
Comments
A simple scene description language incorporating most of the
basics, which would be informative for anyone thinking about designing
yet another
ray-trace scene-description format.
Vendor specifications are available for this format.
NFF (Neutral File Format) is the creation of Eric Haines. Mr. Haines, the publisher of Ray Tracing News, has been active in the high-end graphics community for a number of years, He is well-known through these efforts, particularly on the Internet. As a consequence of Mr. Haines' visibility, although NFF was originally designed to test rendering algorithms, the format has played a role in the evolution of other, more sophisticated, scene description languages and formats.
Contents:
File Organization
File Details
For Further Information
Eric Haines describes NFF as follows:
The NFF (Neutral File Format) is designed as a minimal scene description language. The language was designed in order to test various rendering algorithms and efficiency schemes. It is meant to describe the geometry and basic surface characteristics of objects, the placement of lights, and the viewing frustum for the eye. Some additional information is provided for aesthetic reasons (such as the color of the objects, which is not strictly necessary for testing the efficiency of rendering algorithms).
Note that NFF has minimal support for lighting and shading.
NFF files consist of lines of ASCII text. Each line describes an object called an entity. The first field of each line describes the entity's type, and subsequent fields on the same line, and possibly subsequent lines, contain further information on the entity.
The information in this section is extracted from the NFF documentation kindly provided by Eric Haines.
By providing a minimal interface, NFF is meant to act as a simple format to allow the programmer to quickly write filters to move from NFF to the local file format. Presently, the following entities are supported:
Entities are coded as follows:
| ``v'' | Viewpoint location (viewing vectors and angles) |
| ``b'' | Background color |
| ``l'' | Positional light location |
| ``f'' | Object material properties |
| ``c'' | Cone or cylinder primitive |
| ``s'' | Sphere primitive |
| ``p'' | Polygon primitive |
| ``pp'' | Polygonal patch primitive |
These are explained in the following sections.
The viewpoint location entity is coded as follows:
| ``v'' |
| ``from> Fx Fy Fz |
| ``at" Ax Ay Az |
| ``up" Ux Uy Uz |
| ``angle" angle |
| ``hither" hither |
| ``resolution" xres yres |
Format:
v from %g %g %g at %g %g %g up %g %g %g angle %g hither %g resolution %d %d
Eye location in XYZ
Position to be at the center of the image, in XYZ world coordinates (a.k.a. "lookat")
Vector defining which direction is up, as an XYZ vector
In degrees, defined as the angle from the center of top pixel row to bottom pixel row and left column to right column
Distance of the hither plane (if any) from the eye. Mostly needed for hidden surface algorithms.
In pixels, in x and in y
Note that no assumptions are made about normalizing the data (e.g., the from-at distance does not have to be 1). Also, vectors are not required to be perpendicular to each other.
For all databases, some viewing parameters are always the same:
| yon is "at infinity." |
| aspect ratio is 1.0. |
A view entity must be defined before any objects are defined. (This requirement is so that NFF files can be displayed on-the-fly by hidden-surface machines.)
A color is simply RGB, with values between 0 and 1:
"b" R G B
Format:
b %g %g %g
If no background color is set, assume that RGB = [0,0,0].
A light is defined by XYZ position:
"l" X Y Z [R G B]
Format:
l %g %g %g [%g %g %g]
All light entities must be defined before any objects are defined. (This requirement is so that NFF files can be used by hidden surface machines). Lights have a non-zero intensity of no particular value, if not specified (i.e., the program can determine a useful intensity as desired); the red/green/blue color of the light can optionally be specified.
Object material properties (fill color and shading parameters) are coded as follows:
"f" red green blue Kd Ks Shine T index_of_refraction
Format:
f %g %g %g %g %g %g %g %g
RGB is in terms of 0.0 to 1.0.
| Kd | Diffuse component |
| Ks | Specular |
| Shine | Phong cosine power for highlights |
| T | Transmittance (fraction of contribution of the transmitting ray). |
Usually, 0 <= Kd <= 1 and 0 <= Ks <= 1, though it is not required that Kd + Ks = 1. Note that transmitting objects (T > 0) are considered to have two sides for algorithms that need these (normally, objects have one side).
The fill color is used to color the objects following it until a new color is assigned.
All objects are considered one-sided, unless the second side is needed for transmittance calculations (e.g., you cannot throw out the second intersection of a transparent sphere in ray tracing).
A cylinder is defined as having a radius and an axis defined by two points, which also define the top and bottom edge of the cylinder.
A cone is defined in similar fashion; the difference is that the apex and base radii are different. The apex radius is defined as being smaller than the base radius. Note that the surface exists without endcaps. The cone or cylinder description is shown below:
"c"
base.x base.y base.z base_radius
apex.x apex.y apex.z apex_radius
Format:
c %g %g %g %g %g %g %g %g
A negative value for both radii means that only the inside of the object is visible (objects are normally considered one-sided, with the outside visible). Note that the base and apex cannot be coincident for a cylinder or cone. Making them coincident could be used to define endcaps, but none of the SPD scenes currently make use of this definition.
A sphere is defined by a radius and center position, as shown below:
"s" center.x center.y center.z radius
Format:
s %g %g %g %g
If the radius is negative, then only the sphere's inside is visible (objects are normally considered one-sided, with the outside visible). Currently none of the SPD scenes makes use of negative radii.
A polygon is defined by a set of vertices. With these databases, a polygon is defined to have all points coplanar. A polygon has only one side; the order of the vertices is counterclockwise as you face the polygon (right-handed coordinate system). The first two edges must form a non-zero convex angle, so that the normal and side visibility can be determined by using just the first three vertices.
A polygon is defined as shown below:
"p" total_vertices
vert1.x vert1.y vert1.z
[etc. for total_vertices vertices]
Format:
p %d [ %g %g %g ] <- for total_vertices vertices
A patch is defined by a set of vertices and their normals. With these databases, a patch is defined to have all points coplanar. A patch has only one side, with the order of the vertices being counterclockwise as you face the patch (right-handed coordinate system). The first two edges must form a non-zero convex angle, so that the normal and side visibility can be determined.
A polygonal patch is defined as shown below:
"pp" total_vertices
vert1.x vert1.y vert1.z norm1.x norm1.y norm1.z
[etc. for total_vertices vertices]
Format:
pp %d [ %g %g %g %g %g %g ] <- for total_vertices vertices
A comment is defined as shown below:
"#" [ string ]
Format:
# [ string ]
As soon as a # character is detected, the rest of the line is considered a comment.
For further information about the NFF format, see the specification included on the CD-ROM. You can also contact the NFF author:
Eric Haines
3D/EYE Inc.
1050 Craft Road
Ithaca, NY 14850
Email: erich@eye.com
NFF is also used in conjunction with the Standard Procedural Database (SPD) software, a package designed to create a variety of databases for testing rendering schemes. For more information about SPD, see the following paper:
"A Proposal for Standard Graphics Environments," IEEE Computer Graphics and Applications, vol. 7, no. 11, November 1987, pp. 3-5.
SPD is available by anonymous FTP from:
ftp://wuarchive.wustl.edu/graphics/graphics/objects/
ftp://princeton.edu/pub/Graphics/
Images of the databases are available from (among other places):
ftp://ftp.eye.com/pub/graphics/SPD/
ftp://gondwana.ecr.mu.oz.au/pub/images/haines/
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.
