Heuristic42
Blog
Opengl
Meta
Rendering
1
comment
Dec 15 at 4:39
Matrices
Hello! Are you looking to elevate your online business with a p…
–
anonymous
comment
Nov 27 at 0:30
DerBard: Custom Split Mechanical Keyboard Prototype
hello
–
anonymous
comment
Nov 19 at 15:47
Matrices
[deleted]
–
anonymous
created
Oct 20 at 20:30
Iterators: pointers vs cursors
You're already doing both of these by hand. This post emphaisze…
–
pknowles
comment
Oct 10 at 10:27
Matrices
[deleted]
–
anonymous
comment
Oct 4 at 19:12
Matrices
[deleted]
–
anonymous
comment
Sep 30 at 18:51
Matrices
[deleted]
–
anonymous
comment
Sep 23 at 16:15
Matrices
[deleted]
–
anonymous
comment
Sep 21 at 6:52
Contributing
I kind of predicted what was bound to happen when my favourite …
–
anonymous
comment
Sep 7 at 1:21
Route contention when running docker and a VPN
Thank you for this. Between this and the overwriting of iptabl…
–
anonymous
comment
Sep 6 at 17:57
Making a real EMF Reader
Sorry for the random quoted text comments. I am one of those p…
–
anonymous
comment
Sep 6 at 17:48
Making a real EMF Reader
["ove! Play a tone with a buzzer and has 5 LEDs to show the “EM…
–
anonymous
comment
Sep 6 at 17:47
Making a real EMF Reader
["easure direction Measure the magnetic fie"](#q107-644-685)
–
anonymous
comment
Aug 20 at 17:01
Matrices
[deleted]
–
anonymous
comment
Aug 11 at 22:32
Matrices
[deleted]
–
anonymous
edited
Jun 8 at 22:29
Rethinking writing files with memory mapping and C++
This post introduces the motivation behind the [decodless C++ o…
–
admin
created
Jun 8 at 22:16
Rethinking writing files with memory mapping and C++
This post introduces the motivation behind the [decodless C++ o…
–
pknowles
comment
Jun 5 at 13:36
Contributing
[deleted]
–
anonymous
comment
Apr 19 at 11:24
Matrices
[deleted]
–
anonymous
comment
Apr 13 at 0:25
Matrices
[deleted]
–
anonymous
comment
Apr 5 at 9:43
Matrices
[deleted]
–
anonymous
comment
Mar 27 at 17:19
Matrices
[deleted]
–
anonymous
comment
Mar 25 at 4:59
Matrices
[deleted]
–
anonymous
comment
Mar 5 at 15:39
Matrices
[deleted]
–
anonymous
…
View All
Log in
Shadows
leave this field blank to prove your humanity
Slug
*
A URL path component
Parent page
<root>
rendering/:Article2:3D Rendering (Computer Graphics)
--- rendering/cameras/:Article11:Cameras
--- rendering/matrices/:Article12:Matrices
------ rendering/matrices/projection/:Article14:Projection Matrix
--- rendering/vectors/:Article13:Vectors
--- rendering/geometry/:Article62:3D Geometry
------ rendering/geometry/triangle_meshes/:None
--- rendering/shading/:Article64:Shading
------ rendering/shading/transparency/:Article70:Transparency and Alpha Blending
--- rendering/lights/:Article65:Lights
--- rendering/rasterization/:None
------ rendering/rasterization/deepimage/:Article72:Deep Image
--- rendering/shadows/:Article67:Shadows
--- rendering/spaces/:Article68:Vector Spaces
------ rendering/spaces/tangent_space/:Article69:Tangent Space
------ rendering/spaces/clip_space/:Article89:Clip Space
--- rendering/rotations/:None
--- rendering/images/:Article74:<unset>:Images
------ rendering/images/mipmapping/:Article75:<unset>:Mipmapping
--- rendering/materials/:None
opengl/:Article3:OpenGL Tutorials
--- opengl/oit/:Article7:Order Independent Transparency (OIT)
--- opengl/framebuffer/:Article71:The Framebuffer
meta/:Article4:Pages About This Site
--- meta/contribute/:Article5:Contributing
--- meta/bugs/:Article9:Bugs
--- meta/about/:Article10:Why does this website exist?
The parent page this belongs to.
Article title
*
Article revisions must have a non-empty title
Article body
*
Shadows in computer graphics are the explicit handling of blocked light from surfaces --- where other objects in the scene have occluded the light source during [shading](/14/rendering/shading/). To do this a test is done to see if the surface is directly visible to the light. This may take the form of a secondary ray--geometry intersection test between the surface and light sources or *shadow maps* can be used to pre-compute some visibility information for each light. ![enter image description here][1] The first function of a renderer is to project the scene to an image and convert the geometry to pixel data. Basic lighting effects such as diffuse shading is another important feature. This operation can simply skip checking for obstacles between the surface and the light source, which would otherwise cause shadows to appear, applying lighting to everything. This is why shadows are considered to need explicit handling rather than than light not being there in the first place. Diffuse shading makes surfaces facing a light bright and those facing away dark. It does not take the visibility of the light source into account. Since surfaces that face away from the light have zero light contribution this could be seen as implicit self shadowing but is not discussed as such. A common mistake in shadow shaders is to darken the final color, or only partially scale down the direct light contribution when the shadows are too harsh. It is important to remember shadows are the absence of direct light. Ambient light is separate and back facing surfaces must match the color of the shadows. Following this principle will make multiple lights easier to implement and reduce the visual impact of artefacts such as shadow map precision errors. # Soft Shadows Soft shadows occur when a light source is bigger than a point, as pretty much all lights are. Shadows become blurred the larger the light source is and the further away the surface is from the occluding object. Some techniques simply blur the shadow, rather than correctly integrate the amount of light hitting each point on a surface. ![enter image description here][2] To understand why shadows look blurry, imagine looking at the light source from a point on the surface. You can see an object partially covering the light. The amount of shadow is the ratio of light-area the object covers. To be more accurate, the amount of light the point receives is the sum/integral of all light across the remaining visible area. Now imagine moving around on the surface, still looking at the light. As you move from beneath the occluder more of the light is visible and the total intensity increases. This is why the edges of shadows have a smooth gradient. The problem is computationally very similar to depth of field rendering and techniques for each often apply to the other. ![enter image description here][3] # Raytracing When shading a point, ray tracing the scene geometry from the point to the light position will tell you if there is anything in the way. If so, the point is in shadow and direct light contribution should not be applied. This isn't practical for rasterizers and instead shadow maps are created to cache this query, but first we extend the ray concept to soft shadows. A straight forward way to compute soft shadows when shading a surface is to use numerical integration. Light from all visible parts of light sources is summed by choosing lots of points on their surfaces and finding how many many are occluded. Another way of thinking of this is treating each point as a separate light source. Shading should really be applied for each point, but often they are so close together is it more efficient to integrate first and scale the overall light intensity, using a single centre point for the light direction. This approach is essentially that used in many raytracers. # Shadow Maps Rasterizers are fast because they generate pixel data rather than search for ray--geometry intersections. This requires that the virtual viewing rays remain parallel in their projection. Rasterization is bad at computing arbitrary ray intersections such as secondary shadow rays. Instead, shadow maps can be used to pre-compute intersections between light rays and geometry. This is then queried during shading. A shadow map is an image storing depth per-pixel, rendered from the point of view of a light. For the moment, assume the light is a spotlight with direction. A camera, or position, orientation and projection, is created for the light to match its direction. The scene is then rendered using this camera, but storing depth (distance to the camera) instead of colour in the image. ![enter image description here][4] To find if a point is visible to the light, and not in shadow, it is transformed into the shadow map's image space. If the point's depth is greater than the value at that spot in the shadow map then something else is in the way and it is in shadow. During shading the surface position is often used for lighting calculations. For example a position in eye space. This is transformed into the shadow map's image space. In this case, $\mathsf{light}_\mathsf{projection} \mathsf{light}_\mathsf{view} \mathsf{camera}_\mathsf{view}^{-1} \mathsf{position}$. This can be pre-multiplied so only a single matrix multiply is needed. Then, $\mathsf{shadow}_\mathsf{position_{x,y}} < \mathsf{position}_z$ gives whether the surface is in shadow or not. Due to precision errors and interpolation, banding is a common artefact where a surface casts a shadow on itself. To avoid this a depth *bias*, or offset, is added to the shadow map to err on the side of not in shadow: $\mathsf{shadow}_\mathsf{position_{x,y}} + \mathsf{bias} < \mathsf{position}_z$. [1]: /u/img/ce1205145251.png [2]: /u/img/4d3e9b41db61.png [3]: /u/img/d0063a0905a3.svg [4]: /u/img/9ee6053c4d92.png
Toggle Preview
Edit message
*
A description of the changes made
Discard Draft
Save Draft
leave this field blank to prove your humanity
Flag
the thing you clicked
for moderator attention.
Reason choice:
Spam, promoting, advertising without disclosure
Rude, inappropriate, generally offensive
Too arrogant or demeaning to others
Other
Reason:
The reason for raising the flag
Error