Visibility Pre-Processing Based Ray-Tracer
User manual and notes about the project
Writen by : Adi Bar-Lev
This document contains all the information that is needed to understand
this application, and enables the reader to learn how to get and build the
ray-tracer and how to run it.
The document is divided into the following sections :
The Visibility Pre-Processing based Ray-Tracer is an application which is
based on the article "Visibility Testing Toward Improved Ray-Tracing Performance"
by Adi Bar-Lev and Dr. Gershon Elber.
The visibility computation process itself is based on the use of shadow
volumes (SV) which are produced by polygon-to-polygon and light source-to-polygon
occlusion relations in the scene. Each polygon is tested against all the
SVs which were created by each different polygon in the scene (for more
details see the article) and if contained within such SV, it is "invisible"
to the polygon which created that SV. By maintaining an array of visibilities
for each polygon we can speed-up the run-time of the ray-tracing stage.
The application itself has three main stages which do the following:
- Interprets the given scene and runs the visibility pre-processing.
- Builds a Voxel array structure for better acceleration of the Ray-Tracer.
- Runs the combined Ray-Tracing algorithm with the visibility acceleration.
How to build the project:
The project contains the following files:
In order to compile this project you have to add the include files and libraries
of the 'Irit' solid modeler (see IRIT ). If you are using Microsoft Visual C++ you can use the file VisTracer.mdp
(compiled on version 4.2), or the makefile VisTracer.mak in order to build
the project as a command-line application.
Notice : the project will only read Irit file format - you can download
Irit models from the technion from different locations which are shown in Dr. Elber's home page.
The whole application is a command-line application so in order to use it
with a scene you should type all the switches as will described. All the
parameters passed with the switch will be writen as "xxx", where xxx specify
also the type of parameter expected.
- -r "int" : specify the number of row for the picture (default 500).
- -c "int" : specify the number of columns for the picture (default 500).
- -V "float" : the viewing angle of the camera - given inRadians (default
- -O : switch to orthographic camera mode.
- -v "float float float" : the viewer's location coordinate by (x,y,z).
- -d "float float float" : the viewer's look-at coordinate.
- -f "int" : the fineness parameter specified for the Irit Bspline-to-polygons
converter (default 8).
- -S "int" : number of rays per pixel in the screen in random ray casting
mode which is the default (default = 8 rays).
- -U "int" : number of rays per pixel in a uniform ray casting mode. each
pixel gets (int * int) rays.
- -T "char" : threshold to use with the -S parameter. See Ray-Casting for more details.
- -D "int" : the depth of each initial ray - number of bouncing allowed for
each initial ray (default is 3).
- -F "float" : specify a fog threshold between 0 and 10.0 - the larger it
gets, the thicker the fog is.
- -a "char char char" : the ambient light RGB component - should be between
0 to 255.
- -l "filename" : the batch file containing the list of light sources as will
be described in Lights batch file .
- -n "int" : number of voxels per each axis in the voxel array. (default =
- -N "int" : specify the direction of the normals - 1 / 0 for CW / CCW.
- -L "options" : specify the Or options - see Visibility options for more details (default is 0 - no optimization).
- -t "float" : the ratio of optimization for the polygon-to-polygon visibility stage (default is
- -y "float" : the ratio of optimization for the light source-to-polygon visibility stage (default
- -h : a help list for the command line application. Describes each switch
in short terms.
- -P : writes out performances information which are being gathered during
run-time of the Ray-Tracer.
- "VisTracer Scene.dat -f 18 -n 20 -v 1 2.5 7 -d 0 0 0 -V 1.8 -a 80 80 80
-l Lights1.doc -P" : In this example the user runs the file Scene.dat with fineness parameter
set to 18 (in most cases above 10 is good enough) on a voxel array which
is 20x20x20 voxels in dimensions and the viewer is located at (1,2.5,7)
looking at the origin. The viewer's viewing angle is 1.8 radians and the
ambient components are set to RGB = (80,80,80). The lights for this environment
are specified in the file 'Lights1.doc' and we want to view the statistics
and so the '-P' switch is enebled.
- "VisTracer Scene.dat -N 1 -f 18 -v 1 2.5 7 -d 0 0 0 -L 2 -l Lights1.doc -y
4.0 -S 6 -T 10 -D 4 -P" : Here we run the same file with normals by CCW order, and we enable light-to-polygon
visibility algorithm (L 2) with accelaration with threshold 4.0 (-y 4.0).
We allow the use of stochastic ray-sampling with up to 6 rays per pixel
and with threshold 10, and the maximum depth of the rays in the scene is
set to 4.
Light-sources batch file:
The batch file of the light sources is based on a list of lights parameters
- each light has a separate line which must have the following format :
- light_name p_x p_y p_z i_r i_g i_b <new line>
The light_name can be either 'DIRECTIONAL_LIGHT" or "POINT_LIGHT", which
accordingly changes the following three parameters.
The next three parameters are either the light origin for point light source,
or the light direction for a directional light source.
The last three parameters determines the intensity of the light source in
an RGB color standard, and can get be given values between 0.0 and 1.0.
An example for such a batch file is as follows :
POINT_LIGHT 0.1 5 -1.0 0 1 0
DIRECTIONAL_LIGHT 0 -0.2 1.0 0.8 0 0.8
In the example I set two light sources - one is a green point light which
is located at (0.1,5,-1) and the other is a purple directional light which
points at the direction (0,-0.2,1).
The ray-tracer supports three types of ray-casting:
- Uniform cast: At each pixel we cast n*n uniformly spaced rays "toward" each pixel in
the screen, where n is the number of rays specified by the '-U' switch.
- Random cast: At each pixel we cast n rays "toward" random locations within each pixel.
Here n is the number of rays specified by the '-S' switch.
- Stochastic cast: This mode combines both '-S' and '-T' switches. The '-S' specify the maximum
amount of rays to cast towards each pixel in the screen, while the '-T'
specify a threshold between 1 and 255. This threshold is the maximum deviation
allowed for ray shade, i.e. if the shade is within this threshold, the shade
is close enough to the average shade of the pixel so far, and so no more
rays will be cast at this pixel.
The application enables the user to run with four modes which are combined
by the two following bits :
- bit 0 : determined wheter the user wants to use visibility between polygons.
- bit 1 : determined wheter the user wants to use visibility for light sources.
for example : if you specify "-L 1" it means you want to have polygon visibility,
and if you specify "-L 3" it means that you want both polygon visibility
and light sources visibility.
Ratio for visibility optimization:
In order to fully understand the use of this switch one should read this
section. Nevertheless, the basics for this optimization are that the application
can achieve very good optimization without loosing much of the visibility
The optimization between polygons compares the size of each polygon that
creates SV to the size of a polygon which is about to be used as the projected
polygon for the SV, if this size is below the ratio specified, the application
does not try to build SV around this polygon.
The optimization of the light sources is pretty much the same - it compares
the size of each occluding polygon to the size of the polygon which is about
to be tested for occlusion, and if this size is below the ratio calculated
with the user given ratio and using a similar triangles law for the distances,
the polygon is not being tested.
Using these optimization for scenes with large walls / large polygons in
relation with others has proved itself to be very efficient, and improved
the speed immensely (as the scene grows in complexity so does this optimization
- The application takes every given scene and unify it into a standard size
which is containd within a bounding-box which is 20*20*20 unit size in dimensions,
and it is centerd in the axes origin.
- The light-sources are positioned relative to the unified scene, and before
the camera transformation.
- For any questions about the project or the article please contact Adi Bar-Lev
at eMail adi.virtue.co.il !
Next are the compressed sources and executables: