i
i
i
i
i
i
i
i
1.7. Designing and Coding Graphics Programs 11
A useful approach is to “set a trap” for the bug. First, make sure your program
is deterministic—run it in a single thread and make sure that all random numbers
are computed from fixed seeds. Then, find out which pixel or triangle is exhibiting
A special debugging mode
that uses fixed random-
number seeds is useful.
the bug and add a statement before the code you suspect is incorrect that will be
executed only for the suspect case. For instance, if you find that pixel (126, 247)
exhibits the bug, then add:
if x = 126 and y = 247 then
print “blarg!”
If you set a breakpoint on the print statement, you can drop into the debugger just
before the pixel you’re interested in is computed. Some debuggers have a “condi-
tional breakpoint” feature that can achieve the same thing without modifying the
code.
In the cases where the program crashes, a traditional debugger is useful for
pinpointing the site of the crash. You should then start backtracking in the pro-
gram, using asserts and recompiles, to find where the program went wrong. These
asserts should be left in the program for potential future bugs you will add. This
again means the traditional step-though process is avoided, because that would
not be adding the valuable asserts to your program.
Data Visualization for Debugging
Often it is hard to understand what your program is doing, because it computes a
lot of intermediate results before it finally goes wrong. The situation is similar to
a scientific experiment that measures a lot of data, and one solution is the same:
make good plots and illustrations for yourself to understand what the data means.
For instance, in a ray tracer you might write code to visualize ray trees so you
I like to format debugging
print statements so that the
output happens to be a
Matlab or Gnuplot script
that makes a helpful plot.
—S.M.
can see what paths contributed to a pixel, or in an image resampling routine you
might make plots that show all the points where samples are being taken from the
input. Time spent writing code to visualize your program’s internal state is also
repaid in a better understanding of its behavior when it comes time to optimize it.
Notes
The discussion of software engineering is influenced by the Effective C++ se-
ries (Meyers, 1995, 1997), the Extreme Programming movement (Beck & Andres,
2004), and (Kernighan & Pike, 1999). The discussion of experimental debugging
is based on discussions with Steve Parker.
There are a number of annual conferences related to computer graphics, in-
cluding ACM SIGGRAPH and SIGGRAPH Asia, Grpahics Interface, the Game
i
i
i
i
i
i
i
i
12 1. Introduction
Developers Conference (GDC), Eurographics, Pacific Graphics, High Perfor-
mance Graphics, the Eurographics Symposium on Rendering, and IEEE VisWeek.
These can be readily found by web searches on their names.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.