Visibility Pre-Processing Based Ray-Tracer

User manual and notes about the project

Writen by : Adi Bar-Lev

Ray-Tracing image of a room


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 :

Introduction:

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:

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.

User Manual:

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.

Examples:

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 :

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).

Ray-Casting:

The ray-tracer supports three types of ray-casting:

Visibilty Options:

The application enables the user to run with four modes which are combined by the two following bits :

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 effect.

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 speed-up).

Remarks:

The Utha teapot with fog parameters

Sources load:

Next are the compressed sources and executables: