home *** CD-ROM | disk | FTP | other *** search
/ Inside Multimedia 1995 December / IMM1295.ISO / share / grafik / povhelp / qsandas.hlp < prev    next >
Text File  |  1994-07-07  |  11KB  |  186 lines
  1.  RENDERING
  2.  *********
  3.  
  4.  Question:
  5.     I get a floating point error on certain pictures.  What's wrong?
  6.  Answer:
  7.     The ray tracer performs many thousands of floating point operations when
  8.  tracing a scene.  If checks were added to each one for overflow or under-
  9.  flow, the program would be much slower.  If you get this problem, first look
  10.  through your scene file to make sure you're not doing something like:
  11.        a)   Scaling something by 0 in any dimension.  Example: scale <34, 2,
  12.             0> will generate a warning.
  13.        b)   Making the look_at point the same as the location in the camera.
  14.        c)   Looking straight down at the look_at point.
  15.        d)   Defining triangles with two points the same or nearly the same.
  16.        e)   Using a roughness value of zero (0).
  17.  
  18.     If it doesn't seem to be one of these problems, please let us know.  If
  19.  you do have such troubles, you can try to isolate the problem in the input
  20.  scene file by commenting out objects or groups of objects until you narrow
  21.  it down to a particular section that fails.  Then try commenting out the
  22.  individual characteristics of the offending object.
  23.  
  24.  Question:
  25.     Are planes 2D objects or are they 3D but infinitely thin?
  26.  Answer:
  27.     Neither.  Planes are 3D objects that divide the world into two half-
  28.  spaces.  The space in the direction of the surface normal is considered out-
  29.  side and the other space is inside.  In other words, planes are 3D objects
  30.  that are infinitely thick.  For the plane, plane { y, 0 }, every point with
  31.  a positive Y value is outside and every point with a negative Y value is
  32.  inside.
  33.  
  34.  Question:
  35.     I'd like to go through the program and hand-optimize the assembly code in
  36.  places to make it faster.  What should I optimize?
  37.  Answer:
  38.     Don't bother.  With hand optimization, you'd spend a lot of time to get
  39.  perhaps a 5-10% speed improvement at the cost of total loss of portability.
  40.  If you use a better ray-surface intersection algorithm, you should be able
  41.  to get an order of magnitude or more impro-vement.  Check out some books and
  42.  papers on ray tracing for useful techniques.  Specifically, check out 'Spa-
  43.  tial Subdivision' and 'Ray Coherence' techniques.
  44.  
  45.  Question:
  46.     Objects on the edges of the screen seem to be distorted.  Why?
  47.  Answer:
  48.     If the direction vector of the camera is not very long, you may get dis-
  49.  tortion at the edges of the screen.  Try moving the location back and rai-
  50.  sing the value of the direction vector.
  51.  
  52.  Question:
  53.     How do you position planar image maps without a lot of trial and error?
  54.  Answer:
  55.     By default, images will be mapped onto the range 0,0 to 1,1 in the appro-
  56.  priate plane.  You should be able to translate, rotate, and scale the image
  57.  from there.
  58.  
  59.  Question:
  60.     How do you calculate the surface normals for smooth triangles?
  61.  Answer:
  62.     There are two ways of getting another program to calculate them for you.
  63.  There are now several utilities to help with this:
  64.        1)   Depending on the type of input to the program, you may be able to
  65.             calculate the surface normals directly.  For example, if you have
  66.             a program that converts B-Spline or Bezier Spline surfaces into
  67.             POV-Ray format files, you can calculate the surface normals from
  68.             the surface equations.
  69.        2)   If your original data was a polygon or triangle mesh, then it's
  70.             not quite so simple.  You have to first calculate the surface
  71.             normals of all the triangles.  This is easy to do; you just use
  72.             the vector cross-product of two sides (make sure you get the vec-
  73.             tors in the right order).  Then, for every vertex, you average
  74.             the surface normals of the triangles that meet at that vertex.
  75.             These are the normals you use for smooth triangles.  Look for the
  76.             utilities such as RAW2POV.  RAW2POV has an excellent bounding
  77.              scheme and the ability to specify a smoothing threshold.
  78.  
  79.  Question:
  80.     When I render parts of a picture on different systems, the textures don't
  81.  match when I put them together.  Why?
  82.  Answer:
  83.     The appearance of a texture depends on the particular random number ge-
  84.  nerator used on your system.  POV-Ray seeds the random number generator with
  85.  a fixed value when it starts, so the textures will be consistent from one
  86.  run to another or from one frame to another so long as you use the same ex-
  87.  ecutables.  Once you change executables, you will likely change the random
  88.  number generator and, hence, the appearance of the texture.  There is an
  89.  example of a standard ANSI random number generator provided in IBM.C, in-
  90.  clude it in your machine-specific code if you are having consistency pro-
  91.  blems.
  92.  
  93.  Question:
  94.     I created an object that passes through its bounding volume.  At times, I
  95.  can see the parts of the object that are outside the bounding volume.  Why
  96.  does this happen?
  97.  Answer:
  98.     Bounding volumes are not designed to change the shape of the object. They
  99.  are strictly a realtime improvement feature.  The ray tracer trusts you when
  100.  you say that the object is enclosed by a bounding volume.  The way it uses
  101.  bounding volumes is very simple: If the ray hits the bounding volume (or the
  102.  ray's origin is inside the bounding volume), when the object is tested
  103.  against that ray.  Otherwise, we ignore the object.  If the object extends
  104.  beyond the bounding volume, anything goes.  The results are undefined.  It's
  105.  quite possible that you could see the object outside the bounding volume and
  106.  it's also possible that it could be invisible.  It all depends on the geome-
  107.  try of the scene.  If you want this effect use a clipped_by volume instead
  108.  of bounded_by or use clipped_by { bounded_by } if you wish to clip and bound
  109.  with the same object.
  110.  
  111.  
  112.  SYSTEM
  113.  ******
  114.  
  115.  Question:
  116.     Does the 'virtual memory manager' in POV run only if no existing hard
  117.  disk cache (like SMARTDRIVE) is detected?
  118.  Answer:
  119.     No, the virtual memory manager is NOT a disk cache.  It provides paged
  120.  memory services to POV-Ray in much the same way that a Mainframe or Mini-
  121.  Computer may use their hard disk drives as 'memory'.  This 'memory' appears
  122.  to the program to be actual RAM available for it's use.  It is NOT a 'swap
  123.  file' in the conventional sense.  (For this reason it's best that the file
  124.  used should be located on a drive that DOES NOT USE DISK COMPRESSION PRO-
  125.  GRAMS such as STACKER or SUPERSTOR!)  ICB allows this (plus physical RAM) to
  126.  go to a total of 3.75 Gigabytes....  if you have a big enough hard drive.
  127.  Disk caching will have little effect on the performance of POV-Ray.  POV-Ray
  128.  will 'tolerate' it's being present, if new enough versions of the programs
  129.  are used.  A MUCH better way to boost performance is to use the image buf-
  130.  fering built into POV-Ray with the +bxxx commandline switch.  Since POV-Ray
  131.  must switch out of protected mode to use the BIOS disk service routines, it
  132.  takes a performance hit for every line as it is written to disk.  Also,
  133.  since POV-Ray cares little about memory usage a buffer of 500K is not unrea-
  134.  sonable in a machine with at least 4 Megs of RAM.  I've done a couple timing
  135.  tests and found that trace time can be reduced by as much as 30% with a 500K
  136.  or larger buffer.
  137.  
  138.  Question:
  139.     What is the minimum amount of conventional DOS memory needed to run POV?  Does freeing up conventional memory above this minimum improve performance?
  140.  Answer:
  141.     No minimums are given in the ICB docs, I imagine all that is required is
  142.  enough for the loader program to execute since it is (basically) a real mode
  143.  program.  Be aware however that machines with large amounts of memory taken
  144.  up by drivers, TSR's etc. are MORE LIKELY to have some kind of problem with
  145.  conflicts between POV-Ray and those drivers.  (Simply because they are
  146.  loaded and the vast differences in the way the CPU it's self is used between
  147.  real mode and the 32bit protected mode.)  Performance is not effected by how
  148.  much real mode memory is available, POV-Ray runs almost completely in the
  149.  area BEYOND the real mode 1meg boundary.
  150.  
  151.  Question:
  152.     I assume that if POV-Ray is a protected mode application, you should give
  153.  it as much extended memory as possible.  How much can it use?
  154.  Answer:
  155.     Yes, defiantly.  The more the better since, as far as POV-Ray is concer-
  156.  ned, this IS the memory.  That is where the program actually runs.  As pre-
  157.  viously described, POV-Ray (ICB's limits) can use 64 megabytes of physical
  158.  RAM (the IC's installed in the machine) and additional hard disk space to
  159.  total 3.75 Gigabytes of paged virtual memory.  'Shortcuts' taken by some
  160.  hardware manufacturers may limit what is 'really' available to the program,
  161.  even if more is actually installed in the machine.  Generally you are pretty
  162.  safe in assuming that 16 megabytes of RAM and 32 megabytes of disk space
  163.  will be usable/available in ANY IBM compatible 386/486 PC with an ISA bus.
  164.  48 megabytes of VM should be plenty for any rendering that will be completed
  165.  in under a century....  Also, I have gotten some messages (2 to be exact)
  166.  from people that have been unable to get the program to run in a machine
  167.  with only 2 megs of RAM installed.  Since the first meg is 'reserved' for
  168.  real mode use this leaves 1 meg for POV to knock around in.  POV is actually
  169.  a pretty big program it's self these days, and getting bigger.  4 megs gives
  170.  it some 'breathing space'.
  171.  
  172.  Question:
  173.     What options will allow the program to run as fast as it can?
  174.  Answer:
  175.     Generally the command line options that have the most effect are the
  176.  image buffering (+bxxx) and the keyboard abort (+x).  The image buffering
  177.  can dramatically reduce rendering times.  A setting of +b512 on a machine
  178.  with 4+ megs of RAM is a good compromise between the buffer & how much RAM
  179.  is "sacrificed" to the buffer.  For instance a 512K buffer will limit an
  180.  800x600 image to just 3 disk writes during the image generation instead of
  181.  600.  Depending on the environment, the keyboard abort option (+x) can slow
  182.  things quite a bit too.  It is most noticeable in multitasking environments
  183.  since the keyboard is constantly polled to check for the occurrence of any
  184.  keypress.  Disabling the display option can give a slight improvement in
  185.  rendering speed but it is generally not a very significant improvement.
  186.