Also Known As: WorkdToolkit Neutral File Format
|Maximum Image Size||Unlimited|
|Multiple Images Per File||No|
|Numerical Format||ASCII, big-endian|
|Supporting Applications||Sense8 applications, conversion programs|
|See Also||Discussion of VRML files in Chapter 1|
Used to describe scenes in Sense8 virtual reality hardware/software systems.
An early attempt at describing 3D scenes for virtual world construction. It is unfortunate that Sense8 has chosen to name their format NFF, given the prior existence and wide distribution of Eric Haines' NFF format in the 3D community.
Sense8 is a manufacturer of hardware/software systems that are designed to allow users to experience immersion in a 3D multisensual virtual world. The file format stores the scene description information associated with the visual component of this system.
There are two versions of the format, one in ASCII and one in binary. The binary version follows the conventions of the ASCII version with the exception that only 24-bit color is supported. Unfortunately, information on the binary codes associated with the ASCII tokens was not available at the time of this writing. Version 2.1 of the ASCII version is described here.
In the ASCII version, lines may be terminated with either linefeed or linefeed/carriage return pairs. Excess white space between tokens in the file is ignored. Comments start with "//" and are treated like comments in C++ --that is, characters to the right of the comment token are ignored, and a comment is terminated by a linefeed or by a linefeed/carriage return pair.
NFF files have a short header followed by one or more object descriptions. ASCII files are terminated according to operating system conventions on the host platform. A reader/parser application is expected to check whether objects are complete prior to rendering.
header object #1 object #2
The header consists of the file ID "nff", followed by the version number and two optional lines defining the viewpoint. The syntax is illustrated in the following example:
nff version 2.10 viewpos 0.000 0.000 0.000 viewdir 1.000 1.000 1.000
Following the header is a list of objects. Objects in NFF files are sets of polygons, and each polygon is defined by a list of vertices. An object definition starts out with a name, followed by the number of vertices, and a list of the actual vertices. Vertices are the x, y, and z coordinates of a point expressed as ASCII real numbers, separated by one or more white spaces. Following the vertex information is a list of polygons constructed from the vertex information.
Vertices are indexed according to the order in which they are defined in the file; the first vertex is number 0.
Object Name number of vertices vertex #0 vertex #1
vertex #n polygon #1 polygon #2
Vertex information lines may contain an optional normal definition, a color definition, and texture-mapped information. The normal definition is a vector similar in form to the actual vertex specification. Color definitions are expressed as hexadecimal numbers between 000000 and ffffff in the form 0xrrggbb. The presence of texture-mapped information is signified by the token "uv" and is followed by a pair of map coordinates expressed as real numbers. A fully specified vertex line has the following form:
x y z norm nx ny nz 0xrrggbb uv U V
The following is an example of a vertex at 0,0,0 with normal 0,0,1, colored red, and with u and v values of .5:
0.000 0.000 0.000 norm 0.000 0.000 1.000 0xff0000 uv 0.5 0.5
In many 3D programs, objects can be either colored or texture-mapped but not both. Color information can be useful, however, when a texture is not available to the rendering application or when texture-mapping is turned off for performance reasons. Colors and uv information (related to texture-mapping) may be included on the same vertex definition line, but the color information will be ignored if a texture file is present and textures are being applied to the object.
Polygon definitions start with an integer indicating the number of vertices making up the polygon. Following that is a list of vertex indices. After the vertex indices is a polygon color, specified in a manner similar to vertex colors. These are normally 24-bit colors. They can, however, be stored in 0xrgb form as 12-bit colors.
Following the color definition is an optional token "both", indicating that both sides of the polygon are visible. If the both token is not present, only the front of the polygon is visible. Polygon orientation is conveyed by noting the order in which the vertices are defined. Vertices are arranged in counter-clockwise order from the point of view of an observer facing the front of a polygon.
Optional texture names and attributes may be specified on the polygon definition line. Texture information tokens are constructed by concatenating texture attribute strings and the texture filename. The following texture attributes are recognized:
|_v_||``vanilla'' texture (no shading)|
|_u_||shaded and transparent|
Thus, a token signifying a shaded texture created from bitmap texture file grass would have the form _s_grass. Transparency works on black pixels in the texture bitmap. All black pixels are treated as transparent if transparency is turned on.
Textures applied to polygons may also be modified through the use of the tokens rot (rotate), scale, trans (translate), and mirror. Tokens rot, scale, and trans are followed by real numbers. Rot is expressed in radians, mirror is a toggle, and all are values in u-v texture coordinate space. Texture modifications are applied in the following order: mirror, rot, scale, and trans.
Polygons may be labeled with a token of the form "id=n", where n is a unique polygon number. A "portal name" may also be assigned to a polygon. This assignment is meant to allow the loading of an extension to the virtual world being rendered when the polygon, acting as a "portal," is crossed (presumably by the traveling point of view in an interactive situation).
The complete polygon syntax has the following form:
v1 v2...vn 0xrrggbb both _t_name rot 0.000 scale 0.000 trans 0.000 mirror id=m -nextworld
An example of this would be a six-sided polygon, with shaded grass texture mapped to the front, with the texture rotated, scaled, and translated. An id value of 2 has been assigned to it, and portal "nextworld" is to be loaded when the polygon is traversed by the point of view or camera during an interactive rendering session. Note that the red value is ignored due to the presence of a texture specification.
5 0 1 2 3 4 0xff0000 _s_grass rot 1.0 scale 0.5 trans 1.0 1.0 id=2 -nextworld
Note that vertex color specifications may override polygon color specifications, so for full compatibility with Sense8 products, you must examine color definitions for each polygon and compare them with those in the vertex definitions. If the vertex definitions are all one color, this color is assigned to the polygon, and the color information associated with the polygon is ignored.
In the same way, vertex texture values may override polygon texture designators if the vertex values making up the polygon all include u-v values.
The following is an example of a WTK ASCII NFF file.
nff version 2.1 viewpos 0.0 0.0 0.0 // optional viewpoint... viewdir 0.0 0.0 1.0 // ...and viewing direction FirstObject // object name 8 // total vertices 3.0 3.0 -3.0 // vertex list 3.0 -3.0 -3.0 -3.0 -3.0 -3.0 -3.0 3.0 -3.0 3.0 3.0 3.0 3.0 -3.0 3.0 -3.0 -3.0 3.0 -3.0 3.0 3.0 6 // total polygons. 4 0 1 2 3 0xff0000 // red 4 7 6 5 4 0x00ff00 // green 4 0 4 5 1 0x0000ff // blue 4 1 5 6 2 0xffff00 _s_grass // shaded texture "grass" 4 2 6 7 3 0xffffff _t_sky rot 1.0 // transparent, rotated texture "sky" 4 3 7 4 0 0x000000 _v_world -nextworld // vanilla texture "world", and // polygon is a "portal" to nextworld
For additional information about the Sense8 NFF file format, contact:
100 Shoreline Highway
Mill Valley, CA 94941
You might also want to take a look at the SIG-WTK FTP site, an archive of related 3D objects and image textures, as well as user-contributed software: