diff --git a/tutorials/3d/shadow_mapping.rst b/tutorials/3d/shadow_mapping.rst index d3d7ee74..3f05d4d9 100644 --- a/tutorials/3d/shadow_mapping.rst +++ b/tutorials/3d/shadow_mapping.rst @@ -46,12 +46,12 @@ problems, but the most common one is PSSM (Parallel Split Shadow Maps): .. image:: /img/shadow_directional.png These techniques divide the view in 2 or 4 sections, and a shadow is -rendered for each. This way, close obects can use larger shadow while +rendered for each. This way, close objects can use larger shadow while further away objects will use one in less detail, but in proportion this -seems to make the shadow map size increase while it's actually kept thr +seems to make the shadow map size increase while it's actually kept the same. Of course, this technique is not free, the more splits the more -the performance goes down. On mobile, generally it is convenient to not -sure more tan 2 splits. +the performance goes down. On mobile, it is generally inconvenient to +use more than 2 splits. An alternative technique is PSM (Perspective Shadow Mapping). This technique is much cheaper than PSSM (as cheap as orthogonal), but it @@ -63,12 +63,12 @@ direction are both fixed, and the light is not parallel to the camera Omni light shadows ~~~~~~~~~~~~~~~~~~ -Omnidirectional lights are also troubesome. How to represent 360 degrees +Omnidirectional lights are also troublesome. How to represent 360 degrees of light with a single texture? There are two alternatives, the first one is to use DPSM (Dual Paraboloid Shadow Mapping). This technique is fast, but it requires DISCARD to be used (which makes it not very usable on mobile). DPSM can also look rather bad if the geometry is not -tesselated enough, so more vertices might be necessary if it doesnt'r +tessellated enough, so more vertices might be necessary if it doesn't look tight. The second option is to simply not use a shadow map, and use a shadow cubemap. This is faster, but requires six passes to render all directions and is not supported on the current (GLES2) renderer. @@ -78,9 +78,9 @@ directions and is not supported on the current (GLES2) renderer. As few considerations when using DPSM shadow maps: - Keep Slope-Scale on 0. -- Use a small value for Z-Offset, if thigs look wrong, make it smaller. +- Use a small value for Z-Offset, if this look wrong, make it smaller. - ESM filtering can improve the look. -- The seams between the two halfs of the shadow are generally +- The seams between the two halves of the shadow are generally noticeable, so rotate the light to make them show less. Spot light shadows @@ -107,9 +107,9 @@ Adjusting z-offset So, you have decided to go with non-filtered shadows because they are faster, you want a little more detail or maybe you just like the sexy saw-like shadow outlines because they remind you of your favorite -previous-gen games. Truth is this can kind of be a pain, but most of the -time it can be solved to nice results. There is no magic number and -whathever resut you come up will be different from scene to scene, it +previous-gen games. Truth is, this can be kind of be a pain, but most of the +time it can be adjusted to have nice results. There is no magic number and +whatever result you come up will be different from scene to scene, it just takes a while of tweaking. Let's go step by step. First step is to turn on the shadows, let's assume that both Z-Offset @@ -117,11 +117,11 @@ and Z-Slope-Scale are at 0. You will be greeted by this: .. image:: /img/shadow_offset_1.png -Holy crap, shadow is all around the place and extremely glitchy! this +Holy crap, the shadow is all over the place and extremely glitchy! This happens because the shadow is fighting with the same geometry that is casting it. This is called "self-shadowing". To avoid this meaningless fight, you realize you need to make peace between the shadow and the -geometry, so you push back the shadow a little by adjusting the shadow +geometry, so you push back the shadow a little by increasing the shadow Z-Offset. This improves things a lot: .. image:: /img/shadow_offset_2.png @@ -132,7 +132,7 @@ increase the Z-Offset even more! .. image:: /img/shadow_offset_3.png -And it gets rid of those self-shadowings! hooray! except something is +And it gets rid of those self-shadowings! Hooray! Except something is wrong.. oh, right. Being pushed back too much, the shadows start disconnecting from their casters, which looks pretty awful. Ok, you go back to the previous Z-offset. @@ -144,8 +144,8 @@ shadow caster objects thinner, so the borders don't self-shadow: Aha! Finally something that looks acceptable. It's perfectly acceptable and you can perfectly ship a game that looks like this (imagine you are -looking at Final Fantasy quality art btw, not this horribe attempt at 3D -modelling). There may be very tiiny bits left of self shadowing that no +looking at Final Fantasy quality art btw, not this horrible attempt at 3D +modelling). There may be very tiny bits left of self shadowing that no one cares about, so your inextinguishable greed kicks in again and you raise the Z-Slope Scale again: