Joshua Zawislak
CS 638 Interactive Graphics 2
Final Paper
Interactive Theatrical Lighting
Overview:
The Theatrical Lighting Design and Inventory Management System was created as a way to allow Lighting designers to easily create a design that can be used by electricians in a theater to properly set up lights. The software has multiple parts that help get to this goal. The GUI driven interface is designed for theatrical lighting and allows quick creation of theater spaces so lighting designers can get to designing lights quicker. The inventory management system allows for the user to quickly know what instruments are available to be used in a design. The main focus of this paper is geared towards the usage of photon maps to allow designers to see light interaction with set objects and other lights. Also the cue editor will allow designers to change levels of instruments to test light interaction of their design in a more realistic setting. The software was written in JAVA to allow for lighting designers to use any computer system to develop lighting designs.
Problem:
In theatrical lighting, a lighting designer is responsible for creating the look and feel of the lights. In normal operation it is hard to visualize how the design will look without actually having everything set up. To setup a fully implemented lighting plot in a theater is a labor intensive and time consuming process. The need for a way to test designs without using up time of labor and time in the theater is apparent.
Goals:
The Theatrical Lighting and Inventory Management System enables lighting designers to create a virtual lighting plot and be able to test the usability of the lighting plot. The goal for the usage of photon maps within this project are to allow the user to quickly be able to view the area the light will affect and also to interactively test the lights at different power levels. The desire for interactive speeds is paramount within this effort to allow for constant design time with no long delays for rendering potential designs that only will be scrapped. A secondary objective is accurate representation, while there are methods to fully render high quality images with multiple light sources they take a long time to create the images. With these concerns in mind the challenges that must be overcome are to take into account multiple directional light sources within large overlapping areas and the ability to change power levels of the light sources at interactive speeds.
Process:
The Theatrical Lighting Design and Inventory Management System uses a GUI driven interface of a top down 2D schematic view of the theater area to position the stage, instruments, set objects, and bars. Using further information provided by popup windows all the data needed to recreate a 3D representation of the theater space is acquired. This information is stored internally within the program and can be outputted to xml files linked to a project file so a user can recall the data at a later time. Photon maps are all stored internally within the program although a method was created for saving photon maps to xml but they are so large files they are not practical to use with the needed number of photons that need to be recorded.
The photo map used to record the lighting intersections is slightly modified to try an achieve the goals of the program. Instead of using the normal 2 pass method of photon map that renders at non interactive speed a one pass method is used. The one pass method uses raytracing to calculate the intersections of light “photons” with the set objects. The major changes to the raytracing algorithm are that no caustics are recorded or calculated because they are not necessary for theatrical lighting and take to long to calculate. Also the number of reflections off set objects are reduced from normal amount used in photon map ray tracing to allow for more data to be gathered from the original light source.
The data recorded within in the photon map has also been modified to accommodate our goals. Firstly a maximum number of photons must be set for memory constraints and photons are spread out equally among each light source. The method is modified a photon stores data representing the point of intersection with a surface, the angle that the light hits at the intersection, the color that the light would be at that point of intersection, and which light source the photon came from.
The information within the photon maps are used in two places within the program. On the main schematic page the photon map can be made visible visible as a straight overlay of photons onto the schematic. This allows for quick checking of which set objects the lights will hit and how much area the light will project upon the stage. In the cue editing view photons are placed in to an image map sorted by which light source it originally came from. This will create an image of the light projection in the x,z plane for each light source. For each pixel in the final image the color value from each image map is added to the final image map with consideration taken for the power level of the light the image map represents. The end result is a good representation of the light interaction with each other and the set objects.
Results:
The usability results are quite good in allowing a lighting designer to visually see where the light are placed and how they interact within the created design. Performance speed is an increase from using a two path method but the quality of the image is not as good as the quality of a two pass photon map method. The speed increase is the major benefit and worth the degradation in image quality. On a 650mhz processor with 256mb RAM running Linux Fedora Core 3 it takes 20 minutes to use the unmodified two pass method to render a scene with two lights sources. A more complex scene with 4 light sources within the Theatrical Lighting Design and Inventory Management System took only 30 seconds to originally calculate the photon maps and takes less then 1 second to overlay the photon map onto the schematic. With the same scene it took 1 minute to calculate the individual light source images and less then 2 seconds to render the scene with changed levels. The change in levels of the light is the most speed increase because with the original two path method with no light source data stored in photons it has to render the entire scene again from scratch if a light source's power level is changed. There are some problems with the current system. Because the amount of light sources can be vast and the area the lights cover can also be large the number of photons that could be necessary to fully cover the area covered by the light source is larger then the system can handle. Since there are not enough photons to go around gaps can be seen in between the intersection points of photons. This could be compensated in the cue editor by calculating each pixel in the individual light source images with consideration to surrounding pixels. Also even though there is a dramatic speedup compared to a photon map using caustics and two passes the speed up could probably be faster with this method if it was not integrated into a JAVA program, but then the systems would not be able to be used across a large number of operating systems.
Images:



3 screen shots of the same scene showing how the interaction between lights can be changed just by editing power level of lights,


2 pictures of the same scene with lights at different levels

two
pictures of the same scene showing the elongation of areas of lights and also
degradation of light areas as they become larger.

An example of how lights can be scene to be affected by set objects also shows degradation of large areas and how overlapping lights are shown in the schematic view.
Examples of XML Data:
Photon Example:
<photon
x="103.80893" y="96.0" z="19.730536"
nx="0.0" ny="0.0" nz="0.0" dx="0.0"
dy="0.0" dz="0.0" power="-1778384656"
r="0.0" g="0.0" b="1.0" light="0"/>
Set Object Example:
<set name="Set0"
description="NULL" id="0" house_id="House_Object"
x="23" y="20" z="600">
<node x="0" y="0"
z="600"/>
<node x="0"
y="10" z="600"/>
<node x="683"
y="12" z="600"/>
<node x="684"
y="5" z="600"/>
</set>
Instrument Example:
<instrument
name="NULL" description="50" bar_id="3"
type="striplight" x="106" y="46"
z="200" inventory_id="50" dimmer_id="0"
aimX="130" aimY="27" aimZ="75"
colorR="1.0" colorG="0.0" colorB="0.0"
radius="50"/>
Citations:
The original photon map program modified within the Theatrical Lighting Design and Inventory Management System and used for software measurements testing. can be found at:
http://sunflow.sourceforge.net/
Research Papers:
Global Illumination Using Photon Maps by Henrik Wann Jensen
Design And Simulation of Opera Lighting and Projection Effects by Julie O Dorsey, Francios X. Silhon, Donald P. Greenberg