Home
Authors
FAQ
Contents
Bibliography
Reviews
Errata
Downloads
Gallery
Mailing Lists
Forums
Bug Tracking
Links
Frequently Asked Questions
General
Compiling the system (Windows)
Compiling the system (Linux/OSX)
Making your way around the system
Extending the system
Using the system
General
Q.How many classes have used the book previously? At which universities?
A.Thus far, the book has been used in nearly twenty different graphics courses at ten different universities. Most of these courses have been advanced undergraduate or graduate courses focusing on rendering. The links page has links to the homepages of many of these courses.
Compiling the system (Windows)
Q.I am getting an error in "Yacc'ing pbrtparse" while building the first project 'core'. What's going on?
A.You need to install Cygwin flex and bison, as described in the readme file in on the CD-ROM. Also, if you install it in a location other than the standard C:\cygwin, you need to modify the build information in the yacc and lex files. To do this, in VS2003 Solution Explorer, expand the core project icon, and its "Parser Filed" folder. Right click on each of the two files, pbrtlex.l and pbrtparse.y and change C:\cygwin to the location where you installed Cygwin.
Q.I am seeing an error about not being able to find unistd.h when compiling core/pbrtlex.cpp. What should I do?
A.Either upgrade to the latest version of cygwin, or create an empty file named "unistd.h" in the core/ directory.
Compiling the system (Linux/OSX)
Q.When building pbrt under linux, I get link errors from undefined symbols in some libraries located in OpenEXR/lib-linux/. What's going on?
A.These library binaries were built on RedHat 9.0 Linux, and there were some major compiler changes between RedHat 8 and 9. If you are using an older version of Linux or a different flavor, please download and build the OpenEXR libraries on your system. This will ensure that all the symbol definitions are consistent and eliminate linking problems. The OpenEXR source is available from www.openexr.com.
Q.I built the pbrt binaries from the source code and now when I run them, the system is incredibly slow. How come the prebuilt binaries are so much faster?
A.Under linux/OSX, the pbrt makefiles are set up to build the system without optimization and with debugging symbols by default. To build the system with optimization, do a 'make clean' and then rebuilt the system using your favorite compiler optimization flags, e.g. 'make OPT=-O2'.
Making your way around the system
Q.I am getting a run-time warning about infinite or not-a-number (NaN) values returned for image samples. What's going on?
A.The Scene::Render() method checks the radiance values returned by the integrators to see if they look like they may indicate errors elsewhere in the system. If such a value is found, it prints a warning message. The source of such errors is worth tracking down, as they are indicative of a bug in the system.
There are a few common scenarios for how these values can occur. Most commonly, a Shape returns infinite or NaN values in the DifferentialGeometry at the ray intersection point. These values then propagate through the computations by the integrators and back into the returned values.
Another common case is the Monte Carlo sampling routines. While we believe that the current implementation should never compute bogus values like these, if you're adding a new light source or BRDF, it's possible that errors in their sampling routines can lead to these values.
Another candidate can be the camera rays (most likely if you're adding a new camera plugin). Make sure that the origin, direction and ray weight are all reasonable.
One good way to debug these sorts of errors is to see what value the cameraRaysTraced variable in Scene::Render() has for the ray that take on an infinite or NaN value. Then, set a conditional breakpoint at the top of the main while loop of that method that hits only when cameraRaysTraced has that value. Then, carefully step through all of the computations for that ray until the source of the error is found.
Extending the system
Q.How can a Camera implementation indicate that no ray should be traced for the given Sample value passed to its GenerateRay() method?
A.For some Cameras, not all rays will make it through the lens system. (For example, for a camera that models a realistic lens system, some rays will be blocked by elements inside the lens system.) In order to prevent rays from being traced for these samples, the camera just needs to return a value of zero for the ray's weight. The main rendering loop skips rays with a weight of zero.
Q.How do I add a new BRDF to the system?
A.You don't. BRDFs aren't plugins. Instances of the Material class create BRDFs and add them to the BSDFs they return. So you should implement a new Material class and include the definition of the new BRDF inside the Material's file. Then create a new instance of the BRDF in the Material::GetBSDF() method, add it to the BSDF, and you're done.
Q.How come the range of pixel values that the Sampler needs to compute sample values for is more than (0,0)->(xResolution,yResolution)?
A.There are two factors that affect the range of pixels for which Samplers need to generate samples: the crop window, if any, and the pixel reconstruction filter's extent. The first of these can reduce the number of pixels that need samples generated for them, and the second can increase it. In particular, it is often necessary to generate samples for pixels with negative coordinates and pixels with coordinates slightly greater than x/yResolution. (See discussion on pp. 376-377.)
Q.How do I debug the system? I'm not able to set a breakpoint in any of the plugins.
A.Unfortunately, debugging pbrt is made slightly more difficult by its plugin architecture. Because it doesn't load the appropriate plugins until the scene file is parsed, it's not possible to set breakpoints inside the plugins with many debuggers. (gdb version 6.1 has a new feature, "pending breakpoint support" which looks like it solves this problem.)
If you're trying to debug a Shape implementation, for example, you can load the executable and put a breakpoint in MakeShape(). Then step OVER the code that loads the plugin. Then you can put breakpoints in your code.
You can also set breakpoints in pbrt's API methods (e.g. pbrtLightSource() to debug light source creation).
If you're trying to debug something during rendering, not scene creation, the best thing to do is set a breakpoint in Scene::Render(), and then step into the parts of the code that you're trying to debug. At that point, you should be able to set other breakpoints in plugins.
Sometimes gdb doesn't want to set a breakpoint in Scene::Render() (there doesn't seem to be much regularity to this.) In that case, set a breakpoint in main(), then once that breaks then try setting the Scene::Render() breakpoint; it should work then.
Another possibility is to add code like:
volatile int gee_i_wish_i_didnt_have_to_do_this = 1;
while (gee_i_wish_i_didnt_have_to_do_this) {}
so your code goes into an infinite loop. Then you can attach to the
running process the debugger, break it, set the variable to zero, and go on
your merry way.
On Windows, you can put a call to DebugBreak() where you want to start debugging---this will drop you into the debugger at any time while the program is running.
printfs. Lots of printfs.
Using the system
Q.How do I convert scenes to pbrt's file format?
A.The pbrt CD-ROM includes source code to a
converter from 3ds format to pbrt's. This
converter depends on the third-party lib3ds library. (Note that 3ds
is
Q.How come if I convert a TIFF image to EXR format and then back to TIFF (using tifftoexr and then exrtotiff), the resulting image is different than the original TIFF?
A.Gamma correction. tifftoexr doesn't do any gamma correction under the assumption that the image being converted is an image map to be used for rendering. However, exrtotiff assumes that the image being converted is output from the renderer to be displayed on the screen, so it does apply gamma correction by default. To turn this off, use the -g 1 command line option.
Q.How do I convert HDRI images to a format that pbrt can understand?
A.There are two steps to convert high-dynamic range images for use in pbrt. First, the image must be converted to "latitude-longitude" format if it is currently stored as a cube map, light probe, etc. HDRShop handles these conversions well.
Second, it must be converted to EXR file format. The easiest way to do this is to use HDRShop to save the image as a TIFF and then use tifftoexr to convert it.
Q.Under linux, I'm seeing the error message pbrt: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory. when I try to use the pre-built binaries from the CD. What's going wrong?
A.The pbrt binaries on the CD were built using the 3.2 version of the gcc compiler. Unfortunately, the binaries dynamically link to the C++ standard library (in libstdc++), so that they depend on the same version of libsttc++ being available on your system as there is on our system. If libstdc++.so.5 is not installed on your system, the best solution may be to rebuild the binaries from the source code using the version of the compiler and the standard library that is installed.
Q.What are good ways to make movies from a sequence of images rendered by pbrt?
A.Some people have reported success using the mencoder encoder, which is a part of the mplayer package.
© Copyright 2004-2007 Matt Pharr & Greg Humphreys. All rights reserved.