Post by Dieter Bay » Fri, 03 Jun 1994 02:55:49

                         FASTER THAN POV-RAY
                     (at least on most machines)

                             Version 2.1

          A modified, sped-up and unofficial version of the
             Persistence of Vision Ray-Tracer Version 2.2

                             Dieter Bayer
             e-mail: die...@cip.e-technik.uni-erlangen.de


     Faster than  POV-Ray (FTPOV-Ray)  speeds  up  calulation  of
     images by  using some  kind of  direction cubes  for primary
     rays (the  vista buffer)  and shadow rays (the light buffer)
     at the  cost of  additional preprocessing  time and  greater
     memory usage. The bounding slab hierarchy used by POV-Ray is
     projected onto the viewing plane and each point light source
     a priori.  Thus the  number of  ray/slab-tests  is  reduced.
     Furthermore some  modules have  been modified  to  eliminate
     unnecessary calculations  and automatic  bounding  has  been

        The modified  source code  in the archive FTPV21S.ZIP may
     only be  distributed together  with this  text and  the file
     POVLEGAL.DOC that  is part  of the official POV-Ray package.
     To use  the source code you'll need the original POV-Ray 2.2

        WARNING!!! If  you use FTPOV-Ray you'll do it at your own
     risk!  And   don't  forget   that  the  POV-Ray  team  isn't
     responsible for this version.

        If something remains unclear, please drop me a note and I
     will update this file. Any Comments, benchmark tests, ideas,
     bug reports are also welcomed, especially benchmark tests of
     the three different methods (-um?) (Do they make sense?).


     The following new options have been added to POV-Ray to make
     things switchable at demand (they are not used by default).

     +uvb     Use the vista buffer.

     +ulb     Use the light buffer.

     +usf     Split unclipped  CSG unions  if their  children are

     +usi     Split all unclipped CSG unions.

     +ubq     Use automatic bounding for quadrics.

     +upv     Use  'previewing'  (just  draws  object's  bounding
              rectangles; CSG objects are blue, other objects are

     -um1     Method 1: don't use bounding slabs while descending
              the vista/light  buffer tree.  This may  be  faster
              than method 2 for some scenes and/or machines.

     -um2     Method 2:  use bounding  slabs on the leaves (i. e.
              the objects  themselves) of  the vista/light buffer
              tree (default method).

     -um3     Use bounding  slabs on all nodes of the vista/light
              buffer. This  may(???) be faster on machines with a
              fast(!!!) floating point unit.

        If you  use the  vista and/or  light  buffer  you  should
     always specifiy  +ubq and +usf/+usi. And don't forget to use
     the automatic  bounding slabs  (+mb option)  or neither  the
     vista nor  the light  buffer will be used, regardless of the
     specified options. Just play around with the new options and
     see what happens.


     -  Since I  can't guarantee  that FTPOV-Ray works correct in
        all cases  it's a  good idea  to trace  a  scene  at  low
        resolution with  both POV-Ray  and FTPOV-Ray.  If you get
        (nearly) identical images, you can use FTPOV-Ray (keep in
        mind that things like crand and anti-aliasing jitter lead
        to different results every run).

     -  Do NOT  use  bounding  objects  that  do  not  completely
        enclose the bounded objects. Otherwise you will get wrong
        results with  FTPOV-Ray. You  shouldn't even do this with
        POV-Ray, because the results are not predictable (instead
        use clipped_by  and bounded_by, as mentioned in POV-Ray's

     -  FTPOV-Ray  splits  unclipped  unions  even  if  they  are
        bounded (if  they aren't part of an intersection or merge
        object  of course).

     -  The direction  cube  algorithms  and  the  bounding  slab
        technique heavily  depend on  finite objects.  You should
        use them whenever possible.

     -  FTPOV-Ray calculates  a better (but not perfect) bounding
        box around  CSG intersections than POV-Ray does. Thus you
        don't have to bound intersections as long as they contain
        at least  one finite object. Even some intersections that
        weren't boundable  can now  be bounded,  depending on the
        way they  are declared.  Use the normal form for quadrics
        and planes  perpendicular to  the coordinate  axis in the
        object's declaration to get an automatic bound around the
        object. Afterwards  you can  translate, rotate  and scale
        the object as you like.

     -  FTPOV-Ray can  bound some  quadric  shapes  if  they  are
        declared in  their normal  form, i. e. f(x,y,z) = A*x*x +
        B*y*y +  C*z*z +  J. It's  the normal  way to declare the
        quadrics in  this form  and translate,  rotate and  scale
        them afterwards  (just look  at SHAPES.INC).  Ellipsoids,
        spheres and  even clipped cylinders and cones can thus be
        bounded. Ellipsoids  (and I  think  cones  and  cylinders
        also)  declared   as  quadric   surfaces  are  faster  to
        intersect than  scaled spheres  (or the new cone/cylinder
        primitive). And  with the new bounding functions quadrics
        will now respond to automatic bounding in most cases.

     -  The up, right and direction vectors defined in the camera
        statement have  to be  perpendicular to each other (isn't
        this a  bug in  POV-Ray?). If  you want  to be  sure, use
        look_at as the last vector in the camera definition.


     A little  time can  be saved  by removing some of the vector
     macros used.  The code  might be  easier to  read with these
     macros but  they sometimes  waste time  due  to  unnecessary
     memory transfers  (may depend  on the processor and compiler
     used). A  few  modifications  I  have  made  assume  that  a
     floating  point  multiplication  is  (much)  faster  than  a
     division (true for 387/486/Pentium).

     BOUND.C    Made some functions globally.

     CSG.C      Modified computation of CSG's bounding box to get
                a tighter bounding box around intersections.

     LIGHTING.C Removed some unnecessary calculations.

     PARSE.C    Added calls  to the new bounding box function for
                quadrics  and   the  new   plane's  bounding  box

     POVRAY.C   Added calls  to new  modules  and  code  for  new

     QUADRICS.C Added inverted flag to quadrics.

     RENDER.C   Added calls to new functions.

        For further  details look at the source code and read the


     After parsing  the image  description and  preprocessing,  a
     statistic about  the current  image is  printed to  standard
     error ouput  (that's normally  the screen;  if you're  using
     previewing you'll  have to  pipe it into a file or you won't
     be able  to read it). This statistic tells you the following
     details about all objects used in the scene.

     sum      Total number of objects.

     csg      Number of objects used inside a CSG.

     infin    Number of  infinite objects.  These objects  do not
              respond to  automatic bounding an should be avoided
              whenever  possible   (using  bounding  objects  may
              help).  Infinite   objects  used  in  CSG  are  not

     bound    Number of objects used as bounding objects.

     clip     Number of objects used as clipping objects.

     bounded  Number of bounded objects.

     clipped  Number of clipped objects.

        For good  performance  you  should  keep  the  number  of
     infinite objects as small as possible.


     I have  uploaded the  source code and executables for MS-DOS
     and  OS/2   2.x  to   ftp.informatik.uni-oldenburg.de.   The
     archives are:

     FTPV21S.ZIP  Contains the source code for FTPOV-Ray.

     FTPV21MS.ZIP Contains  the   32bit  executable   for  MS-DOS
                  compiled  with   DJGPP  1.11  (GCC  2.5.7).  It
                  requires a  386/387, 486  (no SX!)  or Pentium.
                  There seem to be some problems with DJGPP since
                  some scenes  crashed using the original POV-Ray
                  2.2 source code. Be warned!

     FTPV21OS.ZIP Contains the  32bit  executable  for  OS/2  2.x
                  compiled with  Eberhard Mattes  GCC port called
                  emx (also  runs under  MS-DOS). It  requires  a
                  386/387, 486  (no SX!)  or Pentium  and has  no
                  display capabilities.

        In addition to the source code for FTPOV-Ray you need the
     original  POV-Ray   source  code  that  are  available  over
     Internet  by   anonymous  FTP   from  alfred.ccs.carleton.ca
     ( There  you'll also  find most  of the  scenes
     used in the benchmark tests.


     The source  code for  FTPOV-Ray is compiled in a similar way
     to the  original POV-Ray  source code. You have to make sure
     that the  new files  ADDON?.C are  included in your Makefile
     (they use  ADDON.H), and  the original files are replaced by
     the new ones. To use the new code you'll also have to define
     the flag  'DB_CODE'. You  can use  a compiler switch (e.g. -
     DDB_CODE with  gcc) to  do this  or modify  the file FRAME.H
     (the  line   "#define  DB_CODE"   is  already   included  in

        Besides  the   modifications  and  the  three  new  files
     (ADDON0.C,  ADDON1.C,   ADDON2.C,  ADDON3.C,   ADDON.H)  the
     archive only  contains the  modified files  of  the  POV-Ray
     source code.


     The following  articles  gave  me  the  ideas  for  the  new

     -  The vista projection was taken from:

        A. Hashimoto, T. Akimoto, K. Mase, and Y. Suenaga, "Vista
        Ray-Tracing: High  Speed Ray  Tracing  Using  Perspective
        Projection Image",  New Advances  in  Computer  Graphics,
        Proceedings of  CG International  '89, R. A. Earnshaw, B.
        Wyvill (Eds.), Springer, ..., pp. 549-560

     -  The idea for the light buffer was taken from:

        E. Haines  and D. Greenberg, "The Light Buffer: A Shadow-
        Testing Accelerator",  IEEE CG&A,  Vol. 6,  No. 9,  Sept.
        1986, pp. 6-16


     Version 1.0
         -  First public release.

     Version 2.0
         -  Redesign of the vista buffer and the light buffer.
         -  Fixed some bugs.
         -  Made changes to the readme file.
         -  Made modifications/additions  switchable  at  compile
         -  Removed object and light source limits.
         -  Made  some   changes  in   QUADRICS.C  (inside  test,
            inverted flag).
         -  Fixed problem  with slow  tracing of unmodified scene
            files (like FISH13.POV or IONIC5.POV).
         -  Added options  to turn the vista and the light buffer
         -  Added options to turn union splitting on/off.
         -  Added a  function  for  automatic  bounding  of  most
            quadric shapes.
         -  Added option  to turn automatic bounding for quadrics
         -  Added option to turn 'previewing' on/off.
         -  Changed   bounding    box    calculation    of    CSG
         -  Changed bounding  box structure  to a  more  suitable

     Version 2.1
         -  Added new method which uses bounding boxes around the
            leafs of  the vista/light tree and the priority queue
            to keep number of ray/object-intersections nearly the
            same compared to POV-Ray 2.2.
         -  Changed the recursion used to descend the vista/light
            buffer tree to a queue.
         -  Added option  to choose  in which way the vista/light
            buffer tree is descended.
         -  Switched back  to original bounding structure because
            different (and  worser) hierarchies were created with
            the new  structure (why  this happend  is  beyond  my
         -  Fixed some bugs.
         -  Sped up creation of vista and light buffer.
         -  Reduced memory used by the light buffer.


1. ** [Announcement] UView 2.1 **

CineGraphics announces the release of the UView 2.1 Upgrade.

You can get a free demo of UView 2.1 from our site at:


We are proud to have some of the biggest names in the game development
industry using the software. Some of the games that used UView in
development include Daikatana (Ionstorm), 100% of all texturing in
Ascension (Origin) , portions of Ultima Online (Origin) as well as games
from InterPlay, Lucas Arts, Atari and Midway Games.

Many of the non-game users find texturing using UVs (not planar,
cylinderical or spherical mapping) gives them more control over how and
where the image maps are placed.

Download a demo and see for yourself.

We will be adding testimonials and screen shots from users as well as
tutorials to our web site shortly.

Upgrade Pricing
Upgrades for UView 2.1 are only available directly from CineGraphics.
$89 Intel / $109 Alpha for registered users of UView 2.0 that purchased
before 11/1/98. Registered users that purchased after this date can
receive a FREE upgrade.

Dan Laguardia, Technical Support
To reply, remove "_" from email address

2. Compiling on HP_UX machines

3. Nikon Scan 2.1 on LS-1000?

4. lightwave question for possible new user

5. GNU plotting utilities 2.1 released

6. going to art college?

7. Paint Shop Pro 5 with Animation Shop Beta 2.1 Now Available

8. univbe41.zip

9. *** FS Strata Studio Pro 2.1 ***

10. Astound 2.1 and Windows95

11. FS: Electric Image Animation System 2.1

12. Wright Design 2.0 or 2.1