 RENDERING
 *********

 Question:
    I get a floating point error on certain pictures.  What's wrong?
 Answer:
    The ray tracer performs many thousands of floating point operations when
 tracing a scene.  If checks were added to each one for overflow or under-
 flow, the program would be much slower.  If you get this problem, first look
 through your scene file to make sure you're not doing something like:
       a)   Scaling something by 0 in any dimension.  Example: scale <34, 2,
            0> will generate a warning.
       b)   Making the look_at point the same as the location in the camera.
       c)   Looking straight down at the look_at point.
       d)   Defining triangles with two points the same or nearly the same.
       e)   Using a roughness value of zero (0).

    If it doesn't seem to be one of these problems, please let us know.  If
 you do have such troubles, you can try to isolate the problem in the input
 scene file by commenting out objects or groups of objects until you narrow
 it down to a particular section that fails.  Then try commenting out the
 individual characteristics of the offending object.

 Question:
    Are planes 2D objects or are they 3D but infinitely thin?
 Answer:
    Neither.  Planes are 3D objects that divide the world into two half-
 spaces.  The space in the direction of the surface normal is considered out-
 side and the other space is inside.  In other words, planes are 3D objects
 that are infinitely thick.  For the plane, plane { y, 0 }, every point with
 a positive Y value is outside and every point with a negative Y value is
 inside.

 Question:
    I'd like to go through the program and hand-optimize the assembly code in
 places to make it faster.  What should I optimize?
 Answer:
    Don't bother.  With hand optimization, you'd spend a lot of time to get
 perhaps a 5-10% speed improvement at the cost of total loss of portability.
 If you use a better ray-surface intersection algorithm, you should be able
 to get an order of magnitude or more impro-vement.  Check out some books and
 papers on ray tracing for useful techniques.  Specifically, check out 'Spa-
 tial Subdivision' and 'Ray Coherence' techniques.

 Question:
    Objects on the edges of the screen seem to be distorted.  Why?
 Answer:
    If the direction vector of the camera is not very long, you may get dis-
 tortion at the edges of the screen.  Try moving the location back and rai-
 sing the value of the direction vector.

 Question:
    How do you position planar image maps without a lot of trial and error?
 Answer:
    By default, images will be mapped onto the range 0,0 to 1,1 in the appro-
 priate plane.  You should be able to translate, rotate, and scale the image
 from there.

 Question:
    How do you calculate the surface normals for smooth triangles?
 Answer:
    There are two ways of getting another program to calculate them for you.
 There are now several utilities to help with this:
       1)   Depending on the type of input to the program, you may be able to
            calculate the surface normals directly.  For example, if you have
            a program that converts B-Spline or Bezier Spline surfaces into
            POV-Ray format files, you can calculate the surface normals from
            the surface equations.
       2)   If your original data was a polygon or triangle mesh, then it's
            not quite so simple.  You have to first calculate the surface
            normals of all the triangles.  This is easy to do; you just use
            the vector cross-product of two sides (make sure you get the vec-
            tors in the right order).  Then, for every vertex, you average
            the surface normals of the triangles that meet at that vertex.
            These are the normals you use for smooth triangles.  Look for the
            utilities such as RAW2POV.  RAW2POV has an excellent bounding
             scheme and the ability to specify a smoothing threshold.

 Question:
    When I render parts of a picture on different systems, the textures don't
 match when I put them together.  Why?
 Answer:
    The appearance of a texture depends on the particular random number ge-
 nerator used on your system.  POV-Ray seeds the random number generator with
 a fixed value when it starts, so the textures will be consistent from one
 run to another or from one frame to another so long as you use the same ex-
 ecutables.  Once you change executables, you will likely change the random
 number generator and, hence, the appearance of the texture.  There is an
 example of a standard ANSI random number generator provided in IBM.C, in-
 clude it in your machine-specific code if you are having consistency pro-
 blems.

 Question:
    I created an object that passes through its bounding volume.  At times, I
 can see the parts of the object that are outside the bounding volume.  Why
 does this happen?
 Answer:
    Bounding volumes are not designed to change the shape of the object. They
 are strictly a realtime improvement feature.  The ray tracer trusts you when
 you say that the object is enclosed by a bounding volume.  The way it uses
 bounding volumes is very simple: If the ray hits the bounding volume (or the
 ray's origin is inside the bounding volume), when the object is tested
 against that ray.  Otherwise, we ignore the object.  If the object extends
 beyond the bounding volume, anything goes.  The results are undefined.  It's
 quite possible that you could see the object outside the bounding volume and
 it's also possible that it could be invisible.  It all depends on the geome-
 try of the scene.  If you want this effect use a clipped_by volume instead
 of bounded_by or use clipped_by { bounded_by } if you wish to clip and bound
 with the same object.


 SYSTEM
 ******

 Question:
    Does the 'virtual memory manager' in POV run only if no existing hard
 disk cache (like SMARTDRIVE) is detected?
 Answer:
    No, the virtual memory manager is NOT a disk cache.  It provides paged
 memory services to POV-Ray in much the same way that a Mainframe or Mini-
 Computer may use their hard disk drives as 'memory'.  This 'memory' appears
 to the program to be actual RAM available for it's use.  It is NOT a 'swap
 file' in the conventional sense.  (For this reason it's best that the file
 used should be located on a drive that DOES NOT USE DISK COMPRESSION PRO-
 GRAMS such as STACKER or SUPERSTOR!)  ICB allows this (plus physical RAM) to
 go to a total of 3.75 Gigabytes....  if you have a big enough hard drive.
 Disk caching will have little effect on the performance of POV-Ray.  POV-Ray
 will 'tolerate' it's being present, if new enough versions of the programs
 are used.  A MUCH better way to boost performance is to use the image buf-
 fering built into POV-Ray with the +bxxx commandline switch.  Since POV-Ray
 must switch out of protected mode to use the BIOS disk service routines, it
 takes a performance hit for every line as it is written to disk.  Also,
 since POV-Ray cares little about memory usage a buffer of 500K is not unrea-
 sonable in a machine with at least 4 Megs of RAM.  I've done a couple timing
 tests and found that trace time can be reduced by as much as 30% with a 500K
 or larger buffer.

 Question:
    What is the minimum amount of conventional DOS memory needed to run POV?  Does freeing up conventional memory above this minimum improve performance?
 Answer:
    No minimums are given in the ICB docs, I imagine all that is required is
 enough for the loader program to execute since it is (basically) a real mode
 program.  Be aware however that machines with large amounts of memory taken
 up by drivers, TSR's etc. are MORE LIKELY to have some kind of problem with
 conflicts between POV-Ray and those drivers.  (Simply because they are
 loaded and the vast differences in the way the CPU it's self is used between
 real mode and the 32bit protected mode.)  Performance is not effected by how
 much real mode memory is available, POV-Ray runs almost completely in the
 area BEYOND the real mode 1meg boundary.

 Question:
    I assume that if POV-Ray is a protected mode application, you should give
 it as much extended memory as possible.  How much can it use?
 Answer:
    Yes, defiantly.  The more the better since, as far as POV-Ray is concer-
 ned, this IS the memory.  That is where the program actually runs.  As pre-
 viously described, POV-Ray (ICB's limits) can use 64 megabytes of physical
 RAM (the IC's installed in the machine) and additional hard disk space to
 total 3.75 Gigabytes of paged virtual memory.  'Shortcuts' taken by some
 hardware manufacturers may limit what is 'really' available to the program,
 even if more is actually installed in the machine.  Generally you are pretty
 safe in assuming that 16 megabytes of RAM and 32 megabytes of disk space
 will be usable/available in ANY IBM compatible 386/486 PC with an ISA bus.
 48 megabytes of VM should be plenty for any rendering that will be completed
 in under a century....  Also, I have gotten some messages (2 to be exact)
 from people that have been unable to get the program to run in a machine
 with only 2 megs of RAM installed.  Since the first meg is 'reserved' for
 real mode use this leaves 1 meg for POV to knock around in.  POV is actually
 a pretty big program it's self these days, and getting bigger.  4 megs gives
 it some 'breathing space'.

 Question:
    What options will allow the program to run as fast as it can?
 Answer:
    Generally the command line options that have the most effect are the
 image buffering (+bxxx) and the keyboard abort (+x).  The image buffering
 can dramatically reduce rendering times.  A setting of +b512 on a machine
 with 4+ megs of RAM is a good compromise between the buffer & how much RAM
 is "sacrificed" to the buffer.  For instance a 512K buffer will limit an
 800x600 image to just 3 disk writes during the image generation instead of
 600.  Depending on the environment, the keyboard abort option (+x) can slow
 things quite a bit too.  It is most noticeable in multitasking environments
 since the keyboard is constantly polled to check for the occurrence of any
 keypress.  Disabling the display option can give a slight improvement in
 rendering speed but it is generally not a very significant improvement.
