1 / 94

951 likes | 1.4k Vues

Shadows. Dinesh Manocha Computer Graphics COMP-770 lecture Spring 2009. What are Shadows?. From Webster’s dictionary:. Shad-ow (noun): partial darkness or obscurity within a part of space from which rays from a source of light are cut off by an interposed opaque body.

Télécharger la présentation
## Shadows

**An Image/Link below is provided (as is) to download presentation**
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.
Content is provided to you AS IS for your information and personal use only.
Download presentation by click this link.
While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

**Shadows**Dinesh Manocha Computer Graphics COMP-770 lecture Spring 2009**What are Shadows?**From Webster’s dictionary: Shad-ow (noun): partial darkness or obscurity within a part of space from which rays from a source of light are cut off by an interposed opaque body Is this definition sufficient?**What are Shadows?**• Does the occluder have to be opaque to have a shadow? • transparency (no scattering) • translucency (scattering) • What about indirect light? • reflection • atmospheric scattering • wave properties: diffraction • What about volumetric or atmospheric shadowing? • changes in density Is this still a shadow?**What are Shadows Really?**• Is this definition sufficient? • In practice, too general! • We need some restrictions Volumes of space that receive no light or lightthat has been attenuated through obscuration**Common Shadow Algorithm Restrictions**• No transparency or translucency! • Limited forms can sometimes be handled efficiently • Backwards ray-tracing has no trouble with these effects, but it is much more expensive than typical shadow algorithms • No indirect light! • More sophisticated global illumination algorithms handle this at great expense (radiosity, backwards ray-tracing) • No atmospheric effects (vacuum)! • No indirect scattering • No shadowing from density changes • No wave properties (geometric optics)!**What Do We Call Shadows?**• Regions not completelyvisible from a light source • Assumptions: • Single light source • Finite area light sources • Opaque objects • Two parts: • Umbra: totally blocked from light • Penumbra: partially obscured area light source shadow umbra penumbra**Basic Types of Light & Shadows**area, direct & indirect area, direct only point, direct only directional, direct only SOFT SHADOWS HARD or SHARP SHADOWS more realistic simpler more realistic for small-scale scenes, directional is realistic for scenes lit by sunlight in space!**Goal of Shadow Algorithms**• Shadow computation can be considered a global illumination problem • this includes ray-tracing and radiosity! • Most common shadow algorithms are restricted to direct light and point or directional light sources • Area light sources are usually approximated by many point lights or by filtering techniques Ideally, for all surfaces, find the fraction of lightthat is received from a particular light source**Global Shadow Component inLocal Illumination Model**• Shadowi is the fraction of light received at the surface • For point lights, 0 (shadowed) or 1 (lit) • For area lights, value in [0,1] • Ambient term approximates indirect light Without shadows: With shadows:**What else does this say?**• Multiple lights are not really difficult (conceptually) • Complex multi-light effects are many single-light problems summed together! • Superposition property of illumination model () • This works for shadows as well! • Focus on single-source shadow computation • Generalization is simple, but efficiency may be improved**Characteristics of Shadow Algorithms**• Light-source types • Directional • Point • Area • Light transfer types • Direct vs. indirect • Opaque only • Transparency / translucency • Atmospheric effects • Geometry types • Polygons • Higher-order surfaces**Characteristics of Shadow Algorithms**• Computational precision (like visibility algorithms) • Object precision (geometry-based, continuous) • Image precision (image-based, discrete) • Computational complexity • Running-time • Speedups from static viewer, lights, scene • Amount of user intervention (object sorting) • Numerical degeneracies**Characteristics of Shadow Algorithms**• When shadows are computed • During rendering of fully-lit scene (additive) • After rendering of fully-lit scene (subtractive)not correct, but fast and often good enough • Types of shadow/object interaction • Between shadow-casting object and receiving object • Object self-shadowing • General shadow casting**Taxonomy of Shadow Algorithms**• Object-based • Local illumination model (Warnock69,Gouraud71,Phong75) • Area subdivision (Nishita74,Atherton78) • Planar projection (Blinn88) • Radiosity (Goral84,Cohen85,Nishita85) • Lloyd (2004) • Image-based • Shadow-maps (Williams78,Hourcade85,Reeves87, Stamminger/Drettakis02, Lloyd 07) • Projective textures (Segal92) • Hybrid • Scan-line approach (Appel68,Bouknight70) • Ray-tracing (Appel68,Goldstein71,Whitted80,Cook84) • Backwards ray-tracing (Arvo86) • Shadow-volumes (Crow77,Bergeron86,Chin89)**Good Surveys of Shadow Algorithms**Early complete surveys found in (Crow77 & Woo90) Recent survey on hard shadows: Lloyd 2007 (Ph.D. thesis) Recent survey on soft shadows: Laine 2007 (Ph.D. thesis)**Survey of Shadow Algorithms**Focus is on the following algorithms: • Local illumination • Ray-tracing • Planar projection • Shadow volumes • Projective textures • Shadow-maps Will briefly mention: • Scan-line approach • Area subdivision • Backwards ray-tracing • Radiosity**Local Illumination “Shadows”**• Backfacing polygons are in shadow (only lit by ambient) • Point/directional light sources only • Partial self-shadowing • like backface culling is a partial visibility solution • Very fast (often implemented in hardware) • General surface types in almost any rendering system!**Local Illumination “Shadows”**• Typically, not considered a shadow algorithm • Just handles shadows of the most restrictive form • Dramatically improves the look of other restricted algorithms**Local Illumination “Shadows”**Properties: • Point or directional light sources • Direct light • Opaque objects • All types of geometry (depends on rendering system) • Object precision • Fast, local computation (single pass) • Only handles limited self-shadowing convenient since many algorithms do not handle any self-shadowing • Computed during normal rendering pass • Simplest algorithm to implement**Ray-tracing Shadows**Only interested in shadow-ray tracing (shadow feelers) • For a point P in space, determine if it is shadow with respect to a single point light source L by intersecting line segment PL (shadow feeler) with the environment • If line segment intersects object, then P is in shadow, otherwise, point P is illuminated by light source L L shadow feeler(edge PL) P**Ray-tracing Shadows**• Arguably, the simplest general algorithm • Can even handle area light sources • point-sample area source: distributed ray-tracing (Cook84) Area light Li Li P P Shadowi = 0 Shadowi = 2/5**Ray-tracing Shadows**• Slow • Intersection tests are (relatively) expensive • May be sped up with standard ray-tracing acceleration techniques • Shadow feeler may incorrectly intersect object touching P • Depth bias • Object tagging • Don’t intersect shadow feeler with object touching P • Works only for objects not requiring self-shadowing Sounds great, what’s the problem?**Ray-tracing Shadows**How do we use the shadow feelers? 2 different rendering methods • Standard ray-casting with shadow feelers • Hardware Z-buffered rendering with shadow feelers**Ray-tracing Shadows**Ray-casting with shadow feelers For each pixel: • Trace ray from eye through pixel center • Compute closest object intersection point P along ray • Calc Shadowi for point by performing shadow feeler intersection test • Calc illumination at point P Light Eye**Ray-tracing Shadows**Z-buffering with shadow feelers • Render the scene into the depth-buffer (no need compute color) • For each pixel, determine if in shadow: • “unproject” the screen space pixel point to transform into eye space • Perform shadow feeler test with light in eye space to compute Shadowi • Store Shadowi for each pixel • Light the scene using per-pixel Shadowi values Light Eye**Ray-tracing Shadows**Z-buffering with shadow feelers How do we use per-pixel Shadowi values to light the scene? • Method 1: compute lighting at each pixel in software • Deferred shading • Requires object surface info (normal, materials) • Could use more complex lighting model**Ray-tracing Shadows**Z-buffering with shadow feelers How do we use per-pixel Shadowi values to light the scene? • Method 2: use graphics hardware • For point lights: • Shadowi values either 0 or 1 • Use stencil buffer, stencil values = Shadowi values • Re-render scene with the corresponding light on using graphics hardware but use stencil test to only write into lit pixels (stencil=1). Should perform additive blending and ambient-lit scene should be rendered in depth computation pass. • For area lights: • Shadowi values continuous in [0,1] • Multiple-passes and modulation blending • Pixel Contribution = Ambienti + Shadowi*(Diffusei+Speculari)**Ray-tracing Shadows**Properties • Point, directional, and area light sources • Direct light (may be generalized to indirect) • Opaque (thin-film transparency easily handled) • All types of geometry (just need edge intersection test) • Hybrid : object-precision (line intersection), image-precision for generating pixel rays • Slow, but many acceleration techniques are available • General shadow algorithm • Computed during illumination (additive, but subtractive is possible) • Simple to implement**Planar Projection Shadows**• Shadows cast by objects onto planar surfaces • Brute force: project shadow casting objects onto the plane and draw projected object as a shadow Directional light(parallel projection) Point light(perspective projection)**Planar Projection Shadows**Not sufficient • co-planar polygons (Z-fighting) : depth bias • requires clipping to relevant portion of plane : shadow receiver stenciling**Planar Projection Shadowsbetter approach, subtractive**strategy Render scene fully lit by single light For each planar shadow receiver: • Render receivers: stencil pixels covered • Render projected shadow casters in a shadow color with depth testing on, depth biasing (offset from plane), modulation blending, and stenciling (to write only on receiver and to avoid double pixel writing) • Receiver stencil value=1, only write where stencil equals 1, change to zero after modulating pixel Texture is visible in shadow**Planar Projection Shadowsproblems with subtractive strategy**• Called subtractive because it begins with full-lighting and removes light in shadows (modulates) • Can be more efficient than additive (avoids passes) • Not as accurate as additive. Doesn’t follow lighting model • Specular and diffuse components in shadow • Modulates ambient term • Shadow color is chosen by user as opposed to the correct version**Planar Projection Shadowseven better approach, additive**strategy • Draw ambient lit shadow receiving scene (global and all lights’ local ambient) • For each light source:For each planar receiver • Render receiver: stencil pixels covered • Render projected shadow casters into stenciled receiver area: depth testing on, depth biasing, stencil pixels covered by shadow • Re-render receivers lit by single light source (no ambient light): depth-test set to EQUAL, additive blending, write only into stenciled areas on receiver and not in shadow • Draw shadow casting scene: full-lighting**Planar Projection ShadowsProperties**• Point or directional light sources • Direct light • Opaque objects (could fake transparency using subtractive) • Polygonal shadow casting objects, planar receivers • Object precision • Number of passes: L=num lights, P=num planar receivers • subtractive: 1 fully lit pass, L*P special passes (no lighting) • additive: 1 ambient lit pass, 2*L*P receiver passes, L*P caster passes**Planar Projection ShadowsProperties**• Can take advantage of static components: • static objects & lights: precompute silhouette polygon from light source • static objects & viewer: precompute first pass over entire scene • Visibility from light is handled by user(must choose casters and receivers) • No self-shadowing (relies on local illumination) • Both subtractive and additive strategies presented • Conceptually simple, surprisingly difficult to get right gives techniques needed to handle more sophisticated multi-pass methods**Shadow VolumesWhat are they?**Volume of space in shadow of a single occluder with respect to a point light source OR Volume of space swept out by extruding an occluding polygon away from a point light source along the projector rays originating at the pointlight and passing through the vertices of the polygon point light occluding triangle 3D shadow volume**Shadow VolumesHow do you use them?**• Parity test to see if a point P on a visible surface is in shadow: • Initialize parity to 0 • Shoot ray from eye to point P • Each time a shadow-volume boundary is crossed, invert the parity • if parity=0, P is in shadowif parity=1, P is lit What are some potential problems? point light eye 0 occluder 0 0 1 1 0 parity=0 parity=1 parity=0**Shadow VolumesProblems with Parity Test**• Incorrectly shadows pts(reversed parity) • Should a point on the occluder flip the parity?(consistent if not flipped) Eye inside of shadow volume Self-shadowing of visible occluders Multiple overlapping shadow volumes 0 0 0 0 1 0 1 0 1 0 • Point on the occluder should not flip the parity • Touching boundary is not counted as a crossing • Incorrectly shadows pts (incorrect parity) • Is parity’s binary condition sufficient?**Shadow VolumesSolutions to Parity Test Problems**• Init parity to be 0 when starting outside and 1 when inside • Do not flip parity when viewing the “in”-side of an occluder Eye inside of shadow volume Self-shadowing of visible occluders Multiple overlapping shadow volumes 0 1 +1 +1 -1 -1 1 1 0 0 1 2 1 0 • Do not flip parity when viewing “out”-side of an occluder either • Binary parity value is not sufficient, we need a general counter for boundary crossings: +1 entering a shadow volume, -1 exiting**+1**+1 -1 -1 0 1 2 1 0 Shadow VolumesA More General Solution Determine if point P is in shadow: • Init boundary crossing counter to number of shadow volumes containing the eye pointWhy? Because ray must leave this many shadow volumes to reach a lit point • Along ray, increment counter each time a shadow volume is entered, decrement each time one is exited • If the counter is >0, P is in shadow Special case when P is on an occluder • Do not increment or decrement counter • Point on boundary does not count as a crossing**Shadow VolumesMore Examples**Can you calculate the final boundary count for these visible points?**Shadow VolumesMore Examples**Can you calculate the final boundary count for these visible points? 1 0 +1 +1 1 +1 -1 +1 +1 -1 1 +1 -1 -1 0 2 0 0**Shadow VolumesHow do we use this information to find shadow**pixels? Could just use ray-casting (ray through each pixel) • Too slow, possibly more primitives to intersect with • Could use silhouette of complex objects to simplify shadow volumes 0 0 1 + - + - + 1 + - 0 - + - + + + + - - + + - + 0 + - + + - + 1 0 2 1**Shadow VolumesUsing Standard Graphics Hardware**Simple observations: • For convex occluders, shadows volumes form convex shape. • Enter through front-facing shadow-volume boundariesExit through back-facing 0 0 1 + - + - + 1 + - 0 - + - + + + + - - + + - + 0 + - + + - +**Shadow VolumesUsing Standard Graphics Hardware**Use standard Z-buffered rendering and the stencil buffer (8 bits) to calculate boundary count for each pixel • Create shadow volumes for each occluding object (should be convex) • Render the ambient lit scene, keep the depth values • For each light source • Initialize stencil values to number of volumes containing the eye point • Still using the Z-buffer depth test (strictly less-than), but no depth update • Render the front-facing shadow-volume boundary polygons, increment stencil values for all pixels covered by the polygons that pass the depth test • Render the back-facing boundary polygons, but decrement the stencil. • Pixels with stencil value of zero are lit, re-render the scene with lighting on (no ambient, depth-test should be set to equal).**Shadow VolumesUsing Standard Graphics Hardware: step-by-step**• Create shadow volumes • Initialize stencil buffer valuesto # of volumes containing eye per-pixel stencil values initially 0**Shadow VolumesUsing Standard Graphics Hardware: step-by-step**• Render the ambient lit scene • Store the Z-buffer • Set depth-test to strictly less-than**Shadow VolumesUsing Standard Graphics Hardware: step-by-step**• Render front-facing shadow-volume boundary polygons • Why front faces first? Unsigned stencil values • Increment stencil values for pixels covered that pass depth-test**Shadow VolumesUsing Standard Graphics Hardware: step-by-step**• Render back-facing shadow-volume boundary polygons • Decrement stencil values for pixels covered that pass depth-test**Shadow VolumesUsing Standard Graphics Hardware: step-by-step**• Pixels with stencil value of zero are lit • Set depth-test to strictly equals • Re-render lit scene with no ambient into lit pixels

More Related