From: vorl@sdf.lonestar.org (Omar Loggiodice)
Subject: TECH: OIFF an object interchange file format
Originator: hlab@milton.u.washington.edu
Organization: University of Washington
Date: Fri, 14 Aug 1992 12:01:10 GMT



+-------------------------------------------------------------------------+
|                     PROGRESS REPORT#2 FOR WE PROJECT                    |
|                             START-UP VERSION                            |
+-------------------------------------------------------------------------+
+-------------------------------------------------------------------------+
|Topic:     OIFF- an Object Interchange File format                       |
|           First revision                                                |
|                                                                         |
|                                                        Date: 14-Aug-92  |
+-------------------------------------------------------------------------+

   This is the progress report #2 for the World Editor project start-up
   version (this project is being developed in the COMART forum on CIS, its
   main objective is to provide tools to create, modify and interact with
   virtual worlds).

   Pretty good comments and suggestions were made by Jerry Isdale and Drake
   Christensen. This report covers their suggestions as applied to the
   initial proposal of OIFF (covered in WEPR01.TXT). BTW, I personally
   want to thank Jerry Isdale (the Daddy, our project leader) and Drake
   Christensen (a new VR enthusiast) for their good comments. Keep on the
   good work.

   Here the new revision of the object interchange file format is explained.
   Small revisions will for sure be made when we refine VORL, the world
   description language.

   References: PC magazine June 16 1992. Pag 387. (windows RIFF format)
               Multimedia Programmer's Reference (windows documentation)
               WEPR??.TXT Library 1,2, or 13 of the COMART forum on CIS.
               WE*.* files in libraries 1,2 and 13 of the COMART forum.


    Thanks for your collaboration.
       Omar Loggiodice

What has been coded
-------------------

   The first set of C++ classes which handle the OIFF file format are
ready. They can be found on Lib2 of the COMART forum on CIS. Some
modifications to the file format and the code are being made. The next
steps are the following:
   
1.- Coding of the VORL (world. desc. language) module (parser/interpreter)
   2.- Integration with RND386

Introduction
------------

 What is an object?
   It's a set of time-varying effects upon our senses.

 What is OIFF?

   It is a file format which describes objects.

 Why not PLG?

   PLG only supports the sense of vision, and it does not support
   time-changing properties. But it's a very useful format and we will use a
   version of PLG in the VISI chunk. We could indeed use PLG as far as the
   start-up version is concerned, but it won't be a wise decision given our
   long term goals.

 Advantes of OIFF:
   1.- It will provide binary or ASCII format depending on user needs.
       Only ASCII will be used in the start-up version.
   2.- Contains a header (which works as an index) for fast browsing of
       objects.
   3.- It's easily extendable
   4.- No hard-coded offsets (extendability)
   5.- It considers not only vision, but other senses.
   6.- Easy conversion of PLG to OIFF
   7.- It's platform independent.


