home *** CD-ROM | disk | FTP | other *** search
/ Stars of Shareware: Raytrace & Morphing / SOS-RAYTRACE.ISO / programm / utility / dos / cchem03 / nff.doc < prev    next >
Encoding:
Text File  |  1992-09-21  |  8.6 KB  |  256 lines
  1.                       Neutral File Format (NFF)
  2.                       =========================
  3.  
  4.     by Eric Haines, 3D/Eye Inc, 410 E Upland Rd, Ithaca, NY 14850
  5.                             (607)-257-1381
  6.              Email: hpfcla!hpfcrs!eye!erich@hplabs.hp.com
  7.  
  8. [This  is  a  description  of the format used in the SPD package.  Any
  9. comments  on  how  to  expand  this  format  are  appreciated.    Some
  10. extensions  seem  obvious  to  me  (e.g.   adding  directional lights,
  11. circles, and tori), but I want to take my time, gather  opinions,  and
  12. get  it more-or-less right the first go round.  Also, I'm ridiculously
  13. busy right now.  -EAH]
  14.  
  15. [Extended by John Walker (kelvin@Autodesk.com)  to  add  the  "aspect"
  16. statement to allow rendering non-square images and to support displays
  17. with non-square pixels.]
  18.  
  19. Draft document #1, 10/3/88
  20.  
  21. The  NFF  (Neutral  File  Format)  is  designed  as  a  minimal  scene
  22. description language.  The language was  designed  in  order  to  test
  23. various  rendering  algorithms and efficiency schemes.  It is meant to
  24. describe the geometry and basic surface  characteristics  of  objects,
  25. the  placement  of  lights, and the viewing frustum for the eye.  Some
  26. additional information is provided for aesthetic reasons (such as  the
  27. color  of  the  objects,  which  is not strictly necessary for testing
  28. rendering algorithms).
  29.  
  30. Future enhancements include: circle and torus objects, spline surfaces
  31. with  trimming  curves,  directional   lights,   characteristics   for
  32. positional lights, CSG descriptions, and probably more by the time you
  33. read this.  Comments, suggestions, and criticisms are all welcome.
  34.  
  35. At  present  the  NFF  file format is used in conjunction with the SPD
  36. (Standard Procedural Database) software, a package designed to  create
  37. a variety of databases for testing rendering schemes.  The SPD package
  38. is available from Netlib and via ftp from drizzle.cs.uoregon.edu.  For
  39. more  information  about  SPD  see  "A  Proposal for Standard Graphics
  40. Environments," IEEE Computer Graphics and Applications, vol.   7,  no.
  41. 11, November 1987, pp.  3-5.
  42.  
  43. By  providing  a  minimal  interface,  NFF is meant to act as a simple
  44. format to allow the programmer to quickly write filters to  move  from
  45. NFF  to  the  local file format.  Presently the following entities are
  46. supported:
  47.  
  48.      A simple perspective frustum
  49.      A positional (vs. directional) light source description
  50.      A background color description
  51.      A surface properties description
  52.      Polygon, polygonal patch, cylinder/cone, and sphere descriptions
  53.  
  54. Files are output as lines of text.  For each entity,  the  first  line
  55. defines its type.  The rest of the first line and possibly other lines
  56. contain further information about the entity.  Entities include:
  57.  
  58.     "v"  - viewing vectors and angles
  59.     "l"  - positional light location
  60.     "b"  - background color
  61.     "f"  - object material properties
  62.     "c"  - cone or cylinder primitive
  63.     "s"  - sphere primitive
  64.     "p"  - polygon primitive
  65.     "pp" - polygonal patch primitive
  66.  
  67. These are explained in depth below:
  68.  
  69. Viewpoint location.  Description:
  70.     "v"
  71.     "from" Fx Fy Fz
  72.     "at" Ax Ay Az
  73.     "up" Ux Uy Uz
  74.     "angle" angle
  75.     "hither" hither
  76.     "resolution" xres yres
  77.     "aspect" ratio
  78.  
  79. Format:
  80.     v
  81.     from %g %g %g
  82.     at %g %g %g
  83.     up %g %g %g
  84.     angle %g
  85.     hither %g
  86.     resolution %d %d
  87.     aspect %g
  88.  
  89. The parameters are:
  90.  
  91.     From:  the eye location in XYZ.
  92.     At:    a position to be at the center of the image, in XYZ world
  93.            coordinates.  A.k.a. "lookat".
  94.     Up:    a vector defining which direction is up, as an XYZ vector.
  95.     Angle: in degrees, defined as from the center of top pixel row to
  96.            bottom pixel row and left column to right column.
  97.     Resolution: in pixels, in x and in y.
  98.     Aspect: screen aspect ratio divided by pixel aspect ratio.  Equal
  99.            to resolution_y/resolution_x for square pixels.
  100.  
  101.   Note that no assumptions are made about normalizing the  data  (e.g.
  102.   the  from-at distance does not have to be 1).  Also, vectors are not
  103.   required to be perpendicular to each other.
  104.  
  105.   For all databases some viewing parameters are always the same:
  106.  
  107.     Yon is "at infinity."
  108.     Aspect ratio is 1.0.
  109.  
  110.   A view entity must be defined before any objects are  defined  (this
  111.   requirement  is  so  that  NFF  files  can be used by hidden surface
  112.   machines).
  113.  
  114. LIGHTS
  115. ======
  116.  
  117. Positional light.  A light is defined by XYZ position.  Description:
  118.  
  119.     "l" X Y Z
  120.  
  121. Format:
  122.     l %g %g %g
  123.  
  124.     All light entities must be defined before any objects are  defined
  125.     (this  requirement  is  so  that  NFF  files can be used by hidden
  126.     surface  machines).   Lights  have  a  non-zero  intensity  of  no
  127.     particular  value  [this  definition  may  change  soon,  with the
  128.     addition of an intensity and/or color].
  129.  
  130. BACKGROUND
  131. ==========
  132.  
  133. Background color.  A color is simply RGB with values between 0 and 1:
  134.  
  135.     "b" R G B
  136.  
  137. Format:
  138.     b %g %g %g
  139.  
  140.     If no background color is set, assume RGB = {0,0,0}.
  141.  
  142. MATERIAL PROPERTIES
  143. ===================
  144.  
  145. Fill color and shading parameters.  Description:
  146.  
  147.      "f" red green blue Kd Ks Shine T index_of_refraction
  148.  
  149. Format:
  150.     f %g %g %g %g %g %g %g %g
  151.  
  152.     RGB is in terms of 0.0 to 1.0.
  153.  
  154.     Kd  is  the diffuse component, Ks the specular, Shine is the Phong
  155.     cosine power for highlights, T is transmittance (fraction of light
  156.     passed  per unit).  Usually, 0 <= Kd <= 1 and 0 <= Ks <= 1, though
  157.     it is not required that Kd + Ks  ==  1.   Note  that  transmitting
  158.     objects  (T  >  0) are considered to have two sides for algorithms
  159.     that need these (normally objects have one side).
  160.   
  161.     The fill color is used to color the objects following it  until  a
  162.     new color is assigned.
  163.  
  164. OBJECTS
  165. =======
  166.  
  167. Objects:  all objects are considered one-sided, unless the second side
  168. is needed for transmittance calculations (e.g.  you cannot  throw  out
  169. the second intersection of a transparent sphere in ray tracing).
  170.  
  171. Cylinder  or  cone
  172. ------------------ 
  173.     A cylinder is defined as having a radius and an  axis  defined  by
  174.     two  points,  which  also  define  the  top and bottom edge of the
  175.     cylinder.  A cone is defined similarly, the difference being  that
  176.     the apex and base radii are different.  The apex radius is defined
  177.     as being smaller than the base  radius.   Note  that  the  surface
  178.     exists without endcaps.  The cone or cylinder description:
  179.  
  180.     "c"
  181.     base.x base.y base.z base_radius
  182.     apex.x apex.y apex.z apex_radius
  183.  
  184. Format:
  185.     c
  186.     %g %g %g %g
  187.     %g %g %g %g
  188.  
  189.     A  negative value for both radii means that only the inside of the
  190.     object is visible (objects are normally considered one sided, with
  191.     the  outside  visible).   Note  that  the  base and apex cannot be
  192.     coincident for a cylinder or cone.
  193.  
  194. Sphere
  195. ------
  196.  
  197. A sphere is defined by a radius and center position:
  198.  
  199.     "s" center.x center.y center.z radius
  200.  
  201. Format:
  202.     s %g %g %g %g
  203.  
  204.     If  the  radius  is  negative,  then  only  the sphere's inside is
  205.     visible (objects are  normally  considered  one  sided,  with  the
  206.     outside visible).
  207.  
  208. Polygon
  209. -------
  210.  
  211.     A  polygon is defined by a set of vertices.  With these databases,
  212.     a polygon is defined to have all points coplanar.  A  polygon  has
  213.     only  one side, with the order of the vertices counterclockwise as
  214.     you face the polygon (right-handed coordinate system).  The  first
  215.     two  edges  must  form a non-zero convex angle, so that the normal
  216.     and side visibility can be determined.  Description:
  217.  
  218.     "p" total_vertices
  219.     vert1.x vert1.y vert1.z
  220.     [etc. for total_vertices vertices]
  221.  
  222. Format:
  223.     p %d
  224.     [ %g %g %g ] <-- for total_vertices vertices
  225.  
  226. Polygon Patch
  227. -------------
  228.  
  229.     A patch is defined by a set of vertices and their  normals.   With
  230.     these  databases,  a patch is defined to have all points coplanar.
  231.     A patch has only one side, with the order of  the  vertices  being
  232.     counterclockwise  as  you  face the patch (right-handed coordinate
  233.     system).  The first two edges must form a non-zero  convex  angle,
  234.     so  that  the  normal  and  side  visibility  can  be  determined.
  235.     Description:
  236.  
  237.     "pp" total_vertices
  238.     vert1.x vert1.y vert1.z norm1.x norm1.y norm1.z
  239.     [etc. for total_vertices vertices]
  240.  
  241. Format:
  242.     pp %d
  243.     [ %g %g %g %g %g %g ] <-- for total_vertices vertices
  244.  
  245. COMMENT
  246. =======
  247.  
  248. Description:
  249.     "#" [ string ]
  250.  
  251. Format:
  252.     # [ string ]
  253.  
  254.     As soon as a "#" character is detected, the rest of the line is considered
  255.     a comment.
  256.