In reviewing the contents of this chapter, it is clear that there is no algorithm for all situations. From a research perspective, shadow (depth) map papers have been the most abundant in an attempt to automate the correction of shadow artifacts. The current count for the papers are
Planar receivers of shadows 5 Shadow (depth) map 103
Shadow volumes 44
Ray tracing 37
2.7.1
Offline Rendering Trends
In offline rendering situations, the trend is that most turnkey software (such as film and video software including Houdini, Renderman, Maya, Mental Ray, Lightwave, etc., and CAD software including SolidWorks, AutoCAD, TurboCAD, etc.) pro- vide shadow options from both ray tracing and shadow depth maps, and shadow
volumes are rarely offered. Shadow depth maps offer the faster, less memory con- suming (unless out-of-core techniques are applied (see Section 2.5.2)), approxi- mate, and usually aesthetically pleasing quality solution, whereas ray tracing pro- vides the most flexible and exact solutions, usually used when shadow depth maps become troublesome or fail. Also, with platforms supporting high parallelism (on the CPU or GPU) or scenes with many shadow-casting lights (due to less per-light preprocessing or many light optimizations (see Section 2.5.3)), ray tracing is be- coming more affordable.
Shadow depth maps are much more appropriate than shadow volumes in of- fline rendering situations because shadow depth maps allow efficient handling of large data sets, higher quality renderings due to user-input tweaking (and the users’ willingness to tweak parameters), and percentage-closer filtering capabilities to achieve fake soft shadows, which can also mask the straight edges of polygons that shadow volumes cannot. As well, shadow depth maps can deal much more ef- fectively with the terminator problem (Section 1.4.1). Finally, shadow depth maps can easily integrate shadows from any surface type with the flexibility of using dif- ferent visibility determination algorithms for each surface type (e.g., Z-buffer for polygons, ray tracing for algebraic surfaces, simplified splatting for voxels, etc.).
The most common implementation of shadow depth maps in offline render- ing situations is the implementation described by Reeves et al. [476]. Some offer the mid-distance solution [642] for avoiding bad self-shadowing, and many offer some tile-like implementations [172, 333, 480] to reduce memory usage. It is rare to see any nonlinear shadow depth maps implemented, however. This is likely due to the lack of image-artifact-free robustness (especially with aliasing far-away ge- ometry) of the nonlinear approaches in many offline rendering situations as well as the ability of the production users to optimize their scenes very well (i.e., the entire model is rarely submitted for rendering of specific scenes; parts of the models are manually culled) that allows linear shadow depth maps to be very effective.
2.7.2
Real-Time Rendering Trends
In real-time situations, it is rare to see ray tracing in turnkey real-time engines. Although ray tracing is, by far, the most flexible, unfortunately it remains inap- propriate if real-time frame rates are desired unless the platforms support high parallelism (on either the CPU or GPU), which is not universally true yet. Shadow depth map and shadow volume algorithms tend to be much faster on common hardware. Shadow volumes are quite at home in real-time, GPU-based, simple environments (e.g., Sketchup) because the polygon count (for shadow-casting ob- jects) tends to be small, polygons are the dominant primitive for real-time appli- cations, and shadow volumes can deal with polygons very efficiently and accu- rately with little to no user input. However, shadow volumes have not been used in many AAA titled games (high-quality games with large budgets) or other real- time environments because a consistent frame rate cannot be achieved despite the
Figure 2.32.A closed model (left) is no longer closed after cross sectioning (right). Image courtesy of NGRAIN (Canada) Corporation.
optimizations discussed in Section 2.4.3. Also, note that some important shadow volume optimizations (Section 2.4.3) require that objects be closed, but this as- sumption may not be true upon creation, or the assumption may be broken due to real-time interactions such as cross sectioning (without capping). SeeFigure 2.32 for a simple example of a closed model (left) not being closed after cross sectioning (right). However, new approaches such as the per-triangle shadow volumes [536] do show some interesting promise.
On the other hand, shadow depth maps have been quite abundant in real- time engines for more complex environments (such as Second Life, Unity 3D, DX Studio, Renderware, etc.). In fact, most implementations involve either warping shadow depth maps or z-partitioning variations (Section 2.3.7). This has become important to allow entire worlds to be rendered with decent shadow quality with- out resorting to very high shadow depth map resolutions. Z-partitioning variations seem to be gaining more momentum because they generate better quality, tend to be more artifact free, and the quality/performance effects can be controlled by al- lowing the user choice of the number of split planes. In fact, z-partitioning varia- tions seem to be the approach of choice for AAA titled games. There has also been a trend to combine z-partitioning with variance shadow maps to get very good- quality renderings. This is not surprising considering that the two approaches are easy to code and combine.
If only shadows cast on a floor/wall in real time are required, the planar re- ceivers of shadows approach [57, 567, 223] is clearly the winner and most often used implementation under such circumstances (e.g., WebGL). It is even appro- priate and easy to combine approaches: shadows on a floor (where some floors can be a significant size/portion of the scene) are computed using the planar receivers of shadow approach, and the rest of the scene is computed using shadow depth maps, for example.
2.7.3
General Comments
Figure 2.33shows a decision tree for novice practitioners that considers which ap- proaches will work in certain scenarios. Note that the image quality aspect is ad-
yes
use shadow volumes use shadow depth map high scene complexity, or
have ill−formed model, or need other features use ray tracing
low parallelism opportunity and low number of lights?
use planar shadow algorithms use shadow depth map
use ray tracing
low parallelism opportunity and low number of lights?
support polygons only?
shadows on planar floors only? no no no no no yes yes yes yes
Figure 2.33.Graph for determining which shadow approach to use.
dressed at the bottom of the tree, which may be surprising but not unexpected, because the external considerations of the entire system (of which shadow algo- rithms are a part) are generally more constraining.
Pluginable shaders and lights have become commonplace in high-quality ren- derers, such as Renderman, Mental Ray, Maya, etc. This is because shaders and lights only require localized information such as intersection point, texture coor- dinates, tangent values, etc. Allowing shadows to be easily pluginable is tougher however. In the case of ray tracing, this is simple because the user can write user code to add or change shadow rays during shading. However, in non ray tracing algorithms, pluginable shadow algorithms are not that simple because shadow al- gorithms are basically some variation of the visibility determination algorithms. As such, shadow algorithms need access to the data structures of the geometry. Thus, the information required is not so localized. In the case of Renderman, the main support for shadow algorithms is the shadow depth map, and it is treated as a sep- arate rendering pass (Z-depth render mode); then, some user code incorporates the comparison of depth values during shading.
And that is just the literature on hard shadows. The discussions on soft shadows are even more complex and its algorithms less organized. In fact, if the reader only needs to consider polygons, then the recommendation is to skip the next chapter for now and proceed toChapter 4on soft shadows. However, if non-polygons need to be considered, the following chapter should be read next, as it covers hard shadows for non-polygonal objects.
Supporting Shadows for
Other Geometry Types
3.1
What’s Covered in This Chapter
This chapter covers algorithms that generate shadows for non-polygonal primi- tives. Most of the published papers for such primitives discuss hard shadows only with very few delving into soft-shadow discussions. The list of non-polygonal primitives discussed in this chapter includes
● Higher-order surfaces, such as parametric, implicit, subdivision, and CSG (constructive solid geometry) surfaces (Section 3.2).
● Image-based rendering supporting impostors (Section 3.3) [274]. ● Geometry images (Section 3.4).
● Particle systems (Section 3.5). ● Point clouds (Section 3.6).
● Voxels within volume graphics (Section 3.7) [349, 160, 385]. ● Heightfields (Section 3.8).
Note that higher-order surfaces, particle systems, and point clouds are usu- ally natively created in some software (e.g., parametric surfaces created in Maya), whereas heightfields, voxels, and impostors tend to be natively created in other forms and then converted to their particular geometry type for convenience of rendering and visualization.