home *** CD-ROM | disk | FTP | other *** search
/ World of Graphics / WOGRAPH.BIN / 485.VIVID.DOC < prev    next >
Text File  |  1992-03-14  |  113KB  |  3,232 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.                           Vivid 2.0      March 14, 1992
  7.  
  8.                       Copyright 1989-1992 by Stephen B. Coy
  9.  
  10.  
  11.                                 Table of Contents
  12.  
  13.  
  14.             Introduction . . . . . . . . . . . . . . . . . .   2
  15.             Changes for Version 2.0. . . . . . . . . . . . .   3
  16.             Running Vivid. . . . . . . . . . . . . . . . . .   5
  17.             Statistics Display . . . . . . . . . . . . . . .   7
  18.             Legal Stuff. . . . . . . . . . . . . . . . . . .   9
  19.             Acknowledgements . . . . . . . . . . . . . . . .  11
  20.             Input File Format. . . . . . . . . . . . . . . .  13
  21.             Preprocessor . . . . . . . . . . . . . . . .  15
  22.             Studio . . . . . . . . . . . . . . . . . . .  17
  23.             Lights . . . . . . . . . . . . . . . . . . .  24
  24.             Surfaces . . . . . . . . . . . . . . . . . .  28
  25.                 bump mapping . . . . . . . . . . . . . .  31
  26.                 solid texture. . . . . . . . . . . . . .  33
  27.                 Mandelbrot . . . . . . . . . . . . . . .  36
  28.             Geometric Primatives . . . . . . . . . . . .  37
  29.                 sphere . . . . . . . . . . . . . . . . .  37
  30.                 ring . . . . . . . . . . . . . . . . . .  38
  31.                 polygon. . . . . . . . . . . . . . . . .  39
  32.                 triangular patch . . . . . . . . . . . .  40
  33.                 cone . . . . . . . . . . . . . . . . . .  41
  34.             Transformations. . . . . . . . . . . . . . .  42
  35.             Clipping . . . . . . . . . . . . . . . . . .  44
  36.             Support Programs . . . . . . . . . . . . . . . .  46
  37.             img2gif.exe. . . . . . . . . . . . . . . . .  46
  38.             paste.exe. . . . . . . . . . . . . . . . . .  50
  39.             up.exe . . . . . . . . . . . . . . . . . . .  51
  40.             down.exe . . . . . . . . . . . . . . . . . .  52
  41.             File Formats . . . . . . . . . . . . . . . . . .  53
  42.             Bibliography . . . . . . . . . . . . . . . . . .  54
  43.             Index. . . . . . . . . . . . . . . . . . . . . .  55
  44.         
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                         1
  59.  
  60.  
  61.  
  62.  
  63.                             Introduction to Vivid 2.0
  64.  
  65.              Surprise!  Yes, 2.0 is finally here.  I'd like to appologize
  66.         to those of you who have been waiting for many months for this to
  67.         come out.  I've been busy doing my Master's thesis and, of
  68.         course, adding "just this one more feature." A few bugs were
  69.         squashed in the process although I'm sure that new ones have been
  70.         breeding in the walls just waiting until this release.  Even with
  71.         the bugs I still consider Vivid to be one of the finest ray
  72.         tracers (I've) ever written. 
  73.  
  74.              In the archive you received should be this document, the
  75.         Vivid executable, some sample input files, and tools for
  76.         processing the image after it has been generated.  Vivid.exe has
  77.         been compiled to run on any MS-DOS based system with a 286 or
  78.         better and a math coprocessor.  Ray tracing can be extremely slow
  79.         and anything less is really not worth it.  If, however, you don't
  80.         believe me feel free to write and I'll send you a copy compiled
  81.         for an bare 8086.  I hope you don't plan on using your PC in the
  82.         next month.  Back to the 286/287 version.  This version also
  83.         contains a DOS extender allowing Vivid to take advantage of any
  84.         extended memory you may have.  For those of you that still want
  85.         something better I also have 386 versions available.  See the
  86.         Legal Stuff section for more info. 
  87.  
  88.              The rest of this document explains the details of how to run
  89.         Vivid and the tools and how to construct an input file.  I
  90.         recommend that you print out this file and a couple of the sample
  91.         input files when first learning Vivid.  An example is worth a
  92.         thousand words, or at least the paper it's printed on. 
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.                                         2
  117.  
  118.  
  119.  
  120.  
  121.                       (Most of the) Changes for Version 2.0
  122.  
  123.  
  124.              I learned to spell Mark VandeWettering's name correctly. 
  125.         Sorry about version 1.0 Mark. 
  126.  
  127.              Inside/outside problems have been resolved eliminating the
  128.         need to have spheres with negative radii or worry about clockwise
  129.         vs counter-clockwise polygons. 
  130.  
  131.              Polygon patches are a lot healthier. 
  132.  
  133.              I plugged my brain back in.  The description of fuzzy
  134.         spheres given in the 1.0 docs is wrong.  But it's better now. 
  135.  
  136.              When using the depth of field option a new "samples"
  137.         parameter has been added to allow you to control the number of
  138.         rays per pixel used. 
  139.  
  140.              Spherical light sources also allow the "samples" parameter
  141.         to determine the number of shadow rays shot toward them. 
  142.  
  143.              There is no longer a limit on the number of lights except
  144.         for memory and your patience.  The limit was 20 but this info
  145.         never made it into the docs for version 1.0.  The limit on number
  146.         of objects has also been removed although due to the operating
  147.         system an effective limit of about 2000 objects still remains. 
  148.         The DOS extender version is limited only by memory. 
  149.  
  150.              The number of objects contained within a bounding box may
  151.         now be specified.  The default, 4, is equal to the prior, fixed
  152.         value.  This can be specified by adding
  153.             bunching 6
  154.         to the studio structure.  Changing this value will affect the
  155.         performance of the automatic bounding box construction.  Results
  156.         are image dependent but I think that 4 is a good default value. 
  157.  
  158.              A bug in the camera model caused the image to become
  159.         distorted when the up vector given in the studio structure wasn't
  160.         perpendicular to the direction of view.  It has been fixed. 
  161.  
  162.              The traditional flat projection model has been joined by not
  163.         one, not just two, but by three other projection models,
  164.         spherical, othographic and parallax.  See the section on the
  165.         studio structure for details. 
  166.  
  167.              The input file format has been changed to eliminate the need
  168.         for semicolons and equals signs.  In order to be compatable with
  169.         the old file format, they are still accepted but are now treated
  170.         just as a space would be treated. 
  171.  
  172.              A quick-render mode has been added to help speed up
  173.  
  174.                                         3
  175.  
  176.  
  177.  
  178.         previews. 
  179.  
  180.              Simple math operations are now supported by the parser. 
  181.         These operations are supported on numbers and on vectors (rgb
  182.         triples and xyz coordinates).  The following is a list of the
  183.         operations supported.  Vectors operations supported include cross
  184.         product, addition, subtraction, scaling, and dot product. 
  185.         Numerical operations include multiplication, division, addition,
  186.         subtraction and exponentiation.  Sine, cosine, tangent, arcsine,
  187.         arccosine, arctangent and square root functions are also
  188.         supported. 
  189.  
  190.              Cylinders can now be specified by giving a cone a single
  191.         radius parameter. 
  192.  
  193.              Preprocessor is here.  include files, defines, undefs and
  194.         lack of fixed colors which are now replaced with color.vc. 
  195.  
  196.              Global transformations are now supported.  Together with
  197.         include files this should make scene modeling much easier. 
  198.  
  199.              Primitives can now be clipped by planes, spheres or cone
  200.         allowing easier generation of more complex models. 
  201.  
  202.              The background can have a palette mapped to it rather than
  203.         just having a single color. 
  204.  
  205.              A new bunch of command line switches are now supported. 
  206.         Typing vivid on the command line without any arguements will give
  207.         you a listing of them. 
  208.  
  209.              The keyword "noise" is now "turbulence" to better follow the
  210.         literature. 
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.                                         4
  233.  
  234.  
  235.  
  236.  
  237.                                   Running Vivid
  238.  
  239.              Vivid input files use the extension .v and the output files
  240.         use .img.  With the preproccessor in Vivid, include files are
  241.         also supported.  These may have any extension.  The syntax for
  242.         including a file into your input file is:
  243.         
  244.             #include filename
  245.         
  246.  
  247.              Include files may have any extension you choose.  The
  248.         following is a list of the file extensions that I regularly use. 
  249.         If we all use the same convention it should make things easier
  250.         for trading input files.  Feel free come up with your own
  251.         conventions if that suits you better. 
  252.         
  253.             .v      Main input file for an image.  Required.
  254.             .img    24-bit output file.
  255.             .map    palette file for img2gif or background mapping.
  256.             .vc     include file with color definitions.  See color.vc.
  257.             .vo     include file with object definition.
  258.             .vs     include file with surface definitions.
  259.         
  260.  
  261.              The .img files produced by Vivid are full 24-bit color.  The
  262.         details of their format are explained later in this document. 
  263.         Since most systems can't display 24-bit graphics I've included a
  264.         tool to convert the .img files into .gif files which can be
  265.         displayed using vpic or cshow.  This tool is called img2gif.  Its
  266.         workings are also detailed later.  In general the procedure for
  267.         generating an image will look like this:
  268.         
  269.         1)  Create an input file, test.v, with your favorite text editor.
  270.         2)  Run Vivid.
  271.             C>vivid test
  272.         3)  Wait until done.  This can take from a few minutes to a
  273.             couple of days depending on the complexity of the image
  274.             and the speed of your machine.  This is a good time to
  275.             raid the fridge.
  276.         4)  Convert the result, test.img, into a .gif file.
  277.             C>img2gif -m -d test
  278.             The -m flag tells img2gif to use median cut to determine
  279.             the palette.  The -d flags turns on Floyd-Steinberg
  280.             dithering.
  281.         5)  View the image.
  282.             C>vpic test.gif
  283.         
  284.         
  285.  
  286.              Because of the way I implemented the preprocessor Vivid
  287.         creates a temporary file on the disk called xyzzy.v.  At this
  288.         time, Vivid does not delete the file after it is done using it. 
  289.  
  290.                                         5
  291.  
  292.  
  293.  
  294.         The reason I leave this is that it is sometimes useful to look at
  295.         when trying to figure out what the preprocessor is doing with
  296.         your input definition.  Feel free to delete it at any time. 
  297.  
  298.                                         
  299.  
  300.              Vivid supports a number of command line flags.  These flags
  301.         allow you to change the operation of the program without changing
  302.         the input file.  The following command line flags are now
  303.         supported:
  304.         
  305.             -s      Run in silent mode, ie no statistics display.
  306.             -r      Resume.
  307.             -i x y  Set image size to x by y pixels.
  308.             -n      No_shadows, same as studio flag.
  309.             -d #    Set maximum recursion depth value
  310.             -a mode Set antialias mode.  Valid modes are: none,
  311.                 quick, corners and adaptive.  Since I can't type
  312.                 I've made it so that you only have to give the
  313.                 first letter of the mode for it to work.
  314.             -p      Don't use the preprocessor.
  315.         
  316.  
  317.              Vivid has the ability to resume the generation of an
  318.         interrupted image.  If during image generation you need to stop,
  319.         hitting ctrl-C or ctrl-BREAK will cause Vivid to stop at the end
  320.         of the next scan line.  This may be up to a few minutes for a
  321.         slow image.  This only works if statistics are enabled (the
  322.         default).  Later, the image generation may be resumed by using
  323.         the -r flag on the command line. 
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.                                         6
  349.  
  350.  
  351.  
  352.  
  353.                                    Statistics
  354.  
  355.  
  356.              Surprisingly enough some people are curious about the
  357.         statistics that Vivid displays while processing.  Somehow they
  358.         actually got the idea that the numbers may contain useful
  359.         information if only they were documented somewhere.  The secret
  360.         is out.  They don't mean a thing.  I just put them in there
  361.         because I like watching them change while I'm waiting for the
  362.         image to generate.  Sorry to break your bubble.  OK, fine, I'm
  363.         joking, happy now?
  364.  
  365.              When you run Vivid it displays the current version number
  366.         and the copyright notice.  It then displays the filename of the
  367.         input files as the preprocessor digests them.  Next a running
  368.         total of lights and primitives is displayed as the parser reads
  369.         the preprocessed input file.  Once the file is completely read in
  370.         the automagic bounding box code is called.  As it generates
  371.         bounding boxes you see the number of primitives climb.  Upon
  372.         completion of the bounding box generation the scene extent is
  373.         displayed.  This is the minimum and maximum values in each axis
  374.         for all the primitives.  At this time the first scan line is
  375.         starting to be rendered.  When it is done the screen will clear
  376.         and a full display of current statistics will be displayed.  The
  377.         meanings for each of the numbers will now be described in
  378.         glorious detail bereft of all attempts at obfuscation.  I hope
  379.         this makes sense. 
  380.  
  381.              The resolution is the size of the final image in pixels. 
  382.         The line display next to it shows the progress of the ray tracer. 
  383.         For example, if you where generating an image 320 pixels wide and
  384.         200 pixels tall the resolution would display 320x200
  385.         (unbelievable!) and the line value would go from 0 to 200.  In
  386.         quick mode this number will increment by 6 instead of 1. 
  387.  
  388.              The next four lines contain information about the number of
  389.         rays cast.  Eye rays are the rays cast from the viewpoint out
  390.         into the scene.  Reflected rays are those generated by a specular
  391.         surface and refracted rays are those generated by transparent
  392.         surfaces.  The total is just the sum of these rays.  If your
  393.         input file doesn't have any reflective or transparent surfaces
  394.         these numbers will stay 0. 
  395.  
  396.              The next section contains information about shadow rays. 
  397.         Shadow rays are the rays shot from the point of intersection
  398.         toward each light in order to determine if there are any other
  399.         primitives in the scene blocking the light (casting a shadow). 
  400.         Vivid uses a shadow cache to try and speed up this process. 
  401.         Cache hits signify an instance when the cached object was found
  402.         to cast a shadow and no ray was cast.  The cache percentage is
  403.         just the number of hits divided by the number of shadow rays. 
  404.  
  405.  
  406.                                         7
  407.  
  408.  
  409.  
  410.              The next number is the average number of rays cast per
  411.         pixel.  This number can give you a fair idea of just how hard the
  412.         ray tracer is working to generate the image.  With no
  413.         antialiasing, reflection, or refraction this number should be
  414.         1.0.  Adaptive antialiasing can push this as high as 16 depending
  415.         on the amount of extra work it does.  Reflected and refracted
  416.         rays will make this even higher.  Using the quick mode this
  417.         number may go to as low as .066 or so.  When this number is less
  418.         than 1 that means that the ray tracer is guessing at some of the
  419.         pixels instead of actually casting a ray for them. 
  420.  
  421.              The average queues per ray value has to do with the bounding
  422.         scheme.  The automatic bounding box generator creates a tree-like
  423.         heirarchy of bounding boxes for the system to test each ray
  424.         against.  If a box is intersected by a ray then the objects in
  425.         the bounding box (either other bounding boxes or primitives) are
  426.         entered into the priority queue for further intersection testing. 
  427.         The "bounds checked" number shows how many bounding box
  428.         intersection tests were performed.  The "queue inserts" number
  429.         shows how many object passed the bounds check and were put into
  430.         the priority queue.  The "queue resets" number displays the total
  431.         number of times the priority queue was reset.  This should be
  432.         equal to the total number of rays plus the number of shadow rays
  433.         plus the number of cache hits.  Don't ask why, it just will be. 
  434.         The "max queue size" number shows the maximum number of objects
  435.         in the queue during the rendering. 
  436.  
  437.              The final number, the max recursion depth, shows the maximum
  438.         number of levels deep the ray tracer had to go while rendering
  439.         the image.  The number after the slash is the max depth it is
  440.         allowed to go. 
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.                                         8
  465.  
  466.  
  467.  
  468.  
  469.                                    Legal Stuff
  470.  
  471.             Vivid is Copyright 1989-1992 by
  472.             Stephen B. Coy
  473.             All Rights Reserved.
  474.  
  475.              You are free to redistribute this package in its entirety. 
  476.         In doing so you may charge no more than a nominal fee for
  477.         duplication.  No part of this package may be included as part of
  478.         a commercial package without explicit written permission.  If you
  479.         have any questions about commercial distribution of Vivid or its
  480.         tools I can be contacted at:
  481.         
  482.             Stephen Coy
  483.             Vivid Software
  484.             15205 NE 13th Pl.  #2904
  485.             Bellevue, WA  98007
  486.             (206) 641-8615
  487.         
  488.             INTERNET:    coy@ssc-vax.boeing.com or
  489.                      uw-beaver!ssc-vax!coy
  490.             CompuServe:  70413,136
  491.         
  492.  
  493.              Originally I thought of distributing Vivid via shareware but
  494.         I seriously dislike the guilt games most shareware authors
  495.         include.  So, I've decided to try beggarware.  Here's the
  496.         product.  Use it.  If you like it I'd be very happy if you'd sent
  497.         a check for $30.  If you think $30 is out of line, send less (or
  498.         more) or beer.  If you don't think Vivid is worth diddly at least
  499.         send a postcard explaining why you don't like it.  If you want
  500.         the 386 versions you'll have to register at the $50 level.  Sorry
  501.         about that but times are tough and compilers aren't cheap. 
  502.         Anyway that's about the price of an average game lately so I
  503.         don't think it's too far out of line.  As is usual I will also
  504.         accept severe sob stories, beer, software (nothing pirated, thank
  505.         you), barter goods, and young women instead of money.  The 386
  506.         diskette contains versions of Vivid compiled with both the
  507.         Zortech and the Intel compilers giving you a choice of DOS
  508.         extenders to work with.  The Intel version is DPMI compliant and
  509.         has the advantage of supporting virtual memory allowing you to
  510.         allocate up to 128Mb of disk space as memory for those seriously
  511.         huge models.  The Zortech version is DPMI, VCPI and XMS
  512.         compatible and takes up less space.  It also seems to be able to
  513.         find about 500K more memory than the Intel version but doesn't
  514.         directly offer virtual memory support.  If another DPMI host
  515.         which supports virtual memory is active, Windows 3.0 running in
  516.         386 enhanced mode for instance, then the Zortech version can take
  517.         advantage of it. 
  518.  
  519.              Whether you send anything or not I would like to hear about
  520.         any suggestions or bugs.  Of course requests accompanied by money
  521.  
  522.                                         9
  523.  
  524.  
  525.  
  526.         will tend to get higher priority.  I will answer all mail and
  527.         email even though I may be a bit slow at times.  Email tends to
  528.         get the fastest response.  If you have tried to contact me and
  529.         not gotten a response please try again.  If you still don't get a
  530.         response you might have to resort to US Mail. 
  531.  
  532.              For those of you into BBSing I can be contacted via any of
  533.         the ADEnet nodes.  ADEnet is a network of BBSs primarily
  534.         dedicated to providing professional quality support for AutoCAD
  535.         and other CAD programs.  In addition there is also an animation
  536.         and rendering conference where questions about Vivid, or graphics
  537.         in general, will be answered.  I usually log in on a daily basis
  538.         so turn around is quite quick.  Another BBS I log into a lot is
  539.         TurboTech.  Ray Johnson, TurboTech's sysop and the author of
  540.         TurboCit, has provided a room for ray trace discussions and has
  541.         plenty of disk space for images.  Check out the conversations,
  542.         too.  The BBS attracts some interesting people.  I also frequent
  543.         CompuServe's COMART forum for those of you with deeper pockets. 
  544.  
  545.              Ray Johnson's Turbo Tech BBS can be reached at
  546.         (206)362-6828. 
  547.  
  548.                  Alacrity Design & Engineering Network (ADEnet)
  549.  
  550.  
  551.              ADEnet serves the design and engineering communities by
  552.         making information useful to them widely available.  This is done
  553.         in three ways: the ADEnet message conferences, the sharing of
  554.         programs and data files across ADEnet and the dissemination of
  555.         industry news and press releases. 
  556.  
  557.                               ADEnet Member Listing
  558.  
  559.  
  560.              The following is a listing of the current ADEnet Member
  561.         BBSs.  Each ADEnet Member is an independant BBS operated by a
  562.         local sysop. 
  563.         Alacrity Software BBS    206-643-5477 Bellevue, WA       DUAL (14.4)
  564.         The Graphics Alternative 510-524-2780 El Cerruto, CA     DUAL (14.4)
  565.         Off Broadway             510-547-5264 San Francisco, CA  V32
  566.         PC-AUG BBS               602-952-0638 Phoenix, AZ        DUAL (9600)
  567.         Mind Image BBS           612-781-1720 Minneapolis, MN    v22, MNP5
  568.         LABB                     717-394-1357 Lancaster, PA      v22, MNP5 [%]
  569.         AEC-ONLINE               818-360-7022 Los Angeles, CA    v22
  570.         The University BBS       908-544-8193 Shrewsbury Twp, NJ DUAL (14.4)
  571.         AZCAD BBS              +61-3-481-6873 Australia          v32bis
  572.         
  573.  
  574.              Each of the listings has the BBS name and it's (primary)
  575.         phone number followed by the location.  At the end of listing is
  576.         the highest allowable bits per second (bps) and protocol. 
  577.         DUAL - US Robotics Dual Standard supporting HST and v.32/v.42bis
  578.         HST  - US Robotics Courier HST
  579.  
  580.                                         10
  581.  
  582.  
  583.  
  584.         v32  - Industry standard v.32/v.42bis supporting upto 9600 bps
  585.         v32b - Industry standard v.32bis/v.42bis supporting upto 14.4k bps
  586.         v22  - Industry standard v.22 supporting upto 2400 bps
  587.         MNP5 - Indicates support Microcom Network Protocol Class 5
  588.         v42b - Indicates support for CCITT v.42bis
  589.         
  590.         [*] CAD/Engineering Services BBS accepts calls between 22:00-05:00 CST.
  591.         [%] LABB is a multiline system, of which only the main line is listed.
  592.         
  593.  
  594.              The following is a listing of the current ADEnet message
  595.         conferences. 
  596.                Conference  Description
  597.                --------------------------------------------------------
  598.                Autodesk    Autodesk product support
  599.                A/E/C       Architectual, Engineering and Construction
  600.                CAD/CAM     Manufacturing, NC Programming
  601.                Civil       Civil engineering
  602.                CompuGFX    Computer graphics, rendering and animation
  603.                DTP         Desktop publishing
  604.                ForSale     Buy & Sell used equipment, job listings
  605.                Generic     Generic Software product support
  606.                GIS         Geographical information services
  607.                uStation    Integraph Microstation support
  608.                News        Industry news and press releases
  609.                Public      Network wide (ADEnet) general conference
  610.                TechTalk    Technical hardware and software discussions
  611.         
  612.  
  613.  
  614.                                  Joining ADEnet
  615.  
  616.  
  617.              If you are the system operator of a BBS and interested in
  618.         joining ADEnet, please download ADENET.ZIP.  Within is a more
  619.         detailed introduction to ADEnet, an application form, and all of
  620.         the necessary information and data files you'll need. 
  621.  
  622.              ADEnet currently supports PC-Relay, QWK/REP, and FidoNet's
  623.         echomail message networking protocols.  Alacrity Software BBS
  624.         serves as the ADEnet hub for nodes using either PC-Relay or
  625.         QWK/REP.  The University BBS acts as ADEnet's "bridge" to nodes
  626.         using echomail. 
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.                                         11
  639.  
  640.  
  641.  
  642.  
  643.                                 Acknowledgements
  644.  
  645.              First on the list I must thank Mark VandeWettering for his
  646.         raytracer MTV.  Some pieces of Vivid have been lifted directly
  647.         from MTV's code.  Hopefully, I only took the bug-free ones.  I'd
  648.         like to thank Mike Thompson for his various contributions both
  649.         technical and fermented.  Thanks to Gregor Harrison for a lot of
  650.         help understanding lex & yacc.  I still am somewhat confused but
  651.         I like it that way.  Thanks to Jason Osgood of ADEnet for
  652.         providing a forum for my rantings about Vivid.  Thanks to Drew
  653.         Wells for encouraging me to join CompuServe.  And thanks to all
  654.         those folks who unwittingly helped Vivid through their postings
  655.         to usenet.  Finally, I'd like to thank all of you who took time
  656.         to send comments (and images and beer and money) for version 1. 
  657.         Coming home to a nice letter and a check in the mail rather than
  658.         just bills makes the whole week go better.  Thank you. 
  659.         
  660.         GIF is a trademark of CompuServe
  661.         MS-DOS is a trademark of Microsoft
  662.         
  663.         
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.                                         12
  697.  
  698.  
  699.  
  700.  
  701.                                 Input File Format
  702.  
  703.              One thing to keep in mind while creating Vivid input files
  704.         is that Vivid's parser is case sensitive.  Macros (see
  705.         preprocessor section) are also case sensitive. 
  706.  
  707.              Vivid uses a right-handed coordinate system for defining the
  708.         location of objects in space.  A right-handed coordinate system
  709.         can be visualized as having the x axis pointing to the right, the
  710.         y axis pointing into the screen and the z axis pointing up.  Each
  711.         object in a scene file will be defined as having a location in
  712.         space defined by an x, y, z triple in this coordinate system. 
  713.  
  714.              Colors are defined by an r, g, b triple where each component
  715.         generally falls in the range 0..1.  To make picking colors easier
  716.         Vivid includes the file color.vc which contains a few dozen
  717.         predefined colors.  Their names and rgb values can be had by
  718.         viewing or printing color.vc.  If this file is #included at the
  719.         top of you input file these names can be used anywhere an rgb
  720.         triple is called for. 
  721.  
  722.              Simple math operations are now supported by the parser. 
  723.         These operations are supported on numbers and on vectors (rgb
  724.         triples and xyz coordinates).  The following is a list of the
  725.         operations supported.  Vectors operations supported include cross
  726.         product, addition, subtraction, scaling, and dot product. 
  727.         Numerical operations include multiplication, division, addition,
  728.         subtraction and exponentiation.  Sine, cosine, tangent, arcsine,
  729.         arccosine, arctangent and square root functions are also
  730.         supported. 
  731.         
  732.             Vector ops
  733.             ----------
  734.             a b c cross x y z       cross product, yields a vector
  735.             a b c dot x y z         dot product, yields a number
  736.             a b c + x y z           vector addition, yields a vector
  737.             a b c - x y z           vector subtraction, yields a vector
  738.             a b c * n               scale a vector by n
  739.             a b c / n               scale a vector by 1/n
  740.             -(a b c)                negate a vector
  741.         
  742.             Numeric ops
  743.             -----------
  744.             sin(x), cos(x), tan(x)  trig functions
  745.             asin(x), acos(x), atan(x)
  746.             sqrt(x)                 returns square root of x
  747.             pow(x y)                returns x to the yth power
  748.             *, /, +, -              normal mathematical operations
  749.         
  750.  
  751.              It should be noted that these operations introduce some
  752.         ambiguity to the input language.  This problem is aggravated by
  753.  
  754.                                         13
  755.  
  756.  
  757.  
  758.         the fact that the parser can only look one token ahead when it
  759.         tries to decide how to treat its current input.  I encourage you
  760.         to avoid any such problems by generously using parantheses to
  761.         eliminate any possible ambiguity in your equations.  For example:
  762.         
  763.             n * a b c can result in either
  764.             (n*a) b c or
  765.             (n*a) (n*b) (n*c)
  766.             depending on how the parser is feeling that day.
  767.         
  768.         
  769.  
  770.              If you really want to I'm sure that you could figure out
  771.         what the parser is doing but that may change in the future so
  772.         save yourself the trouble and just add the parentheses. 
  773.  
  774.              Comments can also be included in the input file.  Like
  775.         comments in computer programs, comments in Vivid input files are
  776.         ignored by the input parser.  Comments in Vivid use the same
  777.         syntax as comments in C++ do.  Multi-line comments start with /*
  778.         and end with */.  Anything between the comment delimeters is
  779.         ignored.  Single line comments start with // and end at the end
  780.         of the line.  For example:
  781.         
  782.         /*      This is a comment
  783.             which spans multiple lines  */
  784.         
  785.         //      This is a single line comment
  786.         
  787.         
  788.  
  789.              Comments should be used as notes in your input files to help
  790.         remind you or anyone else reading the file what the input is
  791.         trying to do.  Comments can also be used to block out part of the
  792.         input file while you are setting it up to help speed up test
  793.         renderings. 
  794.  
  795.              Normally an input file will be made up of a studio
  796.         definition which describes the image size, antialiasing and
  797.         viewpoint followed by the definitions for lights, surfaces, and
  798.         objects.  Object definitions only deal with the geometry of the
  799.         object.  The surface characteristics (color, shine) of the object
  800.         are taken from the last surface definition preceding the object. 
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.                                         14
  813.  
  814.  
  815.  
  816.  
  817.                                   Preprocessor
  818.  
  819.  
  820.              To make writing input files easier, Vivid's parser also has
  821.         a preprocessor.  Currently, the preprocessor only supports two
  822.         functions, the definition of macros and support for include
  823.         files.  Because of the way I implemented the preprocessor Vivid
  824.         creates a temporary file on the disk called xyzzy.v.  (Didn't I
  825.         already mention this? deja vu) At this time, Vivid does not
  826.         delete the file after it is done using it.  The reason I leave
  827.         this is that it is sometimes useful to look at when trying to
  828.         figure out what the preprocessor is doing with your input
  829.         definition.  Feel free to delete it at any time. 
  830.  
  831.              Macros allow you to associate a name with a string of
  832.         characters.  When the parser sees the name in the input file it
  833.         will substitute the appropriate string before continuing.  A
  834.         simple example of this is the color definitions in the file
  835.         color.vc.  In color.vc the colors white and blue are defined like
  836.         this:
  837.         
  838.         #define blue    (0 0 1)
  839.         #define white   (1 1 1)
  840.         
  841.  
  842.              Once defined you can then use the word "white" wherever you
  843.         would normally have to type (1 1 1).  For example, to create a
  844.         blue surface with a white highlight you could then do this:
  845.         
  846.         surface {
  847.             diffuse blue
  848.             shine 20 white
  849.         }
  850.         
  851.  
  852.              Macro names must start with a letter and may contain
  853.         letters, numbers, and the underscore character "_".  Macro names
  854.         are case sensitive.  Note than in the examples I define the
  855.         colors with parentheses around the rgb values.  This is not
  856.         required but helps eliminate any potential parser problems as
  857.         mentioned in the section on the parser's math ability.  You can
  858.         undefine a macro using the #undef keyword. 
  859.         
  860.         #undef blue
  861.         
  862.  
  863.              If you define the same macro more than once the old values
  864.         are put onto a stack and the newest one will always be used.  If
  865.         you then undefine the macro, only the newest one will be deleted
  866.         and the next newest definition will then be active.  If you want
  867.         to define a macro that is longer than one line you have to use
  868.         the backslash, "\", as a continuation character. 
  869.  
  870.                                         15
  871.  
  872.  
  873.  
  874.         
  875.         #define BLUE_PLASTIC                    \
  876.             surface {                       \
  877.                 diffuse blue            \
  878.                 shine 20 white          \
  879.             }
  880.         
  881.  
  882.              Notice that the last line does not have a backslash after
  883.         it.  Once defined you can then just use the name BLUE_PLASTIC in
  884.         the input file wherever you would normally type in the whole
  885.         surface declaration. 
  886.  
  887.              The other preprocessor directive is #include.  This allows
  888.         you to include other files into your input file.  Look at the
  889.         sample input files and notice that almost the first thing in the
  890.         file is a line like:
  891.         
  892.         #include color.vc
  893.         
  894.  
  895.              This causes the parser to read in the file color.vc which
  896.         defines a standard set of colors for use in creating input files. 
  897.         Using Dan Farmer's color editor it is quite easy to create new
  898.         colors to add to this file.  The include command is also useful
  899.         for including objects into your scene.  Combined with the
  900.         transformation commands this will allow you to create objects as
  901.         seperate files and inlcude them into the scene at any location
  902.         and orientation.  You may also inlcude multiple copies of an
  903.         object. 
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.                                         16
  929.  
  930.  
  931.  
  932.  
  933.                                    The Studio
  934.  
  935.              The studio structure in the scene file defines all those
  936.         things that are neither lights, objects or clips.  This includes
  937.         the resolution of the final image, the location of the camera
  938.         (viewpoint), the direction the camera is pointing, the background
  939.         color, and various rendering options.  Some of the options have
  940.         default values.  These are the values these options will take on
  941.         if they are left out of the studio definition.  The studio
  942.         definition looks like this:
  943.         
  944.         studio {
  945.             from x y z
  946.             at x y z
  947.             up x y z
  948.             angle ang
  949.             resolution i j
  950.             start line
  951.             stop line
  952.             aspect asp
  953.             projection mode
  954.         
  955.             ambient acolor
  956.             background bcolor
  957.             haze density
  958.         
  959.             antialias mode
  960.             threshold dist
  961.             jitter
  962.         
  963.             aperture size
  964.             focal_length dist
  965.             samples n
  966.         
  967.             no_shadows
  968.             no_exp_trans
  969.             caustics
  970.         
  971.             depth max_depth
  972.             bunching n
  973.         }
  974.         
  975.         "from" is the location of the camera. 
  976.  
  977.         "at" is where in the scene the camera is pointed. 
  978.  
  979.         "up" is a vector pointing up, usually 0 0 1.  This can be
  980.                 played with to roll the image around the axis of
  981.                 the camera. 
  982.  
  983.         "angle" is the field-of-view angle given in degrees. 
  984.  
  985.  
  986.                                     17
  987.  
  988.  
  989.  
  990.         "resolution" is the size of the image in pixels, i pixels
  991.                 across and j pixels down.  This can also be
  992.                 controlled from the command line using the -i
  993.                 switch. 
  994.  
  995.         "start" and "stop" allow you to start and stop the
  996.                 rendering at the specified line numbers.  I use
  997.                 this for testing new input files and isolating
  998.                 bugs.  Those of you with networks might want to
  999.                 consider using this to split up an image for
  1000.                 rendering on multiple computers.  After the
  1001.                 sections are done you can then use paste.exe to
  1002.                 glue them together.  Currently there is a problem
  1003.                 with using start and the resume (-r) flag.  Avoid
  1004.                 the combination. 
  1005.  
  1006.         "aspect" is the aspect ratio of the screen.  This is the
  1007.                 ratio of width to height of the screen you are
  1008.                 rendering your images for.  I've found that my
  1009.                 Nec 3D has an aspect ratio of about 4/3 and that
  1010.                 my Amiga 1084 has an aspect ratio of about 1.2. 
  1011.                 To determine the proper aspect ratio for your
  1012.                 screen measure the width and height of a screen
  1013.                 image.  The aspect ratio of your screen can be
  1014.                 found by dividing the width by the height. 
  1015.                 Determining the correct aspect ratio of your
  1016.                 screen will insure that circles come out looking
  1017.                 like circles instead of ovals.  Remember, aspect
  1018.                 ratio should the the width/height ratio of the
  1019.                 displayed image regardless of the image
  1020.                 resolution.  Together with the resolution these
  1021.                 are used to determine the aspect ratio of the
  1022.                 pixels. 
  1023.  
  1024.         "projection" controls how the 3d world is mapped onto the
  1025.                 2d screen.  The default is "flat".  This is the
  1026.                 standard perspective projection you've all come
  1027.                 to know and love.  "spherical" projection
  1028.                 produces an effect somewhat like a fisheye lens. 
  1029.                 Things can look pretty strange.  Unique to the
  1030.                 "spherical" mode is the field of view angle can
  1031.                 be greater than 180 degrees.  Try a 360 degree
  1032.                 panorama some time.  The "orthographic"
  1033.                 projection mode produces an image where all the
  1034.                 eye rays are parallel to each other.  For this
  1035.                 mode the "angle" parameter has no meaning and is
  1036.                 replaced with a "width" parameter.  Width defines
  1037.                 how wide the screen is in the world coordinate
  1038.                 system.  Generally, I think that this mode is
  1039.                 useless but it was easy to code so why not? The
  1040.                 final mode is the "parallax" projection mode. 
  1041.                 This produces a 2-point projection instead of a
  1042.                 3-point projection like the "flat" mode.  In the
  1043.  
  1044.                                     18
  1045.  
  1046.  
  1047.  
  1048.                 "parallax" mode, all vertical lines stay vertical
  1049.                 on the screen.  This was implemented specifically
  1050.                 for architectural renderings but is sometimes
  1051.                 useful in other contexts.  Note that "vertical"
  1052.                 is defined by the direction of the up vector. 
  1053.  
  1054.         "ambient" is the color of the light that is everywhere in
  1055.                 the image.  In "the real world" when light
  1056.                 strikes diffuse surfaces such as walls, some of
  1057.                 it is scattered back into the room.  This is why
  1058.                 you can still see under a desk even though no
  1059.                 light is shining directly underneath it.  Most
  1060.                 ray tracers, including Vivid, can't handle this
  1061.                 diffuse interreflection.  But, all hope is not
  1062.                 lost.  To fake diffuse interreflection Vivid
  1063.                 allows you to set an ambient light value.  This
  1064.                 acts like a light that is shining in every
  1065.                 direction at once and does not cast any shadows. 
  1066.                 For an inside scene values of about .2 .2 .2 seem
  1067.                 to work well.  Outside scenes look a bit more
  1068.                 realistic with a higher ambient value because of
  1069.                 the scattering of light the atmosphere does. 
  1070.                 Most ray traced images that you will see just
  1071.                 have the ambient value set to 0 0 0 or black. 
  1072.                 This produces the sharpest contrasts and gives
  1073.                 the image a super-real effect.  The default value
  1074.                 for ambient is 0 0 0. 
  1075.  
  1076.         "background" is the color that will be returned if no
  1077.                 objects are hit while tracing a ray.  Popular
  1078.                 choices are black and sky_blue.  If haze is
  1079.                 defined then this is the color of the haze.  (see
  1080.                 below) The background color defaults to black. 
  1081.                 Alternatively you can do the following:
  1082.                 
  1083.                     background {
  1084.                         palette.map
  1085.                         up x y z
  1086.                     }
  1087.                 
  1088.                  This produces a graduated background using the
  1089.                 colors in the file palette.map.  The file can
  1090.                 have any name but is required to have the .map
  1091.                 extension.  The file is the same format as the
  1092.                 img2gif palette files.  The first color in the
  1093.                 file is the color that will appear in the
  1094.                 direction of the up vector.  If no up vector is
  1095.                 specified then the up vector from the studio
  1096.                 structure will be used. 
  1097.  
  1098.         "haze" is the density of the fog or haze in the scene. 
  1099.                 The haze density defaults to 0.  This means that
  1100.                 there is no haze.  A value of .5 means that for
  1101.  
  1102.                                     19
  1103.  
  1104.  
  1105.  
  1106.                 every unit a ray travels, half of its color is
  1107.                 determined by the background color.  This
  1108.                 function is exponential, ie if the haze density
  1109.                 is given as .5 the color of a ray going 1 unit
  1110.                 will be .5 times the color of the object it hits
  1111.                 and .5 times the background color.  A ray going 2
  1112.                 units will be .25 the color of the object and .75
  1113.                 times the background color.  For most images this
  1114.                 parameter can be ignored and the default value of
  1115.                 0 used. 
  1116.  
  1117.         "antialias" determines whether or not antialiasing is
  1118.                 performed and what type is used.  This can also
  1119.                 be controlled from the command line using the -a
  1120.                 switch.  The valid modes are:
  1121.  
  1122.             none -- Do one ray per pixel, right through the
  1123.                 center.  Results are blocky but relatively quick. 
  1124.                 This is the default. 
  1125.             quick -- This does a subsampling approximation of the
  1126.                 image.  In areas of even color the most speedup
  1127.                 is gained.  This is the fastest mode but the
  1128.                 results are not useful for much more than test
  1129.                 images.  At best (ie on a blank image) this
  1130.                 should be about 15 times faster than the above
  1131.                 mode.  In general I notice about a 3-5 times
  1132.                 speedup.  This is a great mode for doing test
  1133.                 renderings. 
  1134.             corners -- Shoot a ray at each corner of the pixel
  1135.                 and average the results.  Since the corners are
  1136.                 shared by adjoining pixels this means about one
  1137.                 ray per pixel.  The results are almost as quick
  1138.                 as none but usually have a better look. 
  1139.                 Effectively this is the same as running a
  1140.                 smoothing filter over the image. 
  1141.             adaptive -- Rays are shot at the corners of the
  1142.                 pixel.  If they are within a certain threshold of
  1143.                 each other the program moves on to the next
  1144.                 pixel.  If they differ by more than the threshold
  1145.                 value, the pixel is subdivided into four
  1146.                 subpixels and sampled again.  The corners of the
  1147.                 subpixels are then compared against the threshold
  1148.                 and if they are still too far apart the are
  1149.                 subdivided once more.  The effective result of
  1150.                 this is that in areas of constant or smoothly
  1151.                 changing intensity only one ray per pixel is
  1152.                 shot.  At edges or other sharp color transitions
  1153.                 up to 25 rays per pixel may be averaged to
  1154.                 determine the color of the pixel.  The result is
  1155.                 fairly good antialiasing without too much undo
  1156.                 overhead. 
  1157.  
  1158.         "threshold" is the threshold value used by the adaptive
  1159.  
  1160.                                     20
  1161.  
  1162.  
  1163.  
  1164.                 mode of antialiasing.  The default threshold is
  1165.                 16.  Valid values are 0..255.  This parameter
  1166.                 also affects the quick mode.  In general, lower
  1167.                 values will produce better results but take more
  1168.                 time. 
  1169.  
  1170.         "jitter" is a flag telling the system to add a little bit
  1171.                 of randomness to the direction each ray is shot. 
  1172.                 Combined with antialiasing this helps to break up
  1173.                 the patterns sometimes caused by sampling an
  1174.                 image on a regular grid.  Images with regular
  1175.                 patterns such as checkerboards disappearing into
  1176.                 the horizon will benefit most from jitter. 
  1177.  
  1178.         "aperture" is an optional parameter which allows the ray
  1179.                 tracer to model a more realistic camera.  The
  1180.                 default aperture is 0 which models a pinhole
  1181.                 camera.  With an aperture greater than 0 objects
  1182.                 at the focal length (see below) will appear in
  1183.                 sharp focus while objects nearer or further from
  1184.                 the viewpoint will be blurred.  The larger the
  1185.                 aperture, the more exaggerated the blurring will
  1186.                 be.  Using this option will greatly increase the
  1187.                 amount of time needed to generate an image
  1188.                 because Vivid uses distributed ray tracing to
  1189.                 model the effects of a camera with a non-zero
  1190.                 aperture.  This causes the number of rays
  1191.                 necessary to calculate the color of a pixel to
  1192.                 increase greatly.  The default is to shoot 8 rays
  1193.                 instead of one ray whenever aperture is greater
  1194.                 than zero.  This value can be controlled with the
  1195.                 "samples" parameter below. 
  1196.  
  1197.         "focal_length" determines the distance from the camera to
  1198.                 the focal plane where objects are rendered in
  1199.                 focus.  This option is used in conjunction with
  1200.                 the aperture option.  Objects which are a
  1201.                 distance equal to the focal length away from the
  1202.                 camera will be in sharp focus.  The default for
  1203.                 the focal length is the distance between the
  1204.                 "from" and "at" points which determine the
  1205.                 viewpoint and the viewing direction. 
  1206.  
  1207.         "samples" controls the number of rays shot when a
  1208.                 non-zero aperture is used.  The default is 8. 
  1209.  
  1210.         "no_shadows" causes all shadow calculations to be turned
  1211.                 off.  The speed increase gained by turning
  1212.                 shadows off is especially useful when doing test
  1213.                 images of a new scene.  The can also be
  1214.                 controlled using the command line switch -n. 
  1215.  
  1216.         "no_exp_trans" is a wonderfully intuitive name for a flag
  1217.  
  1218.                                     21
  1219.  
  1220.  
  1221.  
  1222.                 that turns off the exponential attenuation of the
  1223.                 rays as they pass through transparent objects. 
  1224.                 Got that? Let me try again.  Normally when Vivid
  1225.                 shoots a ray through a transparent object (glass)
  1226.                 the color of the ray is tinted by the color of
  1227.                 the glass and is a function of the distance that
  1228.                 the ray has to travel through the glass.  For
  1229.                 example if you have two sheets of coke-bottle
  1230.                 green glass where one is 1/4 inch thick and the
  1231.                 other is 2 inches thick, light passing through
  1232.                 the thicker one will be darker.  The relationship
  1233.                 between the thickness and the amount of tinting
  1234.                 is exponential.  This causes problems with single
  1235.                 sided glass because when Vivid tries to compute
  1236.                 the thickness of the glass the distance
  1237.                 calculated is from the glass to whatever wall or
  1238.                 floor the ray hits next.  Hence the windows will
  1239.                 tend to be way dark.  When you set the
  1240.                 no_exp_trans flag in the studio structure Vivid
  1241.                 only uses the transparent color of the surface to
  1242.                 calculate the tint and totally ignores the
  1243.                 distance that the ray travels.  This tinting also
  1244.                 affects shadow rays. 
  1245.  
  1246.         "caustics" is an experimental flag which turns on Vivid's
  1247.                 faked caustics.  Caustics are those neat patterns
  1248.                 of light that are produced as light passes
  1249.                 through a transparent object.  I've been playing
  1250.                 around with a couple of ways to get some of the
  1251.                 effect without having to spend a few days per
  1252.                 image doing the real thing.  The effect is pretty
  1253.                 subtle but does seem to make some images look
  1254.                 better.  Joe Bob says check it out. 
  1255.  
  1256.         "depth" lets you limit the maximum recursion level to
  1257.                 which rays will be traced.  At a depth of 1 only
  1258.                 eye rays are traced.  A depth of 2 will trace 1st
  1259.                 level reflections and refractions.  The maximum
  1260.                 value allowed is 20.  This is also the default
  1261.                 value.  This can also be changed using the
  1262.                 command line switch -d. 
  1263.  
  1264.         "bunching" allows you to control the branching factor of
  1265.                 the tree created by the bounding boxes.  I'm not
  1266.                 really sure what an optimal value is but the
  1267.                 default value of 4 seems to work well for most
  1268.                 cases.  At any rate, values less than two are
  1269.                 guaranteed to cause grief.  Higher values will
  1270.                 cause the bounding box tree to branch more at
  1271.                 each level and therefore be shallower.  Lower
  1272.                 values will do the opposite.  I find that
  1273.                 experimenting with takes more time than I ever
  1274.                 save so the only time I use it is when I am close
  1275.  
  1276.                                     22
  1277.  
  1278.  
  1279.  
  1280.                 to running out of memory.  Using a higher value
  1281.                 like 8 or 12 will create fewer composite
  1282.                 (bounding box) nodes in the tree and save soom
  1283.                 memory.  Feel free not to ignore it without fear
  1284.                 of missing out on something. 
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.                                         23
  1335.  
  1336.  
  1337.  
  1338.  
  1339.                                      Lights
  1340.  
  1341.  
  1342.              Lights come in four flavors, point, directional, spherical
  1343.         and spot.  Just as the name implies a point light is a light
  1344.         source occupying a single point in space.  It has position,
  1345.         color, and attributes determining how much the intensity of the
  1346.         light falls off with distance.  A directional light acts like a
  1347.         point light source infinitely far away with no reduction in
  1348.         intensity over distance.  A spherical light source actually has a
  1349.         radius to it and can provide shadows with penumbra (soft edges). 
  1350.         This feature, however, adds a considerable amount to the time
  1351.         needed to render the image.  Spot lights produce a cone of light
  1352.         that falls off on the edges.  These are quite nice for
  1353.         highlighting areas of your model.  In most cases they also
  1354.         produce the least number of shadow rays making them quicker than
  1355.         just putting a point light inside a cone. 
  1356.  
  1357.              The definition for a point light source looks like this:
  1358.         
  1359.         light {
  1360.             type point
  1361.             falloff f            // defaults to 0
  1362.             position x y z
  1363.             color r g b
  1364.         }
  1365.         
  1366.  
  1367.              The falloff parameter determines how the intensity of the
  1368.         light is reduced over distance(dist).  In the real world the
  1369.         light intensity falls off as 1/(dist*dist) (f=2).  Vivid also
  1370.         allows the light to fall off as 1/dist (f=1) and not to fall off
  1371.         at all (f=0).  Why would you want to use anything except f=2?
  1372.         Simplicity is one reason.  With f=0 you can set the light's color
  1373.         to 1 1 1 and know that whatever objects the light falls on will
  1374.         be illuminated fully regardless of the distance of the light from
  1375.         the object.  With f=2 you must take into account this distance. 
  1376.         If the object you wish to be illuminated is 3 units away from the
  1377.         light then in order to get the same amount of illumination that
  1378.         f=0 provides you must set the color to 9 9 9 ie 3^2.  For f=1 the
  1379.         color would have to be 3 3 3.  In the real world much of the
  1380.         light around us does not come directly from the light source.  It
  1381.         often bounces off of other objects on its way to the object we
  1382.         are interested in.  Since Vivid, like most ray tracers, does not
  1383.         model this interobject diffuse reflection we can achieve much the
  1384.         same effect by have the light intensity fall off linearly with
  1385.         distance, ie f=1.  The default value is f=0. 
  1386.  
  1387.              The definition for a directional light source looks like:
  1388.         
  1389.         light {
  1390.             type directional
  1391.  
  1392.                                         24
  1393.  
  1394.  
  1395.  
  1396.             color r g b
  1397.             direction dx dy dz
  1398.         }
  1399.         
  1400.         or the direction can be replaced by a from and at pair:
  1401.         
  1402.         light {
  1403.             type directional
  1404.             color r g b
  1405.             from x y z
  1406.             at x y z
  1407.         }
  1408.         
  1409.         
  1410.  
  1411.              The direction vector points along the direction the light is
  1412.         travelling.  Since the light is assumed to be at infinity, there
  1413.         is no falloff parameter.  If you are having difficulty
  1414.         understanding how the direction parameter works is is sometimes
  1415.         useful to note that direction x y z is the same as center 0 0 0
  1416.         at x y z. 
  1417.  
  1418.              The definition for a spherical light source looks like:
  1419.         
  1420.         light {
  1421.             type spherical
  1422.             position x y z
  1423.             radius r
  1424.             color r g b
  1425.             falloff f
  1426.             samples n
  1427.         }
  1428.         
  1429.  
  1430.              Spherical lights differ from point lights in that the
  1431.         shadows they cast have penumbra.  Normally when a ray hits a
  1432.         surface a shadow ray is shot toward each light.  If the shadow
  1433.         ray hits any surface on the way to the light then that light is
  1434.         blocked and the surface is in the shadow of the blocking object. 
  1435.         With spherical light sources multiple shadow rays are shot.  Each
  1436.         one is shot to a random point within the radius of the light.  If
  1437.         the light is half blocked by an object, approximately half the
  1438.         shadow rays will be blocked and half will pass through to the
  1439.         light.  The ratio of blocked to not-blocked shadow rays is then
  1440.         used to determine how strong the shadow is.  As you might expect,
  1441.         the extra shadow rays will add a lot of extra time to the
  1442.         rendering.  Some references refer to these light sources as
  1443.         extended light sources.  The number of shadow rays shot each time
  1444.         is controlled by the samples parameter.  The default value for
  1445.         this is 16. 
  1446.  
  1447.              The definition for a spot light source looks like:
  1448.         
  1449.  
  1450.                                         25
  1451.  
  1452.  
  1453.  
  1454.         light {
  1455.             type spot
  1456.             position x y z
  1457.             direction dx dy dz
  1458.             min_angle angle1
  1459.             max_angle angle2
  1460.             color r g b
  1461.             falloff f
  1462.         }
  1463.         
  1464.  
  1465.              Like the directional light, the direction parameter may be
  1466.         replaced with the at x y z to specify where the light is shining. 
  1467.         Min_angle and max_angle define the shape of the cone of light
  1468.         produced by the spot light.  Everything within the min_angle
  1469.         angle of the axis of the light will be fully illuminated.  From
  1470.         there the light intensity will fall off until max_angle is
  1471.         reached.  For example if you want a cone of light 30 degrees wide
  1472.         with sharp edges you would define min_angle and max_angle to be
  1473.         30.  To get the same size light but one that fades out at the
  1474.         edges you would define max_angle to be 30 and min_angle to be 0. 
  1475.  
  1476.              Each light source can also have a couple of other
  1477.         parameters.  They are no_shadows and no_spec.  As you've probably
  1478.         guessed, these allow you to turn off shadows and specular
  1479.         highlights for each light.  Used together with a directional
  1480.         light source of low intensity (.2 .2 .2) this is often a nice
  1481.         alternative to global ambient light.  Global ambient light tends
  1482.         to make objects appear flat whereas this technique will provide
  1483.         subtle shading without the shadows and spots of your "real" light
  1484.         sources. 
  1485.  
  1486.              One thing to note is that even if a light is within the
  1487.         viewing scene it will not appear as an object.  If you want you
  1488.         lights to be visible you can wrap a transparent shell around them
  1489.         using a sphere.  Example:
  1490.         
  1491.         //      Define a point light at 2 3 4 that shows up in the scene
  1492.         //      as a light with radius 1.
  1493.         
  1494.         light {
  1495.             center 2 3 4
  1496.             type point
  1497.             color white
  1498.         }
  1499.         
  1500.         //      glass shell
  1501.         
  1502.         surface {
  1503.             ambient white        // same color as the light
  1504.             transparent white    // totally transparent
  1505.         }
  1506.         sphere {
  1507.  
  1508.                                         26
  1509.  
  1510.  
  1511.  
  1512.             center 2 3 4
  1513.             radius 1
  1514.         }
  1515.         
  1516.         For details on spheres and surfaces skip ahead. 
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.                                         27
  1567.  
  1568.  
  1569.  
  1570.  
  1571.                                     Surfaces
  1572.  
  1573.  
  1574.              Surface structures allow you to define the surface
  1575.         characteristics of the objects you are rendering such as color,
  1576.         reflectivity and texture.  When a surface is defined in the input
  1577.         file, it is applied to all the primitives following it until a
  1578.         new surface is defined.  This allows multiple objects to be
  1579.         entered without having to repeat the surface characteristics.  A
  1580.         simple surface structure looks like this:
  1581.         
  1582.         surface {
  1583.             diffuse r g b        // defaults to 0 0 0 (black)
  1584.             ambient r g b        // defaults to 0 0 0
  1585.             specular r g b       // defaults to 0 0 0
  1586.             shine pow            // defaults to 0
  1587.             transparent r g b    // defaults to 0 0 0
  1588.             ior num              // defaults to 1.0
  1589.             fuzz magnitude       // defaults to 0.0
  1590.             no_antialias         // turn off antialiasing
  1591.         }
  1592.         
  1593.  
  1594.              All of these components of the surface are figured in when
  1595.         the ray tracer determines the color of an object in the scene. 
  1596.         The diffuse color is the actual color of the object as seen when
  1597.         illuminated by a full white light.  A value of 0 0 0 signifies a
  1598.         black object while a value of 1 1 1 indicates white.  The
  1599.         brightness of this component depends on the amount of light
  1600.         falling on the surface at that point.  The ambient term is
  1601.         sometimes also referred to as the self-luminous component.  This
  1602.         is the color the object will appear in a totally dark scene.  The
  1603.         specular component specifies the reflectivity of the surface.  A
  1604.         value of 1 1 1 will produce a mirror-like reflection.  The shine
  1605.         value determines how large the specular spot will appear on a
  1606.         surface.  Low values, 1..10, will produce large, soft-edged
  1607.         specular highlights while high values, 1000 or more, will produce
  1608.         a small, sharp spot.  Traditionally the brightness and color of
  1609.         the spot is in direct proportion to the specular component.  The
  1610.         problem is that sometimes it would be nice to have a blue object
  1611.         with specular highlights without having the extra overhead of
  1612.         tracing reflected rays.  Therefore Vivid allows a second form for
  1613.         defining specular spots:
  1614.         
  1615.             shine pow r g b
  1616.         
  1617.  
  1618.              In this case the color given will be used instead of the
  1619.         specular component of the surface.  The transparent component
  1620.         allows you to define how transparent the surface is.  A value of
  1621.         1 1 1 will appear glass-like because it allows all colors to pass
  1622.         through while a value of 1 0 0 will produce a surface like red
  1623.  
  1624.                                         28
  1625.  
  1626.  
  1627.  
  1628.         glass since it only allows red light to pass through.  A surface
  1629.         with a transparent component of .9 .9 .9 will appear partially
  1630.         transparent with the amount of light passed through based on the
  1631.         thickness of the object the light is passing through.  The index
  1632.         of refraction, ior, determines how much the ray is bent as it
  1633.         passes into the transparent surface.  In reality this is related
  1634.         to the relative density of the surface.  To simulate glass values
  1635.         of about 1.1 to 1.3 seem to work best.  The ior of diamond is
  1636.         2.6.  Fuzz is a way of adding random noise to the surface normal
  1637.         of the object when its color is determined.  Since the diffuse
  1638.         color of the object is affected by the angle the light hits the
  1639.         surface this randomization can produce a sort of coarse texuture
  1640.         to an object.  Applied to mirrored or transparent surfaces this
  1641.         produces an affect much like frosted glass.  Generally, small
  1642.         values of fuzz, .01 to .3, seem to work best. 
  1643.  
  1644.              The no_antialias flag tells the adaptive antialiasing to
  1645.         effectively turn off for that surface.  In general this is not
  1646.         something that you want to do except in a few special cases.  The
  1647.         original reason for this parameter was that fuzzy surfaces can
  1648.         cause the adaptive antialias option to shoot lots of rays and
  1649.         slow down the image generation considerably.  By adding the
  1650.         no_antialias flag to the surface definition you still get the
  1651.         benefits of the adaptive antialiasing along the edges of the
  1652.         objects but you avoid the slowdown that can be caused by any
  1653.         large, fuzzy surfaces.  Note, however, that this will change the
  1654.         look of the surface.  Try cutting the amount of fuzz in half when
  1655.         using this option to preserve the amount of color variation in
  1656.         the surface. 
  1657.  
  1658.              As an aid to those of us that can't type, some keywords may
  1659.         be abbreviated: surf, diff, amb, spec and trans.  I trust that
  1660.         you'll be able to figure out what goes with what. 
  1661.  
  1662.              Some examples are probably in order. 
  1663.         
  1664.         //    simple red surface
  1665.         surface {
  1666.             diff 1 0 0
  1667.         }
  1668.         
  1669.         //    self-luminous blue
  1670.         surface {
  1671.             ambient 0 0 1
  1672.         }
  1673.         
  1674.         //      mirror with specular highlights
  1675.         surface {
  1676.             spec 1 1 1
  1677.             shine 100
  1678.         }
  1679.         
  1680.         //      glass with some reflection
  1681.  
  1682.                                         29
  1683.  
  1684.  
  1685.  
  1686.         surface {
  1687.             spec .3 .3 .3
  1688.             shine 30
  1689.             trans .7 .7 .7
  1690.             ior 1.2
  1691.         }
  1692.         
  1693.  
  1694.              In general, the rule of thumb is that amb+diff+spec+trans
  1695.         should be less than or equal to 1 1 1.  Of course since we are
  1696.         defining our own universe anything is possible. 
  1697.  
  1698.  
  1699.  
  1700.  
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738.  
  1739.  
  1740.                                         30
  1741.  
  1742.  
  1743.  
  1744.  
  1745.                                   Bump Mapping
  1746.  
  1747.              Bump mapping is a means of giving a surface some texture
  1748.         which enhances the realism of the surface by adding ripples or
  1749.         bumps to the surface.  The surface isn't actually distorted but
  1750.         its normal is.  This allows a simple surface to appear very
  1751.         complicated.  Bump definitions are included inside of the simple
  1752.         surface definitions, ie:
  1753.         
  1754.         surface {
  1755.             diffuse red
  1756.             bump {
  1757.                 ...
  1758.             }
  1759.         }
  1760.         
  1761.         A sample wave bump map looks like this:
  1762.         
  1763.         bump {
  1764.             wave {
  1765.                 center 1 2 3
  1766.                 wavelength 2.0
  1767.                 amplitude 0.2
  1768.                 damping 0.9          // defaults to 1.0
  1769.                 phase 0.0            // defaults to 0.0
  1770.             }
  1771.         }
  1772.         
  1773.  
  1774.              Center defines the source of the wave.  Wavelength defines
  1775.         the crest to crest distance of the wave.  Amplitude defines the
  1776.         maximum amount that the surface normal is bumped.  Values under 1
  1777.         are definitely best.  The damping parameter defines how much the
  1778.         amplitude falls with distance.  In the example given the
  1779.         amplitude will decrease by 10% for each wavelength of distance
  1780.         from the source.  The phase is a number between 0 and 1 which
  1781.         defines a starting offset for the phase of the wave.  This can be
  1782.         used in animations to create a wave which appears to move
  1783.         realistically by incrementing the phase by a small amount for
  1784.         each frame.  More than one wave may be defined within the bump
  1785.         structure.  By defining three or four wave sources at various
  1786.         locations with differing wavelengths and amplitudes a very
  1787.         realistic rippled surface can be created. 
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794.  
  1795.  
  1796.  
  1797.  
  1798.                                         31
  1799.  
  1800.  
  1801.  
  1802.  
  1803.              Turbulence can also be used to perturb the normal of a
  1804.         surface.  The definition of turbulence looks like this:
  1805.         
  1806.         bump {
  1807.             turbulence {
  1808.                 scale 1 1 1
  1809.                 offset 0 0 0
  1810.                 amplitude .5
  1811.                 terms 4
  1812.             }
  1813.         }
  1814.         
  1815.  
  1816.              The turbulence function takes the location of the ray
  1817.         intersection and returns a random number in the range +-
  1818.         amplitude.  The scale and offset factors are applied to the xyz
  1819.         location before the turbulence function is called.  The terms
  1820.         parameter allows you to build a fractal-like surface.  When
  1821.         terms>1 the turbulence function is summed multiple times.  Each
  1822.         successive term in the sum has its scaling doubled and the
  1823.         amplitude halved.  This produces the varying levels of
  1824.         self-similarity associated with fractals.  The sample file
  1825.         vivid1.v uses this feature and a non-symmetric scaling to produce
  1826.         the "spun-chrome" look on the large sphere.  Turbulence and wave
  1827.         definitions may be included with each other inside a bump
  1828.         definition. 
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.  
  1853.  
  1854.  
  1855.  
  1856.                                         32
  1857.  
  1858.  
  1859.  
  1860.  
  1861.                                 Textured Surfaces
  1862.  
  1863.  
  1864.              Vivid also allows the use of solid texturing to enhance the
  1865.         realism of the surfaces rendered.  Textured surfaces are really
  1866.         just two surfaces with some definition of which appears where on
  1867.         the object and how the two surfaces are blended together.  The
  1868.         surfaces can be "layered" in one of three patterns checker,
  1869.         spherical or noise.  The checker pattern produces a 3-d checker. 
  1870.         The size of the blocks is controlled by the scale factor.  If one
  1871.         of the scale parameters is 0 then the pattern is assumed not to
  1872.         change along that axis.  An example would be a simple
  1873.         checkerboard pattern with checkers 2 units on a side colored
  1874.         black and white.  This pattern is defined to extend infinitely
  1875.         along the z axis. 
  1876.         
  1877.         surface {
  1878.             texture {
  1879.                 pattern checker
  1880.                 scale 2 2 0
  1881.                 offset 0 0 0                 // default
  1882.                 fuzz 0                       // default
  1883.                 blend 0                      // default
  1884.                 surface { diff black }
  1885.                 surface { diff white }
  1886.             }
  1887.         }
  1888.         
  1889.  
  1890.              A scale of 2 0 0 would create a pattern which changes every
  1891.         2 units in the x direction but is continuous in the y and z
  1892.         directions.  This is equivalent to 2-unit thick slabs of material
  1893.         stacked along the x axis.  The spherical pattern produces
  1894.         concentric layers of alternating surfaces.  When one of the scale
  1895.         parameters is 0 concentric cylinders are formed with the axis of
  1896.         the cylinders along the zero'ed axis.  This is useful for wood
  1897.         textures.  The spherical pattern also requires 2 radius
  1898.         definitions for the layers.  The first radius is used for the
  1899.         first surface, etc. 
  1900.         
  1901.         surface {
  1902.             texture {
  1903.                 pattern spherical
  1904.                 scale 2 2 0
  1905.                 radius 1
  1906.                 radius 2
  1907.                 surface { diff black }
  1908.                 surface { diff white }
  1909.             }
  1910.         }
  1911.         
  1912.  
  1913.  
  1914.                                         33
  1915.  
  1916.  
  1917.  
  1918.  
  1919.              The noise pattern uses the output of the noise function
  1920.         directly to pick between the two surfaces.  This is useful for
  1921.         producing textures like granite.  By using unequal scaling values
  1922.         in the x y and z directions you can get a streaked looking
  1923.         surface.  I've also used this using tan and brown surfaces to
  1924.         produce a fine wood-grain look. 
  1925.         
  1926.         surface {
  1927.             texture {
  1928.                 pattern noise
  1929.                 terms 4
  1930.                 scale x y z
  1931.                 surface { diff white }
  1932.                 surface { diff black }
  1933.             }
  1934.         }
  1935.         
  1936.  
  1937.              The fuzz and blend parameters may be used to soften the
  1938.         edges between the two surfaces.  Their values range from 0 to 1. 
  1939.         The blend parameter produces a smooth transition between the
  1940.         surfaces.  The value of the blend parameter determines the width
  1941.         of this transition area.  The fuzz parameter adds noise to the
  1942.         point being checked in proportion to its value.  This produces a
  1943.         coarse, speckled transition between the surfaces. 
  1944.  
  1945.              The turbulence function mention in the bump map section may
  1946.         also be applied to textured surfaces.  By varying the parameters
  1947.         the effect can be made to range from a slight perturbation of the
  1948.         pattern, to a marble look, to excessive turbulence.  A simple
  1949.         example is presented below. 
  1950.  
  1951.              Due to the way Vivid's parser works if you want to bump map
  1952.         a surface which is also textured the bump definition must appear
  1953.         in the surface structure before the texture definition.  Also
  1954.         notice that the surfaces defined in a texture definition need not
  1955.         be simple surfaces.  They may also be textured.  The following is
  1956.         a definition for a checkerboard surface with checks 10 units on a
  1957.         side.  Half the checks are black while the other half have a
  1958.         red/white marble finish. 
  1959.         
  1960.         surface {
  1961.             texture {
  1962.                 pattern checker
  1963.                 scale 10 10 0
  1964.                 surface { diff black }
  1965.                 surface {
  1966.                     texture {
  1967.                         pattern checker
  1968.                         scale 1 0 0
  1969.                         blend 0.7
  1970.                         turbulence {
  1971.  
  1972.                                         34
  1973.  
  1974.  
  1975.  
  1976.                             amplitude 3
  1977.                             terms 4
  1978.                         }
  1979.                         surface { diff white }
  1980.                         surface { diff red }
  1981.                     }
  1982.                 }
  1983.             }
  1984.         }
  1985.         
  1986.  
  1987.  
  1988.  
  1989.  
  1990.  
  1991.  
  1992.  
  1993.  
  1994.  
  1995.  
  1996.  
  1997.  
  1998.  
  1999.  
  2000.  
  2001.  
  2002.  
  2003.  
  2004.  
  2005.  
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018.  
  2019.  
  2020.  
  2021.  
  2022.  
  2023.  
  2024.  
  2025.  
  2026.  
  2027.  
  2028.  
  2029.  
  2030.                                         35
  2031.  
  2032.  
  2033.  
  2034.  
  2035.              Vivid also allows a Mandelbrot pattern as demonstrated in
  2036.         the sample input file vivid1.v.  The Mandelbrot pattern was put
  2037.         into Vivid as a joke one evening.  Currently the format for
  2038.         specifying it is terrible.  The first two parameters of the scale
  2039.         value determine the x y scaling of the set while the 3rd
  2040.         parameter determines the maximum number of iterations.  The
  2041.         result of the iteration calculation is then scaled by the max
  2042.         number of iterations to determine the relative percentages of the
  2043.         surface parameters for that point. 
  2044.  
  2045.              OK, the way it works is like this.  The actual point of
  2046.         intersection, x y z, is tranlated using the scale and offset
  2047.         values before being put into the Mandelbrot calculation. 
  2048.  
  2049.              new_x = x * scale_x + offset
  2050.  
  2051.              Like I said, this is about a backwards as I could make it
  2052.         and still have it work.  Since the point is multiplied by the
  2053.         scale rather than divided the pattern gets bigger as the scale
  2054.         value gets smaller.  Normally the Mandelbrot set extends from -2
  2055.         to +1 along the x axis (more or less).  If you want to get it to
  2056.         fit from -20 to +10 you would have to scale it by 0.1 in the x
  2057.         and y axes.  Stupid? Yes.  Now, since the offset is added on
  2058.         after the multiplication that makes it work in the Mandelbrot
  2059.         coordinate system rather than the world coordinate system. 
  2060.         Continuing the example above, if you wanted to move the center of
  2061.         the set to world coordinates 300, 100 you would have to give an
  2062.         offset of 30 10. 
  2063.  
  2064.              Using macros I think you can alleviate most of this garbage. 
  2065.             #define ITERATION_LIMIT         (64)
  2066.             #define SCALE                   (10)
  2067.             #define X_OFFSET                (300)
  2068.             #define Y_OFFSET                (100)
  2069.         
  2070.             surf {
  2071.                 texture {
  2072.                     pattern mandelbrot
  2073.                     scale (1/SCALE) (1/SCALE) ITERATION_LIMIT
  2074.                     offset (X_OFFSET/SCALE) (Y_OFFSET/SCALE) 0
  2075.                   //  etc...
  2076.         
  2077.                     }
  2078.         
  2079.  
  2080.              Now all you have to do is change the defines and things will
  2081.         work much more like you expect. 
  2082.  
  2083.              Once I figure out a reasonable way of doing this Mandelbrot
  2084.         and Julia sets will become a real part of Vivid.  (Yeah, I know I
  2085.         said that last time but it's still true.)
  2086.  
  2087.  
  2088.                                         36
  2089.  
  2090.  
  2091.  
  2092.  
  2093.                                      Sphere
  2094.  
  2095.              The sphere is the simplest of the primitives supported by
  2096.         Vivid and generally the fastest to perform an intersection test
  2097.         with.  The format for a sphere is:
  2098.         
  2099.         sphere {
  2100.             center x y z
  2101.             radius r
  2102.         }
  2103.         
  2104.         where x y z is the location in space for the center of the sphere
  2105.         and r is the sphere's radius.  As an example here is the
  2106.         definition for two glass spheres, one which is hollow and one
  2107.         which is solid. 
  2108.         
  2109.         //    glass surface
  2110.         
  2111.         surface { trans 1 1 1 shine 200 1 1 1 ior 1.2 }
  2112.         
  2113.         //      solid globe
  2114.         
  2115.         sphere { center 1 0 0 radius .9 }
  2116.         
  2117.         //      hollow globe
  2118.         
  2119.         sphere { center -1 0 0 radius .9 }      // outer surface
  2120.         sphere { center -1 0 0 radius .8 }     // inner surface
  2121.         
  2122.  
  2123.              Just for laughs vivid also includes a fuzzy spheres option. 
  2124.         These spheres appear fuzzy because they have no fixed radius.  To
  2125.         define a fuzzy sphere define a normal sphere and add a fuzz
  2126.         parameter.  This defines how much larger the radius will randomly
  2127.         be.  Each time the ray tracer performs an intersection test with
  2128.         the fuzzy sphere, the radius to test against is randomly chosen
  2129.         to lie between the radius and radius+fuzz. 
  2130.         
  2131.         //      fuzzy sphere with radius between 0.5 and 2
  2132.         sphere {
  2133.             center 0 1 2
  2134.             radius .5
  2135.             fuzz 1.5
  2136.         }
  2137.         
  2138.         
  2139.  
  2140.  
  2141.  
  2142.  
  2143.  
  2144.  
  2145.  
  2146.                                         37
  2147.  
  2148.  
  2149.  
  2150.  
  2151.                                       Ring
  2152.  
  2153.              The ring primitive may also be described as a washer or
  2154.         disk.  The definition for a ring consists of a location, a
  2155.         surface normal, and a minimum and maximum radius.  The minimum
  2156.         radius may be zero producing a disk without a center hole. 
  2157.         Because the intersection for the ring is faster than for a
  2158.         polygon the ring is a good choice for use as a ground plane
  2159.         underneath the objects you are ray tracing.  The format for the
  2160.         ring definition is:
  2161.         
  2162.         ring {
  2163.             center x y z
  2164.             normal a b c
  2165.             min_radius r0
  2166.             max_radius r1
  2167.         }
  2168.         
  2169.  
  2170.              The surface normal a b c does not have to be normalized.  If
  2171.         you just want a disk without a center hole the min/max radius
  2172.         definitions may be replaced with a single radius definition as
  2173.         follows. 
  2174.         
  2175.         ring {
  2176.             center x y z
  2177.             normal a b c
  2178.             radius r
  2179.         }
  2180.         
  2181.         
  2182.  
  2183.              Whoa, just got a clue that not everyone knows what a surface
  2184.         normal is.  A surface normal is a vector that is perpendicular to
  2185.         a surface, ie one that points straight out from the surface.  For
  2186.         example, the surface normal for the floor in you room would be a
  2187.         vector pointing straight up into the air.  The surface normal of
  2188.         your monitor is the vector pointing straight out between you
  2189.         eyes.  Simple enough? Ok, now a normalized vector is one which
  2190.         has been scaled to have its length equal exactly 1.  This is
  2191.         usually done by calculating the length of the vector then
  2192.         dividing each of the vector's components by the length.  Vectors
  2193.         of length 0 cause no end of problems. 
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200.  
  2201.  
  2202.  
  2203.  
  2204.                                         38
  2205.  
  2206.  
  2207.  
  2208.  
  2209.                                      Polygon
  2210.  
  2211.              Polygons may have any number of vertices (well, a minimum of
  2212.         three is required).  The vertices must all lie within the same
  2213.         plane otherwise the results will be strange.  The order of the
  2214.         vertices may be either clockwise or counter clockwise. 
  2215.         
  2216.         polygon {
  2217.             points 4
  2218.             vertex  1  1 0
  2219.             vertex  1 -1 0
  2220.             vertex -1 -1 0
  2221.             vertex -1  1 0
  2222.         }
  2223.         
  2224.  
  2225.  
  2226.              This will produce a square polygon 2 units on a side
  2227.         centered at the origin with a surface normal equal to 0 0 1. 
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250.  
  2251.  
  2252.  
  2253.  
  2254.  
  2255.  
  2256.  
  2257.  
  2258.  
  2259.  
  2260.  
  2261.  
  2262.                                         39
  2263.  
  2264.  
  2265.  
  2266.  
  2267.                                 Triangular Patch
  2268.  
  2269.              The triangular patch is useful for building objects with
  2270.         complex shapes that you want to appear smooth.  The patch is
  2271.         defined by three vertices and explicit surface normals for each
  2272.         vertex.  In general, manually entering in patches will probably
  2273.         be too tedious to be of much use but when using computer
  2274.         generated input files the results will be worth the extra
  2275.         programming effort. 
  2276.         
  2277.         patch {
  2278.             vertex 1 0 0 normal .1 0 1
  2279.             vertex 0 1 1 normal 0 .1 1
  2280.             vertex 0 0 .5 normal -.1 -.1 1
  2281.         }
  2282.         
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298.  
  2299.  
  2300.  
  2301.  
  2302.  
  2303.  
  2304.  
  2305.  
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.  
  2314.  
  2315.  
  2316.  
  2317.  
  2318.  
  2319.  
  2320.                                         40
  2321.  
  2322.  
  2323.  
  2324.  
  2325.                                       Cone
  2326.  
  2327.              The cones implemented by Vivid are actually truncated cones. 
  2328.         They have a radius both at their base and at their apex.  When
  2329.         these radii are equal the cone does a fair imitation of a
  2330.         cylinder.  To get a pointed cone enter 0 for one of the radii. 
  2331.         
  2332.         cone {
  2333.             base 1 1 1 base_radius 4
  2334.             apex 0 0 5 apex_radius 1
  2335.         }
  2336.         
  2337.  
  2338.              Rings are useful for putting caps on the ends of cones. 
  2339.         Even for a cone at an odd angle the position and normal of the
  2340.         ring can be easily calculated.  To cap the apex end of the cone
  2341.         the ring's center is equal to the apex, the ring's radius is
  2342.         equal to the apex_radius and the ring's normal is equal to
  2343.         apex-base.  Using the example above the definition for a ring to
  2344.         cap the apex end of the cone would look like this:
  2345.         
  2346.         ring {
  2347.             center 0 0 5
  2348.             radius 1
  2349.             normal -1 -1 4
  2350.         }
  2351.         
  2352.  
  2353.  
  2354.  
  2355.  
  2356.  
  2357.  
  2358.  
  2359.  
  2360.  
  2361.  
  2362.  
  2363.  
  2364.  
  2365.  
  2366.  
  2367.  
  2368.  
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.                                         41
  2379.  
  2380.  
  2381.  
  2382.  
  2383.                                  Transformations
  2384.  
  2385.  
  2386.              Vivid's transformation commands allow you to move and scale
  2387.         objects.  Transformation commands apply to all the primitives
  2388.         following them until they are "popped" from the transformation
  2389.         stack.  The format for a transformation command is:
  2390.         
  2391.         transform {
  2392.             scale           s
  2393.             rotate          x y z
  2394.             translate       dx dy dz
  2395.         }
  2396.         
  2397.  
  2398.              Scale changes the size of the objects.  Scale may also be
  2399.         defined as a vector to create objects that are scaled differently
  2400.         in each axis.  Unfortunately this doesn't work with all
  2401.         primitives, only polygons and patches can be scaled
  2402.         non-uniformally.  The rotate command rotates the object the given
  2403.         number of degrees around each axis.  The translate command moves
  2404.         the object.  Any of these may be left out or used more than once. 
  2405.         They can also be used in any order and will be applied to the
  2406.         objects in the order that they are given.  It is very important
  2407.         that you get the order correct.  An object that is rotated 90
  2408.         degrees around the Z axis and translated 10 units along the X
  2409.         axis will end up at 10 0 0 with a 90 degree twist whereas if the
  2410.         operations are applied in the other order the object will end up
  2411.         at 0 10 0.  Sometimes it helps to play around with real objects a
  2412.         bit and work through some of the transformations first.  Remember
  2413.         that all rotations are done around the axes, not necessarily
  2414.         around the center of the object.  This should also be kept in
  2415.         mind when building new objects.  Put 0 0 0 at the objects
  2416.         "natural" center of rotation.  This will help greatly when
  2417.         building scenes with the objects.  For example, the natural
  2418.         "center" for a car model would be at ground level in the center
  2419.         of the car.  This allows the car to fairly easily be placed in
  2420.         the scene where you want it. 
  2421.  
  2422.              To remove a transformation from the transform stack use the
  2423.         "transform_pop" command.  Sometimes you will want to nest
  2424.         transform commands.  This is useful for creating multi-part
  2425.         objects that move relative to each other but also need to move as
  2426.         a whole unit.  For example, say you want to create a tank model
  2427.         with a turret that you can rotate.  Assume that the body of your
  2428.         tank model is in the file tank.vo and the turret is in turret.vo. 
  2429.         To place the tank in your scene, your input file would look like
  2430.         this:
  2431.         
  2432.         #define TURRET_ANGLE    (30)    // rotation for turret
  2433.         
  2434.         transform { translate x y z }   // move whole tank
  2435.  
  2436.                                         42
  2437.  
  2438.  
  2439.  
  2440.         #include tank.vo                // include body geometry
  2441.         transform { rotate 0 0 TURRET_ANGLE }
  2442.         #include turret.vo              // include turret geometry
  2443.         
  2444.         transform_pop           // clean up transform stack
  2445.         transform_pop
  2446.         
  2447.  
  2448.              Using this technique complicated models can be built and
  2449.         positioned with relative ease.  There is currently one major
  2450.         drawback to using transformations, surface textures don't move
  2451.         with the object.  This isn't too big a deal for single frame
  2452.         images but will make animating textured objects look very poor. 
  2453.         Yes, I'm working on it. 
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466.  
  2467.  
  2468.  
  2469.  
  2470.  
  2471.  
  2472.  
  2473.  
  2474.  
  2475.  
  2476.  
  2477.  
  2478.  
  2479.  
  2480.  
  2481.  
  2482.  
  2483.  
  2484.  
  2485.  
  2486.  
  2487.  
  2488.  
  2489.  
  2490.  
  2491.  
  2492.  
  2493.  
  2494.                                         43
  2495.  
  2496.  
  2497.  
  2498.  
  2499.                                     Clipping
  2500.  
  2501.  
  2502.              Primitives can also be "clipped" to produce more complicated
  2503.         shapes.  Basically the way a clip works is that a primitive is
  2504.         defined with a clipping surface which cuts off part of that
  2505.         primitive.  For example a sphere can be clipped against a plane
  2506.         to produce a hemisphere or a cone can be used to clip a hole
  2507.         through another cone.  There are three types of clipping surface:
  2508.         planes, spheres and cones.  Clips are defined within a
  2509.         primitive's definiton.  You may have more than one clip per
  2510.         primitive.  Clips also transform along with their primitives. 
  2511.  
  2512.              A clipping plane is defined by a point and a normal. 
  2513.             clip {
  2514.                 center x y z
  2515.                 normal x y z
  2516.             }
  2517.         
  2518.  
  2519.              The part of the primitive on the normal side of the plane
  2520.         will be kept while the part on the other side will disappear into
  2521.         the Ronald Reagan Memorial Library.  (You may think I'm lying but
  2522.         you'll never really _know_ until you go check.) For example, if
  2523.         you want to get a hemipshere of radius 1 centered at the origin
  2524.         if would look like:
  2525.             sphere {
  2526.                 center 0 0 0 radius 1
  2527.                 clip {
  2528.                     center 0 0 0 normal 0 0 1
  2529.                 }
  2530.             }
  2531.         
  2532.  
  2533.              Note that the clip's normal is pointing upward.  This will
  2534.         give you the top half of the sphere.  If you change the normal to
  2535.         0 0 -1 you will get the bottom half. 
  2536.  
  2537.              Clipping spheres are defined as:
  2538.             clip {
  2539.                 center x y z
  2540.                 radius r
  2541.                 inside or outside
  2542.             }
  2543.         
  2544.  
  2545.              With a clipping sphere you can choose to either keep the
  2546.         part of the primitive inside of the sphere or the part of the
  2547.         primitive outside of the sphere.  You may have already guessed
  2548.         this but that's why the inside and outside keywords are there. 
  2549.  
  2550.              Clipping cones look like:
  2551.  
  2552.                                         44
  2553.  
  2554.  
  2555.  
  2556.             clip {
  2557.                 apex x y z      apex_radius r
  2558.                 base x y z      base_radius r
  2559.                 inside or outside
  2560.             }
  2561.         
  2562.  
  2563.              Just like the cone primitive you may also just define a
  2564.         single radius to get a cylinder. 
  2565.  
  2566.                                         
  2567.  
  2568.              Sometimes you will want to apply the same clips to a group
  2569.         of primitives.  To do this define global clips using the
  2570.         global_clip keyword:
  2571.             global_clip {
  2572.                 clip { ... }
  2573.                 clip { ... }
  2574.                 clip { ... }
  2575.             }
  2576.         
  2577.  
  2578.              The clip_pop keyword will cause the previous section of
  2579.         clips to be popped off the stack much like the transform_pop does
  2580.         for transformations. 
  2581.  
  2582.  
  2583.  
  2584.  
  2585.  
  2586.  
  2587.  
  2588.  
  2589.  
  2590.  
  2591.  
  2592.  
  2593.  
  2594.  
  2595.  
  2596.  
  2597.  
  2598.  
  2599.  
  2600.  
  2601.  
  2602.  
  2603.  
  2604.  
  2605.  
  2606.  
  2607.  
  2608.  
  2609.  
  2610.                                         45
  2611.  
  2612.  
  2613.  
  2614.  
  2615.                                 Support Programs
  2616.  
  2617.                                    img2gif.exe
  2618.  
  2619.              Once vivid has completed an image you need some way to view
  2620.         the results.  That's where img2gif comes in.  Img2gif is used to
  2621.         convert the raw img file that Vivid outputs into a gif file.  The
  2622.         resulting gif file can then be viewed using your favorite view
  2623.         program.  My favorite is Brad Montgomery's vpic.  Look for it on
  2624.         you local BBS.  In a pinch, even fractint can be used to view
  2625.         gifs. 
  2626.  
  2627.              When running img2gif you have 2 main decisions to make: a)
  2628.         how should the program pick the palette and b) should the program
  2629.         do any dithering of the output.  Picking the palette is not
  2630.         always an easy problem.  Standard VGA allows us to view only 256
  2631.         of the available 262,144 colors.  An "average" lores image will
  2632.         have about 7000 colors which we need to represent with our
  2633.         palette of 256.  A higher resolution image my have tens of
  2634.         thousands of colors to represent.  The following algorithms are
  2635.         currently implemented in img2gif. 
  2636.  
  2637.              Palette File -- A palette may be input via a .map file. 
  2638.         This uses the same format as .map files created/read by fractint. 
  2639.         This option is useful for creating multiple gifs with the same
  2640.         palette for animation. 
  2641.  
  2642.              Popularity -- The popularity algorithm chooses the palette
  2643.         by picking the 256 colors which represent then greatest number of
  2644.         pixels in the image.  The remaining colors in the image are
  2645.         mapped onto the palette using a minimum distance formula.  The
  2646.         popularity algorithm tends to work best on images with a lower
  2647.         number of colors.  One typical problem of the algorithm is that
  2648.         small highlights may not be colored correctly.  Highlights
  2649.         generally only cover a few pixels so their color usually doesn't
  2650.         have enough representation in the image to be chosen by the
  2651.         popularity algorithm.  To help alleviate this problem, img2gif
  2652.         forces the corners of the color cube (white, red, green, blue,
  2653.         cyan, magenta, yellow, and black) to be selected as the first
  2654.         eight palette entries.  Since most highlights are white this
  2655.         greatly helps reduce unwanted artifacts in the resulting image. 
  2656.  
  2657.              Median Cut -- The median cut algorithm tries to choose a
  2658.         more well balanced set of colors to represent the image.  The
  2659.         general idea of the median cut is to choose a palette in which
  2660.         each entry represents about the same number of pixels in the
  2661.         image.  This helps to correctly color highlights that a pure
  2662.         popularity algorithm might miss.  Img2gif also allows you to
  2663.         limit the number of pixels represented by any one color.  This,
  2664.         in effect, increases the importance of the colors in highlights
  2665.         and other small regions of the image.  With this limit set to
  2666.         one, every color in the image is given the same weight without
  2667.  
  2668.                                         46
  2669.  
  2670.  
  2671.  
  2672.         regard for the number of pixels it covers. 
  2673.  
  2674.              Fixed Palette -- The fixed palette option uses a
  2675.         predetermined palette instead of choosing one based on the
  2676.         content of the image.  This has the advantage of being much
  2677.         faster.  When choosing by popularity or median cut img2gif must
  2678.         first build a tree structure in memory containing every color in
  2679.         the image and a count of the number of pixels represented by that
  2680.         color.  After choosing the palette the colors in the tree must
  2681.         then be mapped onto the colors in the palette.  This can slow
  2682.         img2gif down quite a bit.  When using a fixed palette the image
  2683.         colors are mapped directly onto the palette colors via simple
  2684.         equations eliminating the need for the tree structure and the
  2685.         costly remapping of the images colors to an arbitrary palette. 
  2686.         Also, the current version of img2gif can only support a tree
  2687.         containing about 57,000 colors.  After this my clone runs out of
  2688.         RAM.  The fixed palettes supported by img2gif are:
  2689.  
  2690.              0 : A grey scale image using 256 grey scale tones.  Due to
  2691.         VGA limitations this will display as 64 shades on most PC
  2692.         systems. 
  2693.  
  2694.              1 : Divides the color cube into 8 shades of red, 8 shades of
  2695.         green, and 4 shades of blue.  Generally produces fairly bad
  2696.         images but kept in for nostalgia.  Blue was chosen to get the
  2697.         lower resolution because in general the human eye is much less
  2698.         sensitive in the blue range and has a harder time focusing on
  2699.         edges therefore the loss of color resolution is not missed as
  2700.         much. 
  2701.  
  2702.              2 : Divides the color cube into 6 shades of red, 7 shades of
  2703.         green, and 6 shades of blue.  This option gives the best balance
  2704.         of speed vs good color representation.  I've found that it works
  2705.         best with images that have a large number of colors.  The
  2706.         addition of dithering is usually helpful. 
  2707.  
  2708.              Dithering is the process of displaying pixels of differing
  2709.         colors next to each other in such a way as to produce the
  2710.         illusion of more colors.  An every day example of this is your
  2711.         television.  Stick your nose up to the picture tube and notice
  2712.         that the screen is made up of tiny red, green, and blue dots
  2713.         which vary in intensity.  These are the only colors your TV
  2714.         actually produces but your eye combines them to produce the rest
  2715.         of the spectrum.  Well, at least the spectrum according to NTSC. 
  2716.  
  2717.              Floyd Steinberg dithering is the original error diffusion
  2718.         dithering algorithm.  Error diffusion dithering attempts to
  2719.         compensate for a limited palette by insuring that the sum of the
  2720.         errors in any region of the image is zero even though the colors
  2721.         at each individual pixel may contain some error.  At each pixel
  2722.         as img2gif scans through the image the nearest color for that
  2723.         pixel is chosen.  Generally this color will not be exact.  The
  2724.         difference between the chosen palette color and the true color is
  2725.  
  2726.                                         47
  2727.  
  2728.  
  2729.  
  2730.         then added to the neighboring pixels which have not been scanned
  2731.         yet.  Floyd Steinberg dithering has the advantage of having a
  2732.         "random" look to it.  Generally, it does not produce noticeable
  2733.         patterns in the output image. 
  2734.  
  2735.              Ordered dithering works by adding a fixed amount to each
  2736.         pixel based on its location.  The sum of these additions over a
  2737.         region of the image is equal to zero.  Since ordered dither does
  2738.         not take into account the values of neighboring pixels it
  2739.         produces fixed patterns in the images which may be distracting in
  2740.         some cases.  Ordered dithering combined with a fixed palette has
  2741.         an advantage if you are using Vivid to produce single fames for
  2742.         an animation.  During an animation the background (non-moving)
  2743.         regions of the image will stay constant whereas if you use Floyd
  2744.         Steinberg dithering the patterns constantly shift around and
  2745.         below any moving objects on the screen. 
  2746.  
  2747.              The random noise option allows you to add white noise to an
  2748.         image.  In some cases this may help as much as dithering.  It can
  2749.         also be used in conjunction with either of the dithering options. 
  2750.         Interesting effects may be obtained by increasing the range of
  2751.         the noise.  Images converted with a large amount of noise tend to
  2752.         take on a distinctly grainy look.  Interesting, but not overly
  2753.         useful.  The default range for the noise is +-8 on a 0..255
  2754.         range.  This value was chosen strictly because it seemed to look
  2755.         good in most cases.  Random noise has the advantage of being
  2756.         constant from image to image.  This means that smooth areas in a
  2757.         series of images will not shimmer during animation. 
  2758.  
  2759.              Ok, fine, now how do I run img2gif? Well, it goes like this:
  2760.  
  2761.              img2gif [-m #] [-f #] [-p palfile] [-d] [-o] [-r [#]] file
  2762.  
  2763.              The default palette choosing algorithm is the popularity
  2764.         method. 
  2765.  
  2766.              [-m #] chooses median cut and limits each color to represent
  2767.         at most # pixels.  # defaults to 64K. 
  2768.  
  2769.              [-f #] chooses fixed palette #.  # defaults to 0, grey
  2770.         scale. 
  2771.  
  2772.              [-p palfile] reads the palette out of the file palfile.map. 
  2773.         If this file does not exist the palette will be chosen by median
  2774.         cut, popularity, or fixed depending on what other flags are set. 
  2775.         After the palette is chosen it will then be written to the file
  2776.         palfile.map. 
  2777.  
  2778.              [-d] chooses Floyd Steinberg dithering. 
  2779.  
  2780.              [-o] chooses ordered dithering. 
  2781.  
  2782.              [-r #] chooses random noise +- #.  # defaults to 8. 
  2783.  
  2784.                                         48
  2785.  
  2786.  
  2787.  
  2788.  
  2789.              For example:
  2790.  
  2791.              img2gif -f 2 -d test
  2792.  
  2793.              will convert test.img to test.gif using fixed palette 2 and
  2794.         Floyd Steinberg dithering. 
  2795.  
  2796.              Assuming that test.map does not exist
  2797.         
  2798.         img2gif -m -p test test1
  2799.         img2gif -m -p test test2
  2800.         img2gif -m -p test test3
  2801.         img2gif -m -p test test4
  2802.         
  2803.         will convert test1 using median cut to choose the palette.  The
  2804.         palette will then be saved to test.map.  Test2, test3, and test4
  2805.         will then be converted using the palette in test.map. 
  2806.  
  2807.              In general the best results will be obtained by using the -m
  2808.         -d flags as in img2gif -m -d test.  For images that tend to be
  2809.         fairly monochromatic I've found that -m -d -r 4 works well. 
  2810.         Adding the small amount of random noise helps break up some of
  2811.         the banding.  On the down side it also adds to the .gif file size
  2812.         since it is tough to compress random noise well.  To get nice
  2813.         looking grey scale images try -f 0 -r. 
  2814.  
  2815.  
  2816.  
  2817.  
  2818.  
  2819.  
  2820.  
  2821.  
  2822.  
  2823.  
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.                                         49
  2843.  
  2844.  
  2845.  
  2846.  
  2847.                                     paste.exe
  2848.  
  2849.              The paste tool will allow you to join together two images in
  2850.         raw file format either vertically (one over the other) or
  2851.         horizontally (side by side), ie.  two 320x200 images may be
  2852.         joined together to form a 320x400 image or a 640x200 image.  In
  2853.         order for two images to be joined vertically the images must have
  2854.         the same width.  In order for them to be joined horizontally they
  2855.         must have the same height. 
  2856.  
  2857.              The calling sequence for paste is:
  2858.  
  2859.              paste [-h | -v] in_file1.img in_file2.img out_file.img
  2860.  
  2861.              In the horizontal case in_file1.img will appear to the right
  2862.         of in_file2.img.  In the vertical case in_file1.img will appear
  2863.         above in_file2.img. 
  2864.  
  2865.  
  2866.  
  2867.  
  2868.  
  2869.  
  2870.  
  2871.  
  2872.  
  2873.  
  2874.  
  2875.  
  2876.  
  2877.  
  2878.  
  2879.  
  2880.  
  2881.  
  2882.  
  2883.  
  2884.  
  2885.  
  2886.  
  2887.  
  2888.  
  2889.  
  2890.  
  2891.  
  2892.  
  2893.  
  2894.  
  2895.  
  2896.  
  2897.  
  2898.  
  2899.  
  2900.                                         50
  2901.  
  2902.  
  2903.  
  2904.  
  2905.                                      up.exe
  2906.  
  2907.              Up allows you to double an image's size vertically,
  2908.         horizontally, or in both directions.  The increase in size is
  2909.         done by pixel duplication, no interpolation is used.  The calling
  2910.         sequence is:
  2911.  
  2912.              up [-h | -v] in_file.img out_file.img
  2913.  
  2914.              If no flag is given, up increases the image's size in both
  2915.         directions. 
  2916.  
  2917.              For example if test.img is a 320x200 image
  2918.  
  2919.              up -v test.img test2.img
  2920.  
  2921.              will create test2.img with a resolution of 320x400. 
  2922.  
  2923.  
  2924.  
  2925.  
  2926.  
  2927.  
  2928.  
  2929.  
  2930.  
  2931.  
  2932.  
  2933.  
  2934.  
  2935.  
  2936.  
  2937.  
  2938.  
  2939.  
  2940.  
  2941.  
  2942.  
  2943.  
  2944.  
  2945.  
  2946.  
  2947.  
  2948.  
  2949.  
  2950.  
  2951.  
  2952.  
  2953.  
  2954.  
  2955.  
  2956.  
  2957.  
  2958.                                         51
  2959.  
  2960.  
  2961.  
  2962.  
  2963.                                     down.exe
  2964.  
  2965.              Down does the opposite of up.  (surprise!) When reducing an
  2966.         image's size, down averages the appropriate pixels to produce the
  2967.         new pixel.  The calling sequence is:
  2968.  
  2969.              down [-h | -v] infile.img outfile.img
  2970.  
  2971.              If no flag is given, down reduces the image in both
  2972.         directions. 
  2973.  
  2974.              For example if test is a 320x200 image
  2975.  
  2976.              down test.img test2.img
  2977.  
  2978.              will produce test2.img with a resolution of 160x100. 
  2979.  
  2980.  
  2981.  
  2982.  
  2983.  
  2984.  
  2985.  
  2986.  
  2987.  
  2988.  
  2989.  
  2990.  
  2991.  
  2992.  
  2993.  
  2994.  
  2995.  
  2996.  
  2997.  
  2998.  
  2999.  
  3000.  
  3001.  
  3002.  
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008.  
  3009.  
  3010.  
  3011.  
  3012.  
  3013.  
  3014.  
  3015.  
  3016.                                         52
  3017.  
  3018.  
  3019.  
  3020.  
  3021.                                   File Formats
  3022.  
  3023.  
  3024.              The information included here about the file formats is to
  3025.         aid people in writing their own image manipulation utilities
  3026.         compatible with the Vivid formats.  I encourage you to experiment
  3027.         and share any interesting results with the rest of us. 
  3028.  
  3029.              img -- This is the format of the files output by Vivid.  The
  3030.         images are stored 24-bits per pixel with a simple run length
  3031.         encoding scheme to help keep the size down.  The run length
  3032.         encoding works by replacing a repetitive string of the same color
  3033.         with a count value and that color written only once.  "Runs" of
  3034.         the same color are not allowed to continue beyond the end of the
  3035.         scanline to make working a scanline at a time easier.  The format
  3036.         consists of a 10 byte header followed by the image data.  The
  3037.         16-bit numbers in the header are stored most significant byte
  3038.         first.  This format is compatible with that used by Alias
  3039.         Research.  (I think.)
  3040.         
  3041.         <2-bytes>    x size of image
  3042.         <2-bytes>    y size of image
  3043.         <2-bytes>    first scanline, usually 0
  3044.         <2-bytes>    last scanline, usually y size - 1
  3045.         <2-bytes>    number of bitplanes, always 24
  3046.         <image data>
  3047.         
  3048.         The image data format looks like:
  3049.         
  3050.         <1-byte>    a repeat count for the following color
  3051.         <1-byte>    blue, 0..225
  3052.         <1-byte>    green, 0..255
  3053.         <1-byte>    red, 0..255
  3054.         
  3055.         This is repeated as many times as necessary to complete the
  3056.         image.  Note: runs do not wrap from one scan line to the next. 
  3057.         This helps simplify post-processing.  It has been noted (hi Ray!)
  3058.         that in some of Vivid's antialiasing modes an extra scan line is
  3059.         output to the file.  This may eventually get fixed but for now
  3060.         the best thing to do is to always use the info in the header
  3061.         rather than looking for the end of file. 
  3062.  
  3063.              map -- This is the format used for palette files.  This
  3064.         format was chosen to be compatible with fractint.  The file is in
  3065.         plain ASCII text and consists of 256 lines each containing the
  3066.         red, green and blue value for that palette entry.  The rgb values
  3067.         are integers in the range 0..255. 
  3068.  
  3069.  
  3070.  
  3071.  
  3072.  
  3073.  
  3074.                                         53
  3075.  
  3076.  
  3077.  
  3078.  
  3079.                                   Bibliography
  3080.  
  3081.  
  3082.              For anyone interested in ray tracing and how it works the
  3083.         following books are highly recommended.  Further references may
  3084.         be found in the bibliography at the end of Glassner's book. 
  3085.  
  3086.              "Computer Graphics, Principles and Practice, 2nd Ed.",
  3087.         Foley, van Dam, Feiner and Hughes, 1990, ISBN 0-201-12110-7
  3088.  
  3089.              "An Introduction to Ray Tracing", Andrew S.  Glassner, ed.,
  3090.         Academic Press, 1989, ISBN 0-12-286160-4
  3091.  
  3092.              "Illumination and Color in Computer Generated Imagery", Roy
  3093.         Hall, Springer-Verlag, 1989, ISBN 0-387-96774-5
  3094.  
  3095.  
  3096.  
  3097.  
  3098.  
  3099.  
  3100.  
  3101.  
  3102.  
  3103.  
  3104.  
  3105.  
  3106.  
  3107.  
  3108.  
  3109.  
  3110.  
  3111.  
  3112.  
  3113.  
  3114.  
  3115.  
  3116.  
  3117.  
  3118.  
  3119.  
  3120.  
  3121.  
  3122.  
  3123.  
  3124.  
  3125.  
  3126.  
  3127.  
  3128.  
  3129.  
  3130.  
  3131.  
  3132.                                         54
  3133.  
  3134.  
  3135.  
  3136.  
  3137.                                       Index
  3138.  
  3139.                   #define. . . . . . . . . . . . . . . . . . . . .  15
  3140.               #include . . . . . . . . . . . . . . . . . . . 5, 16
  3141.                   ambient. . . . . . . . . . . . . . . . . . . . .  19
  3142.                   angle. . . . . . . . . . . . . . . . . . . . . .  17
  3143.                   antialiasing . . . . . . . . . . . . . . . . . .  20
  3144.                   aperture . . . . . . . . . . . . . . . . . . . .  21
  3145.                   aspect ratio . . . . . . . . . . . . . . . . . .  18
  3146.                   at . . . . . . . . . . . . . . . . . . . . . . .  17
  3147.                   background color . . . . . . . . . . . . . . . .  19
  3148.                   bibliography . . . . . . . . . . . . . . . . . .  54
  3149.                   blend. . . . . . . . . . . . . . . . . . . . . .  34
  3150.                   bump mapping . . . . . . . . . . . . . . . . . .  31
  3151.                   bunching . . . . . . . . . . . . . . . . . . . .  22
  3152.                   caustics . . . . . . . . . . . . . . . . . . . .  22
  3153.                   changes for 2.0. . . . . . . . . . . . . . . . .   3
  3154.                   checker pattern. . . . . . . . . . . . . . . . .  33
  3155.                   clipping . . . . . . . . . . . . . . . . . . . .  44
  3156.                   clipping plane . . . . . . . . . . . . . . . . .  44
  3157.                   colors . . . . . . . . . . . . . . . . . . . . .  13
  3158.                   command line flags . . . . . . . . . . . . . . .   6
  3159.                   comments . . . . . . . . . . . . . . . . . . . .  14
  3160.                   compound surfaces. . . . . . . . . . . . . . . .  33
  3161.                   cone . . . . . . . . . . . . . . . . . . . . . .  41
  3162.                   coordinate system. . . . . . . . . . . . . . . .  13
  3163.                   depth. . . . . . . . . . . . . . . . . . . . . .  22
  3164.                   dithering. . . . . . . . . . . . . . . . . . . .  47
  3165.                   down.exe . . . . . . . . . . . . . . . . . . . .  52
  3166.                   field of view angle. . . . . . . . . . . . . . .  17
  3167.                   file extensions. . . . . . . . . . . . . . . . .   5
  3168.                   file formats . . . . . . . . . . . . . . . . . .  53
  3169.                   fixed palettes . . . . . . . . . . . . . . . . .  47
  3170.                   Floyd Steinberg dithering. . . . . . . . . . . .  47
  3171.                   focal_length . . . . . . . . . . . . . . . . . .  21
  3172.                   from . . . . . . . . . . . . . . . . . . . . . .  17
  3173.                   fuzz . . . . . . . . . . . . . . . . . . . . . .  34
  3174.                   gif. . . . . . . . . . . . . . . . . . . . . . .  46
  3175.                   global clipping. . . . . . . . . . . . . . . . .  45
  3176.                   haze . . . . . . . . . . . . . . . . . . . . . .  19
  3177.                   img file format. . . . . . . . . . . . . . . . .  53
  3178.                   img2gif.exe. . . . . . . . . . . . . . . . . . .  46
  3179.                   include files. . . . . . . . . . . . . . . . . .   5
  3180.                   input file format. . . . . . . . . . . . . . . .  13
  3181.                   jitter . . . . . . . . . . . . . . . . . . . . .  21
  3182.               lights . . . . . . . . . . . . . . . . . . . . .  24
  3183.                  directional . . . . . . . . . . . . . . .  24
  3184.                  point . . . . . . . . . . . . . . . . . .  24
  3185.                  spherical . . . . . . . . . . . . . . . .  25
  3186.                  spot. . . . . . . . . . . . . . . . . . .  25
  3187.                   macro. . . . . . . . . . . . . . . . . . . . . .  15
  3188.               macro continuation . . . . . . . . . . . . . . .  15
  3189.  
  3190.                                         55
  3191.  
  3192.  
  3193.  
  3194.                   mandelbrot . . . . . . . . . . . . . . . . . . .  36
  3195.                   map file format. . . . . . . . . . . . . . . . .  53
  3196.                   median cut algorithm . . . . . . . . . . . . . .  46
  3197.                   noise. . . . . . . . . . . . . . . . . . . . . .  34
  3198.                   no_antialias . . . . . . . . . . . . . . . . . .  29
  3199.                   no_exp_trans . . . . . . . . . . . . . . . . . .  21
  3200.                   no_shadows . . . . . . . . . . . . . . . . . . .  21
  3201.                   ordered dither . . . . . . . . . . . . . . . . .  48
  3202.                   palette file . . . . . . . . . . . . . . . . . .  46
  3203.                   paste.exe. . . . . . . . . . . . . . . . . . . .  50
  3204.                   polygon. . . . . . . . . . . . . . . . . . . . .  39
  3205.                   popularity algorithm . . . . . . . . . . . . . .  46
  3206.                   preprocessor . . . . . . . . . . . . . . . . . .  15
  3207.                   projection . . . . . . . . . . . . . . . . . . .  18
  3208.                   random noise dithering . . . . . . . . . . . . .  48
  3209.                   resolution . . . . . . . . . . . . . . . . . . .  18
  3210.                   resume . . . . . . . . . . . . . . . . . . . . .   6
  3211.                   right-handed coordinate system . . . . . . . . .  13
  3212.                   ring . . . . . . . . . . . . . . . . . . . . . .  38
  3213.                   samples. . . . . . . . . . . . . . . . . . . . .  21
  3214.                   solid texture. . . . . . . . . . . . . . . . . .  33
  3215.                   sphere . . . . . . . . . . . . . . . . . . . . .  37
  3216.                   spherical pattern. . . . . . . . . . . . . . . .  33
  3217.                   start. . . . . . . . . . . . . . . . . . . . . .  18
  3218.                   statistics . . . . . . . . . . . . . . . . . . .   7
  3219.                   stop . . . . . . . . . . . . . . . . . . . . . .  18
  3220.                   studio . . . . . . . . . . . . . . . . . . . . .  17
  3221.                   surfaces . . . . . . . . . . . . . . . . . . . .  28
  3222.                   threshold. . . . . . . . . . . . . . . . . . . .  20
  3223.                   transform. . . . . . . . . . . . . . . . . . . .  42
  3224.                   transform_pop. . . . . . . . . . . . . . . . . .  42
  3225.                   triangular patch . . . . . . . . . . . . . . . .  40
  3226.               turbulence . . . . . . . . . . . . . . . . .  32, 34
  3227.                   up . . . . . . . . . . . . . . . . . . . . . . .  17
  3228.                   up.exe . . . . . . . . . . . . . . . . . . . . .  51
  3229.                   viewpoint. . . . . . . . . . . . . . . . . . . .  17
  3230.                   wave bump map. . . . . . . . . . . . . . . . . .  31
  3231.               xyzzy.v. . . . . . . . . . . . . . . . . . . . 5, 15
  3232.