home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 505b.lha / DKBTrace_v2.11 / doc / 25to210.doc < prev    next >
Text File  |  1991-04-30  |  6KB  |  148 lines

  1. Data file conversion from DKB 2.0 through 2.05 to DKB 2.11 guidelines:
  2.  
  3. (If you are converting an earlier version data file than DKB 2.0, then see
  4.  the file 12to20.doc for guidelines for bringing the file up to 2.0 status).
  5.  
  6. There are a couple of differences in the input language format from 2.05 to
  7. DKB 2.11 so there are several MANDATORY conversions required.  For what it's
  8. worth, the conversions are all backward compatible to prior versions of DKB,
  9. for the most part.
  10.  
  11. 1.  BasicShapes.Data - or BASICSHA.DAT or whatever the heck it was being
  12.     called on whatever system it was being run on is now replaced by three
  13.     separate files.  The filenames short enough to be useable across all
  14.     systems so the names of the files will remain consistent for everyone.
  15.     To preserve maximum portability, try to keep these filenames in lower
  16.     case.
  17.  
  18.     The Old Way:
  19.  
  20.     INCLUDE "BasicShapes.Data"  - or -
  21.     INCLUDE "BasicSha.Dat"     - or -
  22.     INCLUDE "BASICSHA.DAT"     - you get the idea... -
  23.  
  24.     The NEW Way:
  25.  
  26.     INCLUDE "shapes.dat"
  27.     INCLUDE "colors.dat"
  28.     INCLUDE "textures.dat"
  29.  
  30.  
  31. 2.  All object info except transformations (ROTATE, SCALE and TRANSLATE) and
  32.     basic object COLOUR (when lower quality -q is used and TEXTURE's are being
  33.     ignored) are now REQUIRED to be inside a TEXTURE-END_TEXTURE block.  This
  34.     concept is clearer, anyway.  Now, the "usual" format for an object looks
  35.     like this (replace comment lines with your own stuff, naturally...):
  36.  
  37.     OBJECT
  38.         { The shape itself - QUADRIC, SPHERE, etc END_QUADRIC, _SPHERE, etc }
  39.  
  40.     { Transformations for Object Only - ROTATE, SCALE, TRANSLATE }
  41.  
  42.     { TEXTURE    }
  43.     {   Transformations for Texture Only - ROTATE, SCALE, TRANSLATE }
  44.     {   Object Lighting Characteristics - AMBIENT, DIFFUSE, etc. }
  45.     { END_TEXTURE    }
  46.  
  47.     { TEXTURE    }
  48.     {   Further Optional Layered Textures - "outside" previous one }
  49.     { END_TEXTURE    }
  50.  
  51.     { Transformations Shared by Object and Texture, ROTATE, SCALE, etc. }
  52.  
  53.     { Optional Basic Object Colour - if TEXTURE's are ignored at low -q. }
  54.     END_OBJECT
  55.  
  56.  
  57. 3.  LIGHT_SOURCE's "usual" format is slightly different, also.  Replace the
  58.     'light_diameter' and 'where you want it' with your own values:
  59.  
  60.     OBJECT
  61.       SPHERE <0.0 0.0 0.0> light_diameter END_SPHERE
  62.       TRANSLATE <where you want it>
  63.  
  64.       LIGHT_SOURCE
  65.       COLOUR White    { This is the colour of the light emitted from lamp. }
  66.  
  67.       TEXTURE
  68.         COLOUR White    { This is the colour of the sphere object itself. }
  69.     AMBIENT 1.0    { It only used if sphere is visible in the scene. }
  70.     DIFFUSE 0.0
  71.       END_TEXTURE
  72.  
  73.     END_OBJECT
  74.  
  75.  
  76. 4.  All of the textures defined in textures.dat (formerly BasicShapes.Data)
  77.     have had the scaling removed from them.  It is up to the user including
  78.     the texture to specify the scale desired.  For some reason most of the
  79.     textures in common use were scaled by <10 10 10>, so that means to convert
  80.     an existing data file multiply any given scale factors by 10 or so.  If
  81.     in doubt, check the old BasicShapes.Data file to see if the texture used
  82.     to use a SCALE statement of it's own.  Mostly, Marble, Cloud_Sky and Wood
  83.     textures will need this rescaling.
  84.  
  85.  
  86. 5.  The definitions of the WOOD's in textures.dat (formerly BasicShapes.Data)
  87.     have had the texture randomness removed from them.  The same reason as #4
  88.     above applies.  Additionally texture randomness looks bad in animations
  89.     because of it's truly random nature.  It's allowable for static pictures,
  90.     though.  Anyway now it's up to you to specify it if you want to.
  91.  
  92.  
  93. 6.  Prior to DKB 2.10, Alpha and Refraction were totally independent.  Now
  94.     they interact heavily.  For a complete description of this change, see
  95.     the DKB210.DOC file (there's a nice graph in there illustrating it).
  96.     In short, to get REFRACTION of the light rays, you're going to need some
  97.     ALPHA so they can get through the surface texture to be refracted.  Of
  98.     the part that ALPHA lets pass through, REFRACTION determines how much
  99.     of that light gets bent passing through the object.
  100.  
  101. 7.  Rotation was totally backwards in versions prior to 2.11.  This means
  102.     that all ROTATE values given will need to be made negative to work as
  103.     they did before.  This does not apply to ROTATE values of 0 or 180, as
  104.     a negative value is meaningless for either of these values.  If the old
  105.     data file said:
  106.  
  107.         ROTATE <0.0 -90.0 45.0>
  108.  
  109.     then it will now say:
  110.  
  111.         ROTATE <0.0 90.0 -45.0>
  112.  
  113.  
  114. That ends the necessary conversions.  There are several other points that
  115. you will want to have uppermost in your mind when considering the data file
  116. conversions:
  117.  
  118. 1.  The files generated by various automatic utilities, such as SCULPT2DKB
  119.     or DXF2DKB, etc. have a COLOUR statement that will modify the texture
  120.     property from the usual "Dull", "Shiny" or whatever texture (because
  121.     "COLOUR" now must be inside a TEXTURE block).  This will cause the texture
  122.     to be separately copied for each object that is using the predefined
  123.     "Dull", etc. textures then modifying them by adding an object colour.
  124.     Unfortunately, this makes a copy of the modified texture for each object
  125.     with a different color satement, and uses up more memory.  If you possibly
  126.     can, try to anticipate the colours to be used and DEFINE them as textures
  127.     to be commonly used by all objects of that same colour and texture.  Not
  128.     doing this may cause an inability to render the same complexity of objects
  129.     as the program used to, because of the increased memory requirements of
  130.     copying all those modified textures.
  131.  
  132.  
  133. 2.  DKB 2.10 now supports automatic transformation of a texture along with an
  134.     object.  If the transformations given are after the TEXTURE - END_TEXTURE
  135.     block, then this will occur.  To suppress this, put the transformations
  136.     first, before the TEXTURE block. Then the texture will not be transformed,
  137.     a'la 2.05's way of doing things.
  138.  
  139.  
  140. 3.  DKB 2.10 now supports layered textures.  They are layered first on bottom
  141.     to last on top.  One or more TEXTURE-END_TEXTURE blocks following a
  142.     TEXTURE block invokes this feature.  Surface characteristics such as
  143.     REFLECTION, PHONG, etc. only have effect on the outermost (last) defined
  144.     TEXTURE-END_TEXTURE block.  In order to see the texture(s) below, the
  145.     outer texture(s) must have some component of ALPHA to them.  See MANDATORY
  146.     conversion item #2 above for the example format of an object using layered
  147.     textures.
  148.