|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Path to Enlightenment The basic algorithm and the high-level details for successful shadow casting are short and simple. We hope that these have been presented in an enlightening manner. Generally, however, we have only touched on the basic principles of shadow casting. We could easily fill another half-dozen articles with additional perspectives and discussions of related issues. Before concluding this article, we would at least like to touch upon a number of real-world implementation issues that you may want to keep in mind as you approach any project that involves shadow casting. Many of these issues are essential concerns in a real-world shadow casting application. Earlier, we introduced the problem of sub-pixel width polygons being produced from high density or small object shadow volumes. Computing and rendering shadow volumes from an invisible level of detail (LOD) model can spare us this problem, as well as minimizing the calculation and rendering time. While this method produces some visual artifacts of its own, primarily objects that shadow themselves, the overall effect is usually acceptable. It is also faster and it reduces the nasty-looking artifacts often associated with sub-pixel rendering. Most overhead involved with LOD shadowing can be amortized if LOD models are being used in the application for other purposes, such as collision detection. The most
difficult problems encountered with shadow casting involve scene and
geometry considerations. You may have noticed that most shadow-casting
demos demonstrate the technique using only a single overhead light with
a non-moveable camera. This carefully contrived approach helps to build
the excitement of the observer (and future implementer) without reckoning
with the additional problems of point of view and light source changes.
At some point, either during or after the demo, the programmer may latch
on to the difficult question, 'What if the camera lies within the shadow
volume?' The basis of this shadow casting algorithm relies on the fact
that a beam cast from the user's eyeball to any shadowed point in the
scene must pass through both the front and back side of the shadow volume.
Once the volume swings toward the near plane, this effect is lost. In
essence, the user is left staring down the barrel of a corrupt shadow
implementation.
Aggressive frustum culling and high-level scene culling can also cause problems when shadow casting. Even if geometry and lights exist outside the current viewing frustum, the shadow of the geometry can still penetrate into the visible scene. For example, as a shadow volume nears the parallel plane of the ground, it can extend for enormous distances before actually connecting with the ground. This factor must be handled in some manner within in the scene manager, depending on the individual application. Possible solutions include limiting shadow distances (to help the scene manager culling), and performing simple checks to determine if a piece of geometry could possibly shadow the visible scene. Errors in this implementation might cause noticeable 'popping' of shadows as objects are recognized as shadow casters too late in the process. The frustum near plane can also cause related problems. Assuming that the application prevents objects from piercing the viewable near plane, a special case still exists in which geometry pierces the non-viewable near plane, yet the light direction causes the shadow volume to cross into view space. This again creates a situation where a given pixel may not lie between both sides of the volume, resulting in undesired effects. Detecting and fixing this case is much more difficult than the 'capping' scenario, because of the intersection with the near plane. One possible solution is to generate a new silhouette to shadow, taking into account the near plane. Another solution is to prevent this case from occurring by handling it at the scene manager level. You may produce popping effects by doing so, but this approach will generally be the simpler of the two. Turning Shadows into Special Effects Rather than just being a source of potential problems, the shadow casting algorithm can also present new effects possibilities. Shadow coloring is one easy addition to the algorithm that can produce highly realistic or amazing creative effects. By altering the color of the overdraw surface from the basic gray presented here in our examples, you can achieve shadow regions with vivid colors or elaborate textures. This effect can be used for accurate shadow colors in multiple colored-light environments, or even strange otherworldly effects, where shadows seem to be swirling, eerie domains of doom and darkness. There is no rule that the cast volumes must be used for shadows. By choosing a non-invisible alpha blend mode, and perhaps even textures, you can create interesting spotlight, projector or flare effects from a light source. This technique works well when choosing additive blend modes for the overdraw polygon, creating a realistic light-mapping effect rather than shadows. As the Light Source Sets in the West Throughout
this article, we have tried to demystify the process of creating shadows
in 3D environments. We have also tried to provide some concrete methods
that programmers can employ to add that extra element of realism that
real-time shadows can add to an imaginatively rendered world. We hope
that the examples and the algorithms will encourage programmers to experiment
with these techniques and perhaps adapt them for actual applications.
Jason Bestimt graduated from Virginia Tech and went to work for Intel's developer relations group working on 3D apps. Recently he joined the team at Firaxis Games working on their upcoming products. Bryant Freitag is an Application Engineer in the Developer Relations Division at Intel Corporation. When not optimizing, analyzing, and in general doing 'real' work, he strives to make video gaming better for all mankind. This evidently involves playing lots of games as well. |
|
|
Features