OIFF proposal.
--------------

   OIFF is a tagged file format. A "tagged" file is mainly
   composed of chunks which are identified by a tag (generally a 4-byte
   ASCII string). A chunk is a tag followed by the data size (32 bit), the
   data pointer and finally, the data itself. For example, if there were a
   chunk whose purpose is to store names it will look like this:

                                             \
            Hex                       Ascii   \
                                               \
     Tag          size                          \
  /          \/          \                      / Binary version
   4E 41 4D 45 00 00 00 06         NAME....    /
   00 00 00 00  ----->pointer      ....       /
   6D 79 6E 61 6D 65  to data      myname    /
  \                /
       data
                                         \
   NAME                                   \
   6                                      /  ASCII version
   0                                     /
   myname

   Since we have five senses, OIFF should support, or at least be extendable
   to support all of them, hence there will be five types of chunks:

      - "SOUN": Sense of Hearing
      - "VISI": Sense of Vision
      - "HAPT": Haptic sense (tactile, etc)
      - "OLFA": Sense of Smell
      - "TAST": Sense of Taste

   Due to technological and deadline reasons we will only consider the VIS
   chunk. Future revisions will define the other chunks.


   Header
   ------

      Due to the fact that we support binary or ascii OIFF files, a 8-byte
      header is included to specify the type of the file.

      "OIFFASCI" if the file is in ASCII version
      "OIFFBINA" if the file is in Binary version

   STAT subchunk
   -------------

   The effects that objects have upon our senses can be 'continuous' or
   'discrete'. The difference is analogous to the one between analogical and
   digital signals. Properties such as velocity or acceleration can be
   considered 'continuous' while changing, for example, from a sphere to a
   cube can be considered 'discrete'.

   In this first version of OIFF only discrete properties will be
   considered, future revisions will include continuous properties.

   There is a special type of chunk called the "state" subchunk. It defines
   the discrete states of an object. It has the following format:

   "STAT" <data-size> <pointer2data> [<data_type> <label> <data>]

   "STAT" is a subchunk because it has to be inside any of the other chunk
   types (SOUN, VISI, etc). The type of the <data> is specified by
   <data_type> and for now it can only be "PLG_" (a four-byte string). For
   instance, if the "STAT" chunk is inside a SOUN chunk then the <data> will
   be sound data in a predefined format specified by <data_type>. <label> is
   a 32-bit number assigned to the specific state. There should not be to
   "STAT"'s with the same label.


   VISI Chunk
   ---------

   The VISI chunk has the following format:

   "VISI" <data-size> <pointer2data> [<subchunk>]

   -"VISI" is the tag for the visual chunk.
   -<data-size> is the size of <subchunk>
   -<pointer2data> is a pointer to the location in the file where the
    <subchunk> resides.
   -<subchunk>, for this version, can only be a "STAT" subchunk. It is
    enclosed between brackets because is doesn't have to be located after
    <pointer2data>.


   PLG format
   ----------

     The version of PLG that we use is the following, numbers can be
     represented in binary or ASCII format depending on the type of the OIFF
     file.

     header:
       <32b.#vertices>
       <32b.#polygons>

     vertices:

       <32b.x#1>
       <32b.y#1>     As many triplets as specified in the header
       <32b.z#1>
       ..
       ..
       <32b.x#n>
       <32b.y#n>
       <32b.z#n>


     polygons:

       <32b.color>
       <32b.#vertices>
       <32b.vertex#1>
       <32b.vertex#2>
       ..
       ..
       <32b.vertex#n>

    NAME chunk
    ----------

       The name chunk is a special chunk which will assign a name to the
       object.

    OIFF chunk
    ----------

       This is the 'root' chunk. All other chunks are subchunks of this.
       It's format is the following:

          "OIFF" <size> <pointer2data> [<subchunk>]


    Example
    -------

       Suppose we have an object which has two states. In one it's a square,
       in the other it's a triangle. The following will be it's OIFFASCI
       file:

       OIFFASCI
       OIFF
          xxxx
          0

          NAME
          8
          0

          myobject

          VISI
          xxxx
          0

             STAT
             xxxx
             0

             PLG_                       <------ Data type
             0001                       <------ State Label (numeric)
             4
             1                          <------ header (#vert,#polys)

             0
             0                          <------ (0,0,0)
             0

             1
             0                          <------ (1,0,0)
             0

             1
             1                          <------ (1,1,0)
             0

             0
             1                          <------ (0,1,0)
             0

             1                          <------ Color of Poly
             4                          <------ Number of vertices
             0                          <------ Vertex#1
             1                          <------       #2
             2                          <------       #3
             3                          <------       #4

             STAT
             xxxx
             0

             PLG_                       <------ Data type
             0002                       <------ State Label (numeric)
             3
             1                          <------ header (#vert,#polys)

             0
             0                          <------ (0,0,0)
             0

             1
             0                          <------ (1,0,0)
             0

             0
             1                          <------ (0,1,0)
             0

             255                        <------ Color of Poly
             3                          <------ Number of vertices
             0                          <------ Vertex#1
             1                          <------       #2
             2                          <------       #3



   Note that all the pointers in this example were null, this is due to the
   fact that the data is located right after the <pointer2data>, this is the
   recommended format for ASCII files (to facilitate editing).

   This might seem complicated, but it really isn't. Of course, the end-user
   will never have to see this, they will use either a modeller or a
   PLG2OIFF converter for example.

   Omar Loggiodice.
   Assistant Leader of the WE project.
   Compuserve: 74040,1543
   Internet:   74040.1543@compuserve.com