② It is possible to use image pyramids and MIP mapping with
images that have non-power-of-two resolutions—the details are explained
by Guthe and Heckbert (2005). Implementing this approach can
save a substantial amount of memory: in the worst case, the resampling that
pbrt’s MIPMap implementation performs can increase memory
requirements by a factor of four. (Consider a texture
that is resampled to be .) Implement this approach in
pbrt, and compare the amount of memory used to store texture data for a
variety of texture-heavy scenes.
② Improve the filtering algorithm used in
the Image::GeneratePyramid() method to initialize the pyramid levels
using the Lanczos filter instead of the box filter. How do the sphere test
images in Figure 10.16 change after your
modifications? Do you see a difference in other scenes that use image
textures?
② Try a few alternative implementations of the statistics
system described in Section B.7 to get a sense of the
performance trade-offs with various approaches. You might try using atomic
operations to update single counters that are shared across threads, or you
might try using a mutex to allow safe updates to shared counters by
multiple threads. Measure the performance compared to pbrt’s current
implementation and discuss possible explanations for your results.
③ Generalize the statistics system (including the per-pixel
statistics) so that it is also available in the GPU rendering path. You
will likely want to pursue an approach based on atomic variables rather
than the thread_local approach that is used for the CPU. Measure
the performance of your implementation and compare to the system before
your changes. Is performance meaningfully affected?