home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ARM Club 3
/
TheARMClub_PDCD3.iso
/
hensa
/
graphics
/
ftpov_2
/
Authors
/
FTPOV21
< prev
next >
Wrap
Text File
|
1996-02-17
|
13KB
|
311 lines
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
by
Dieter Bayer
e-mail: dieter@cip.e-technik.uni-erlangen.de
INTRODUCTION
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
improved.
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
distribution.
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?).
NEW OPTIONS
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
finite.
+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
red).
-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.
PROBLEMS, DRAWBACKS, THINGS TO KNOW
- 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
documentation).
- 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.
CHANGES MADE TO POV-RAY MODULES
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
calculation.
POVRAY.C Added calls to new modules and code for new
options.
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
comments.
FTPOV-RAY'S STATISTIC
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
counted.
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.
WHERE TO GET THE SOURCE CODE FOR FTPOV-RAY (AND POV-RAY 2.2)?
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
(134.117.1.1). There you'll also find most of the scenes
used in the benchmark tests.
HOW TO COMPILE THE SOURCE CODE?
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
FRAME.H!).
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.
REFERENCES
The following articles gave me the ideas for the new
algorithms:
- 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
HISTORY
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
time.
- 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
on/off.
- 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
on/off.
- Added option to turn 'previewing' on/off.
- Changed bounding box calculation of CSG
intersections.
- Changed bounding box structure to a more suitable
form.
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
understanding).
- Fixed some bugs.
- Sped up creation of vista and light buffer.
- Reduced memory used by the light buffer.