Real-Time Rendering Corrigenda for 2nd print

Addenda

• Change figure 7.13: remove the zeros in the z-buffer (as they may indicate that the z-value is cleared there), and replace with something else. Also, add in the text that the Z-buffer is cleared with the "far"-value before rendering starts. (thanks to Norman Lin)
• Page 372, in the comparison of single, double, and triple buffering, add (and mix & clear up) something like: "All buffering schemes have different latencies: single buffering has none (though it is subject to tearing), double buffering have at least one frame of latency, while triple buffering have at least two frames of latency". (thanks to Ben Watson).
• To be added to Chapter 12 on page 374, as a separate section between 12.1.6 and 12.1.7: "The T-buffer is like a parallel accumulation buffer, consisting of a set of 4 or 8 image and Z buffers (or more, memory permitting), each of which can be rendered to simultaneously. There is a mask which determines where a triangle gets sent, i.e. you can send it to one or more buffers at the same time, as desired. On the back-end is some video logic which combines the set of buffers to display a single, averaged image. So, for motion blur and depth of field you send down each triangle a number of times, changing the mask as you change the position or view. Triangles which do not need these effects can be sent just once, to all buffers. The T-buffer's real strength is for anti-aliasing. It jitters the triangle in screen space per buffer, e.g. the first buffer has a jitter of say (0,0), the second buffer (0.5,0), third (0.5,0.5), fourth (0,0.5) [footnote: Better is to sample with something like (0,0.25),(0.5,0),(0.75,0.5),(0.25,0.75) or similar rotated grid, which gives more vertical and horizontal resolution and so gives more levels of antialiasing for nearly vertical or horizontal edges, which usually look the worst]. So you can send a single triangle and have it sent in parallel, at slightly different offsets, to the set of buffers. Combining on the back end gives a fairly good antialiased image (there are still problems from doing regular sampling, box filtering, and not doing gamma correction). An advantage of this approach is that anti-aliasing can be done by default for old games without needing any programming changes; it is just a matter of setting the driver to be in anti-aliasing mode."
• For reference [202] by Kempf and Hartman, add URL: http://techpubs.sgi.com/library/tpl/cgi-bin/download.cgi?coll=0650&db=bks&docnumber=007-2392-002

Significant errors

• Page 47, Equation 3.47, the middle row should say "m_{02}-m_{20}" instead of "m_{20}-m_{02}". Also, in Equation 3.49 the same change should be made. (thanks to Adam Batters)
• Page 131, first sentence should rather be: "The remaining two coordinates are divided by the absolute value of the largest magnitude coordinate, i.e., 0.84. They now range from -1 to 1, and are simply remapped to [0,1] in order to compute the texture coordinates (e.g., the coordinates (-0.2,0.5) are mapped to ((-0.2/0.84+1)/2, (0.5/0.84+1)/2) \approx (0.38,0.80)" (thanks to Tommy Fortes)
• Page 301, in the pseudocode, line 15 should actually be an "else if" not an "if" and should be indented as line 7.
• Page 325, in the algorithm for testing whether two k-DOPs overlap, we cannot guarantee that they overlap if all slabs overlap (however, it is quite likely). According to the separating axis theorem, one also has to test axes formed from the cross products of an edge from each of the k-DOPs.
• Page 351, figure 11.3, according to the separating axis theorem, it is sufficient to find one axis of separation to declare two objects as not overlapping, therefore this illustration is wrong. The reason is that the figure in the middle shows a separating axis and that the test would end there. The figure should be redrawn such that there would be no separating axis (not in the middle and not in the right figure). (thanks to Jacob Ström).
• Reference [28] by Barkans is used as the main reference for anisotropic filtering of textures. The following reference is more appropriate and earlier:
  Andreas Schilling and Günter Knittel and Wolfgang Strasser, ``Texram: A Smart Memory for Texturing'', IEEE Computer Graphics & Applications, 16 (3), pp. 32-41 (May 1996). (thanks to Wolfgang Strasser)

Minor syntax errors

• Page 49, Equation 3.55, replace "h", "p", and "r" with "h/2", "p/2", and "r/2". (thanks to Alex Linde)
• Page 50, Equation 3.56, the order of the quaternions should be "roll", "pitch", and "head" (not hpr). (thanks to Alex Linde)
• Page 350, in "Choice of Bounding Volume", first paragraph, at the end says "... due to one of the 16 axis tests.". It should be "... due to one of the 15 axis tests." (thanks to Bill Budge)

Very minor errors