Graphics Reference
In-Depth Information
ance in proportion to the number of primary rays. Probably the part of your code
shown in Listing 32.20 has L = estimateTotalRadiance(...) rather than L+=
estimateTotalRadiance(...) . That accounts for the presence of the aliasing arti-
facts: You're still working with only one sample per pixel!
Listing 32.20: Averaging several primary rays.
1
2
3
4
5
for (int i = 0; i < m_primaryRaysPerPixel; i++) {
const Ray r = defaultCamera.worldRay(x + rnd.uniform(), y + rnd.uniform(),..)
L += estimateTotalRadiance(r, 0);
}
m_currentImage->set(x, y, L / m_primaryRaysPerPixel);
Suppose, on the other hand, that increasing the number of primary samples
causes the image to grow brighter . Then perhaps you're accumulating radiance,
but failing to divide by the number of primary rays.
Now suppose that your objects mostly look good, but one sphere seems to
be missing its left third—you can see right through where that part of the sphere
should be. What could be wrong? Well, that's a failure to correctly compute the
intersection of a ray with the world, so it's got to be a problem with the bounding
volume hierarchy (BVH) if you're using one. The fact that it looks as if the sphere
was chopped off by a plane suggests that some bounding-plane test is failing. Per-
haps switching to a different BVH will get you the correct results, and thus help
you diagnose the problem in the BVH code. By the way, if some plane has just
a single line of pixels that you can see through (or perhaps a line where you see
through just a few of the pixels), it suggests a failure of a floating-point compari-
son: Perhaps one side of a dividing plane is using a less-than test while the other is
using a greater-than test, and the few pixels where the test reveals equality aren't
handled by either side of the plane (see Figure 32.16).
Figure 32.16: Floating-point
comparison failure in BVH.
Most Monte Carlo rendering approaches produce high-variance results when
you have relatively few samples per pixel. But if you render a Cornell box, for
instance, then a typical secondary ray will hit one of the sides of the box, all of
which are of comparable brightness. Sure, a ray could go into one of the dark
corners, and some rays will come out of the front of the box into empty space. But
in general, if there are a few secondary rays per pixel, the resultant appearance
should be fairly smooth. If you find yourself confronting a “speckled” rendering
like the one shown in Figure 32.17 (produced with one primary ray per pixel)
you're probably confronting a visibility problem. For contrast, Figure 32.18 shows
the same rendering with the visibility problem fixed; there's still lots of noise from
the stochastic nature of the path tracer, but no really dark pixels.
Figure 32.17: Speckles in a ren-
dering.
The path for diagnosis is relatively simple. If you eliminate all but direct light-
ing and still have speckles, then some rays from the hit point to the area-light point
must be failing their visibility test. There are two possibilities. The first is that per-
haps the points generated on the area light are actually not visible. If you've made
a small square hole in the ceiling and placed a large square light slightly above
it, then many random light points won't be visible from the interior. This is just a
modeling mistake. On the other hand, perhaps the light-sampling code has a bug,
and the light points being generated do not actually lie on the light itself. The other
possibility is that the hit point and light point really are not visible from each other
because of a failure to bump one or both. Figure 32.17 was generated by removing
the bumpedRay calls in the path tracer, for instance. The failure of an unbumped
Figure 32.18: Noise in a render-
ing.
 
 
Search WWH ::




Custom Search