diff --git a/Advanced/Plate.png b/Advanced/Plate.png new file mode 100644 index 0000000..708916c Binary files /dev/null and b/Advanced/Plate.png differ diff --git a/Advanced/artifacts_removeaccessoffset.png b/Advanced/artifacts_removeaccessoffset.png new file mode 100644 index 0000000..9c4b1d8 Binary files /dev/null and b/Advanced/artifacts_removeaccessoffset.png differ diff --git a/Advanced/artifacts_sampleonce.png b/Advanced/artifacts_sampleonce.png new file mode 100644 index 0000000..8e8e33c Binary files /dev/null and b/Advanced/artifacts_sampleonce.png differ diff --git a/Advanced/bandartifacts.png b/Advanced/bandartifacts.png new file mode 100644 index 0000000..c7a891b Binary files /dev/null and b/Advanced/bandartifacts.png differ diff --git a/Advanced/equirectangular.png b/Advanced/equirectangular.png new file mode 100644 index 0000000..6e03f7e Binary files /dev/null and b/Advanced/equirectangular.png differ diff --git a/Advanced/equirectangular_rendering.html b/Advanced/equirectangular_rendering.html index a42f736..b9d6ec9 100644 --- a/Advanced/equirectangular_rendering.html +++ b/Advanced/equirectangular_rendering.html @@ -142,67 +142,73 @@
-

5.3 Equirectangular Rendering

Equirectangular rendering is a useful technique to show 360 panorama images. we often see this technique being used for visualizing interior design. or used for rendering further away background or sky in games. with the increasing popularity of the 360 cameras, this technique becomes very useful.

a typical euirectangular texture looks like the following. it should be familiar to you already, as this is how we flatten the globe. We already know how to pin point a location on this map, given a set of longitude and latitude. This is essentially how we access the equirectuangular texture map, via a spherical coordinates.

Image to Show a Flattened Globe
Image to Show a Flattened Globe

the idea of equirectangular rendering is also not difficult to grasp. normally when we access a texture map, we do so via the uv coordinates. when we perform the equirectangular rendering, we create an imaginary sphere enclosing our camera. imagine the framebuffer being rendered is a plane in front of our camera. through each fragment of this image plane, we shot out a ray from our camera position, passing through each fragment and intersects with the imaginary sphere. The intersection point has a coordinate in the Spherical coordinate system theta, .

Image to Show Shooting Ray Intersecting Global
Image to Show Shooting Ray Intersecting Global

with the spherical coordinates, we can derive a uv texture coordinate, through which, we sample the texture map. we are free to rotate the camera, this will allow us to view all the directions of the 360 image.

    // Vertex shader
-    
-    @group(0) @binding(0)
-    var<uniform> modelView: mat4x4<f32>;
-    @group(0) @binding(1)
-    var<uniform> projection: mat4x4<f32>;
-    
-    struct VertexOutput {
-        @builtin(position) clip_position: vec4<f32>,
-        @location(0) worldPos: vec3<f32>
-    };
-    
-    @vertex
-    fn vs_main(
-        @location(0) inPos: vec3<f32>
-    ) -> VertexOutput {
-        var out: VertexOutput;
-        out.worldPos = inPos;
-        var wldLoc:vec4<f32> = modelView * vec4<f32>(inPos, 1.0);
-        out.clip_position = projection * wldLoc;
-        return out;
-    }
-    
-    // Fragment shader
-
-    const pi:f32 = 3.141592654;
-    @group(0) @binding(2)
-    var t_diffuse: texture_2d<f32>;
-    @group(0) @binding(3)
-    var s_diffuse: sampler;
-
-    @fragment
-    fn fs_main(in: VertexOutput) -> @location(0) vec4<f32> {
-        var n:vec3<f32> = normalize(in.worldPos);
-
-        var len:f32 = sqrt (n.x *n.x + n.y*n.y);
-
-        var s:f32 = acos( n.x / len);
-
-        if (n.y < 0) {
-            s = 2.0 * pi - s;
-        }
-
-        s = s / (2.0 * pi);
-
-        var tex_coord:vec2<f32> = vec2(s , ((asin(n.z) * -2.0 / pi ) + 1.0) * 0.5);
-        return textureSampleLevel(t_diffuse, s_diffuse, tex_coord, 0);
-    }

next, let's look at the shader code. The vertex shader is straightforward. We simply does the basic modelview and projection conversion and in addition, we pass the world coordinates to the fragment shader. this word coordinates will help us derive the spherical coordinates used for sampling the texture map.

in the fragment shader, we retrieve the world coordinates, and we calculate the longitude s based on the following equation:

and the latitude based on: -.

since the latitude is between -pi,pi, we will scale it to 0,1.0. notice that we are flipping the latitude or the v coordinate, because the texture coordinate system and the spherical system are flipped along v or latitude.

and following that is a standard texture sampling.

Example Image of Equirectangular Image
Example Image of Equirectangular Image

another very useful thing about Equirectangular rendering is to render highly reflective surfaces, such as metal or mirror or glass. these surface can reflect surrounding environment. Let's see how to render this type of object.

           
-                let nn:vec3<f32> = reflect(-viewDir, n);
-
-                var len:f32 = sqrt (nn.x *nn.x + nn.y*nn.y);
-                var s:f32 = acos( nn.x / len);
-                if (nn.y < 0) {
-                    s = 2.0 * pi - s;
-                }
-                s = s / (2.0 * pi);
-                var tex_coord:vec2<f32> = vec2(s , ((asin(nn.z) * -2.0 / pi ) + 1.0) * 0.5);
-                var diffuseColor:vec4<f32> =
-                        textureSampleLevel(t_diffuse, s_diffuse, tex_coord, 0);
-

previously, in the shadow map demo, we created a teapot with diffuse surface. This time, instead of using a fixed color for the diffuse channel, we will be sampling the diffuse color from its surrounding environment, i.e. the Equirectangular texture map. the sample direction this time, is the reflection direction calculated by both the surface normal and the viewing direction. The rest of the code is the same as the shadow map example and the previous example, we will skip the details.

here is an output of the above example:

Image to Show the Full Sample
Image to Show the Full Sample

+

5.3 Equirectangular Rendering

Equirectangular rendering is a technique widely used for displaying 360-degree panorama images. This method is particularly popular in interior design visualizations and for rendering distant backgrounds or skies in games. With the rise of 360 cameras, this technique has gained even more relevance.

Launch Playground - 5_03_equalrectangle_rendering

An equirectangular texture is essentially a flattened representation of a spherical surface, similar to how a globe is projected onto a 2D map. If you are familiar with this projection, you know that it maps the globe into a rectangular format where longitude and latitude define specific points on the map. This is the basis for accessing the equirectangular texture map through spherical coordinates.

Equirectangular Projection of the Globe
Equirectangular Projection of the Globe

The concept behind equirectangular rendering is straightforward. Typically, texture mapping is done using UV coordinates. In equirectangular rendering, however, we envision an imaginary sphere surrounding the camera. The framebuffer being rendered acts as a plane in front of the camera. For each fragment on this image plane, a ray is cast from the camera position through the fragment, intersecting the imaginary sphere. This intersection point is defined by spherical coordinates, specifically theta and phi.

Equirectangular Texture Access
Equirectangular Texture Access

Using these spherical coordinates, we can derive UV texture coordinates to sample the equirectangular texture map. This setup allows for the camera to rotate freely, providing a full 360-degree view of the panorama image.

@group(0) @binding(0)
+var<uniform> modelView: mat4x4<f32>;
+@group(0) @binding(1)
+var<uniform> projection: mat4x4<f32>;
+
+struct VertexOutput {
+    @builtin(position) clip_position: vec4<f32>,
+    @location(0) worldPos: vec3<f32>
+};
+
+@vertex
+fn vs_main(
+    @location(0) inPos: vec3<f32>
+) -> VertexOutput {
+    var out: VertexOutput;
+    out.worldPos = inPos;
+    var wldLoc:vec4<f32> = modelView * vec4<f32>(inPos, 1.0);
+    out.clip_position = projection * wldLoc;
+    return out;
+}
+
+// Fragment shader
+
+const pi:f32 = 3.141592654;
+@group(0) @binding(2)
+var t_diffuse: texture_2d<f32>;
+@group(0) @binding(3)
+var s_diffuse: sampler;
+
+@fragment
+fn fs_main(in: VertexOutput) -> @location(0) vec4<f32> {
+    var n:vec3<f32> = normalize(in.worldPos);
+
+    var len:f32 = sqrt (n.x *n.x + n.y*n.y);
+
+    var s:f32 = acos( n.x / len);
+    if (n.y < 0) {
+        s = 2.0 * pi - s;
+    }
+
+    s = s / (2.0 * pi);
+    var tex_coord:vec2<f32> = vec2(s , ((asin(n.z) * -2.0 / pi ) + 1.0) * 0.5);
+    return textureSampleLevel(t_diffuse, s_diffuse, tex_coord, 0);
+}
+
5_03_equalrectangle_rendering/index.html:212-255 Shader Samples From Equirectangular Texture

Let's now examine the shader code used for equirectangular rendering. The vertex shader performs standard model-view and projection transformations, and it also passes world coordinates to the fragment shader. These world coordinates are essential for deriving spherical coordinates used to sample the equirectangular texture map.

In the fragment shader, we start by retrieving the world coordinates. We then calculate the longitude and latitude. The longitude is derived from:

var n:vec3<f32> = normalize(in.worldPos);
+
+var len:f32 = sqrt (n.x *n.x + n.y*n.y);
+
+var s:f32 = acos( n.x / len);
+
5_03_equalrectangle_rendering/index.html:243-247 Calculating Longitude

and the latitude from:

if (n.y < 0) {
+    s = 2.0 * pi - s;
+}
+
+s = s / (2.0 * pi);
+
5_03_equalrectangle_rendering/index.html:248-252 Calculating Latitude

Since latitude ranges from -π to π, we scale it to the range of 0 to 1. Additionally, we flip the latitude or V coordinate, as the texture coordinate system and the spherical coordinate system have opposite orientations along V or latitude.

Texture sampling is performed as usual after these calculations.

Example Image of Equirectangular Image
Example Image of Equirectangular Image

Equirectangular rendering is also highly effective for rendering reflective surfaces like metal, mirrors, or glass. These surfaces reflect their surrounding environment, and equirectangular textures can be used to capture this reflection. Here’s how you can implement this:

let nn:vec3<f32> = reflect(-viewDir, n);
+
+var len:f32 = sqrt (nn.x *nn.x + nn.y*nn.y);
+var s:f32 = acos( nn.x / len);
+if (nn.y < 0) {
+    s = 2.0 * pi - s;
+}
+s = s / (2.0 * pi);
+var tex_coord:vec2<f32> = vec2(s , ((asin(nn.z) * -2.0 / pi ) + 1.0) * 0.5);
+var diffuseColor:vec4<f32> =
+        textureSampleLevel(t_diffuse, s_diffuse, tex_coord, 0);
+
5_03_equalrectangle_rendering/index.html:142-152 Shader Reflect Environment Map

In this code snippet, we first compute the reflection direction based on the surface normal and viewing direction. The longitude (s) and latitude are derived from this reflection vector. The latitude is scaled to fit the texture coordinate system. We then sample the diffuse color from the equirectangular texture using these coordinates.

In contrast to our previous shadow map demo, where a fixed color was used, here we sample the diffuse color from the surrounding environment represented by the equirectangular texture. The process remains similar to the shadow map example, so we’ll skip the detailed explanation.

Here is the output of the above example:

The Result of the Rendering
The Result of the Rendering

diff --git a/Advanced/equirectangular_result.png b/Advanced/equirectangular_result.png new file mode 100644 index 0000000..4c8579c Binary files /dev/null and b/Advanced/equirectangular_result.png differ diff --git a/Advanced/parking_lot.jpg b/Advanced/parking_lot.jpg new file mode 100644 index 0000000..ce07eb2 Binary files /dev/null and b/Advanced/parking_lot.jpg differ diff --git a/Advanced/shadow_mapping.html b/Advanced/shadow_mapping.html index cc7981c..d0dc005 100644 --- a/Advanced/shadow_mapping.html +++ b/Advanced/shadow_mapping.html @@ -142,141 +142,163 @@
-

5.1 Shadow Mapping

previously we have learned about lighting, but lighting alone will not achieve realisticity. Our lighting model is very simple, as long as the surface normal is facing a light source, the surface area should be lit up. however, In real life, objects can also cast shadows. a surface area that is occluded from any light source by an object should be dark even its normal is facing light sources.

in this chapter, let's look at how shadow can be implemented. we will be looking at a simple technique called the shadow map. This technique can implement hard shadow, i.e. the boundary between a shadowed area and a lit-up area is distinct. A hard shadow can be generated by idealized a single point light source. it doesn't model more complex scenarios, such as the soft shadow that could be the result of a nearby area light source.

the idea of shadow map is not that complex. we first render the scene from the point of view of the light source. the purpose of this rendering is to generate a depth map, this depth map records the shortest distance from the light source to all areas that are directly under the light source.

later when we render the scene from the actual camera, for each fragment, we calculate its distance to the light source and compare the distance with the value on the above depth map. if the distance is equal or shorter, it means the fragment is lit by the light source. otherwise, the fragment must be occluded, hence we render it in a darker color.

Our code will be based on the lighting code we created before. but the first step is converting the light from a point light to a spot light. the point light can shoot out rays in all directions, it can light up the scene in 360 directions. whereas the spot light has a narrow light cone, only within the cone, the scene can be light up.

when we render the scene from the view of the light, we need to define a view frustum, which is compatible with the spot light.

Image to Illustrate the Spot Light
Image to Illustrate the Spot Light

The idea of implementing spot light is very easy. we only need to slightly modify our original point light shader:

var wldLoc2light:vec3<f32> =   in.wldLoc-lightLoc;
+            
5.1 Shadow Mapping
In previous lessons, we covered lighting, but achieving realism requires more than just lighting alone. Our current lighting model is quite basic: if a surface normal faces a light source, the surface is illuminated. However, in reality, objects cast shadows, meaning that a surface area blocked from a light source by an object should remain dark, even if its normal faces the light.
Launch Playground - 5_01_shadow_maps
In this tutorial, we will explore how to implement shadows using a technique called shadow mapping. This technique allows us to create hard shadows, where the boundary between shadowed and lit areas is well-defined. Hard shadows can be produced by simulating an idealized point light source but do not address more complex scenarios like soft shadows that result from nearby area light sources.
The concept of shadow mapping is straightforward. First, we render the scene from the light source’s perspective to generate a depth map. This depth map records the shortest distance from the light source to all visible surfaces directly illuminated by the light.
Later, when rendering the scene from the camera’s perspective, we calculate the distance from each fragment to the light source and compare it with the corresponding value in the depth map. If the distance is equal to or less than the depth map value, the fragment is lit by the light source. Otherwise, if the distance is greater, the fragment is considered occluded and is rendered in a darker color.
Our code will build on the lighting code from before. The first step is to adjust the light from a point light to a spot light. Unlike a point light, which emits rays in all directions, a spot light has a narrow cone of illumination, affecting only the scene within this cone.
When rendering from the light’s perspective, we need to define a view frustum compatible with the spot light.
Spot Light
Spot Light
Implementing a spot light is straightforward. We only need to make a few adjustments to our original point light shader:
if (face) {
+    var wldLoc2light:vec3<f32> =   in.wldLoc-lightLoc;
+    if (align > 0.9) {
+        var radiance:vec3<f32>  = ambientColor.rgb * ambientConstant + 
+            diffuse(-lightDir, n, diffuseColor.rgb)* diffuseConstant +
+            specular(-lightDir, viewDir, n, specularColor.rgb, shininess) * specularConstant;
 
-var align:f32 = dot( normalize(wldLoc2light),lightDir);
-
-if (align > 0.9) {
-    var radiance:vec3<f32>  = ambientColor.rgb * ambientConstant + 
-        diffuse(-lightDir, n, diffuseColor.rgb)* diffuseConstant +
-        specular(-lightDir, viewDir, n, specularColor.rgb, shininess) * specularConstant;
-        
         return vec4<f32>(radiance * visibility ,1.0);
-} else {
-    return vec4<f32>(1.0,1.0,0.0,1.0);
-}
here wldLoc2light is the vector of the fragment's world location to the light's location. whereas lightDir is the light direction. we perform a dot product of the two vectors and only light up fragments when the dot product passes our threshold of 0.9. i.e. the angle between the vectors need to be small enough. both vectors are in the world coordinate system, without applying the projection matrix;
    var wldLoc:vec4<f32> = modelView * vec4<f32>(inPos, 1.0);
-    out.clip_position = projection * wldLoc;
-    out.wldLoc = wldLoc.xyz / wldLoc.w;
-    ...
-    var lightLoc:vec4<f32> = modelView * vec4<f32>(lightDirection, 1.0);
-    out.lightLoc = lightLoc.xyz / lightLoc.w;
Image to Show Spot Light After Shader Change
Image to Show Spot Light After Shader Change
after turning the point light into a spot light, next, we will generate a depth map, or a shadow map by rendering the scene using a virtual camera that is aligned with the light.
let's take a step by step approach by dumping and visualizing this depth map first before applying it to the third step to create the shadow.
    // Vertex shader
-    
-    @group(0) @binding(0)
-    var<uniform> modelView: mat4x4<f32>;
-    @group(0) @binding(1)
-    var<uniform> projection: mat4x4<f32>;
-    
-    struct VertexOutput {
-        @builtin(position) clip_position: vec4<f32>,
-        @location(0) depth: f32
-    };
-    
-    @vertex
-    fn vs_main(
-        @location(0) inPos: vec3<f32>
-    ) -> VertexOutput {
-        var out: VertexOutput;
-
-        var wldLoc:vec4<f32> = modelView * vec4<f32>(inPos, 1.0);
-        out.clip_position = projection * wldLoc;
-        out.depth = out.clip_position.z / out.clip_position.w;
-        return out;
     }
+} 
+return vec4<f32>( 0.0,0.0,0.0,1.0);
+
5_01_shadow_maps/index.html:135-145 Spot Light Shader
In this shader, wldLoc2light represents the vector from the fragment’s world location to the light’s location, while lightDir is the light direction vector. We compute the dot product of these two vectors and only illuminate the fragment if the dot product exceeds a threshold of 0.9, indicating that the angle between the vectors is sufficiently small. Both vectors are in the world coordinate system and have not yet been transformed by the projection matrix:
var wldLoc:vec4<f32> = modelView * vec4<f32>(inPos, 1.0);
+out.clip_position = projection * wldLoc;
+out.wldLoc = wldLoc.xyz / wldLoc.w;
+out.inPos = inPos;
+var lightLoc:vec4<f32> = modelView * vec4<f32>(lightDirection, 1.0);
+out.lightLoc = lightLoc.xyz / lightLoc.w;
+
5_01_shadow_maps/index.html:92-97 Spot Light Vectors
After converting the point light to a spot light, the next step is to generate a depth map, or shadow map, by rendering the scene from a virtual camera aligned with the light.
Let’s take a step-by-step approach: first, we’ll dump and visualize the depth map before applying it in the final step to create the shadow effect.
@group(0) @binding(0)
+var<uniform> modelView: mat4x4<f32>;
+@group(0) @binding(1)
+var<uniform> projection: mat4x4<f32>;
+
+struct VertexOutput {
+    @builtin(position) clip_position: vec4<f32>,
+    @location(0) depth: f32
+};
+
+@vertex
+fn vs_main(
+    @location(0) inPos: vec3<f32>
+) -> VertexOutput {
+    var out: VertexOutput;
+    var wldLoc:vec4<f32> = modelView * vec4<f32>(inPos, 1.0);
+    out.clip_position = projection * wldLoc;
+    out.depth = out.clip_position.z / out.clip_position.w;
+    return out;
+}
 
-    struct FragOutputs {
-        @builtin(frag_depth) depth: f32,
-        @location(0) color: vec4<f32>
-      }
-    
-    // Fragment shader
-    @fragment
-    fn fs_main(in: VertexOutput,   @builtin(front_facing) isFront: bool) -> FragOutputs {
-        var out:FragOutputs;
-        if (isFront) {
-            out.depth = in.depth;
-        }
-        else {
-            out.depth = in.depth -0.001;
-        }
-        out.color = vec4<f32>(0.0,1.0,0.0,1.0);
-        return out;
-    }
the above shader is simple and should be familiar to you. let me explain some of the interesting details. first, as previously mentioned, the depth map is rendered from the view of the light, hence the modelview matrix and the projection matrix is not from the camera, but from the light. Second, in a normal fragment shader, depth is implicitly calculated by the graphics pipeline. but here we need to write the depth value onto a texture map, hence, we have to manually calculate the depth. this is not difficult to do. as we have seen the formula that calculates the clip space position for multiple times. In the clip space, the z value is the depth.
what bears more explanation is the following chunk:
        if (isFront) {
-            out.depth = in.depth;
-        }
-        else {
-            out.depth = in.depth -0.001;
-        }
here we check if the current fragment is front facing. if it is, we output the depth. if it is not, we slightly adjust the depth by moving the fragment closer to the camera a little bit. This is a hack to deal with potential artifacts that might be caused by numerical errors. We will look back at this hack once we have implemented the full program and see what it will happen if we remove this hack.
now let's look at the javascript side and see how parameters are calculated and passed to the above shader. First, we need to create a model view matrix for the light. We want the light to circle around the teapot. for each rendering iteration, we slightly update the angle of the light. Then we calculate a model view matrix out of this angle.
let lightDir = glMatrix.vec3.fromValues(Math.cos(angle) * 8.0, Math.sin(angle) * 8.0, 10);
+struct FragOutputs {
+    @builtin(frag_depth) depth: f32,
+    @location(0) color: vec4<f32>
+  }
+
+// Fragment shader
+@fragment
+fn fs_main(in: VertexOutput,   @builtin(front_facing) isFront: bool) -> FragOutputs {
+    var out:FragOutputs;
+    if (isFront) {
+        out.depth = in.depth;
+    }
+    else {
+        out.depth = in.depth -0.001;
+    }
+    out.color = vec4<f32>(0.0,1.0,0.0,1.0);
+    return out;
+}
+
5_01_shadow_maps/index.html:151-189 Shader to Generate Shadow Map
The shader presented is straightforward and should be familiar. To clarify, the depth map is rendered from the perspective of the light, so the modelView and projection matrices are derived from the light's viewpoint rather than the camera's. In a standard fragment shader, depth calculations are handled automatically by the graphics pipeline. However, in this case, we need to manually calculate and write the depth value to a texture map. This is done using the clip space position, where the z-value represents the depth.
A notable detail in the shader code is:
if (isFront) {
+    out.depth = in.depth;
+}
+else {
+    out.depth = in.depth -0.001;
+}
+
5_01_shadow_maps/index.html:181-186 Applying a Small Depth Offset to Back-Facing Surfaces
Here, the shader checks if the current fragment is front-facing. If it is, the depth value is output directly. If the fragment is not front-facing, the depth is slightly adjusted by moving it closer to the camera. This adjustment helps to mitigate artifacts caused by numerical precision issues. We can revisit and assess the impact of this adjustment after implementing the full program.
Next, we turn to the JavaScript side to understand how parameters are calculated and passed to the shader. Specifically, we need to create a model-view matrix for the light, ensuring it circles around the teapot. For each rendering iteration, we adjust the light’s angle and recalculate the model-view matrix accordingly.
let lightDir = glMatrix.vec3.fromValues(Math.cos(angle) * 8.0, Math.sin(angle) * 8.0, 10);
 let lightDirectionUniformBufferUpdate = createGPUBuffer(device, lightDir, GPUBufferUsage.COPY_SRC);
+spotlight.upsertSpotLight(spotLightId, lightDir, glMatrix.vec3.fromValues(-Math.cos(angle) * 8.0, -Math.sin(angle) * 8.0, -10), glMatrix.vec3.fromValues(0.0, 1.0, 0.0));
+spotlight.refreshBuffer(device);
 
 let lightModelViewMatrix = glMatrix.mat4.lookAt(glMatrix.mat4.create(),
     glMatrix.vec3.fromValues(Math.cos(angle) * 8.0, Math.sin(angle) * 8.0, 10),
     glMatrix.vec3.fromValues(0, 0, 0), glMatrix.vec3.fromValues(0.0, 0.0, 1.0));
 
 let lightModelViewMatrixUniformBufferUpdate = createGPUBuffer(device, lightModelViewMatrix, GPUBufferUsage.COPY_SRC);
-...
-angle += 0.01;  
for the projection matrix of the light, we only need to initialize it once, as the aspect ratio as well as the shadow map's size will not change.
let lightProjectionMatrix = glMatrix.mat4.perspective(glMatrix.mat4.create(),
+
5_01_shadow_maps/index.html:1014-1023 Calculating Rotating Light Direction
For the projection matrix of the light, which does not change frequently, we initialize it only once:
let lightProjectionMatrix = glMatrix.mat4.perspective(glMatrix.mat4.create(),
     Math.acos(0.9) * 2.0, 1.0, 1.0, 100.0);
 
-let lightProjectionMatrixUniformBuffer = createGPUBuffer(device, lightProjectionMatrix, GPUBufferUsage.UNIFORM);
notice that here we are hardcoding the vertical view angle to Math.acos(0.9) * 2.0, this is corresponding to the threshold of 0.9 for visibility in the shader.
next, we will dump this shadow map for visualization:
let copiedBuffer = createGPUBuffer(device, new Float32Array(1024 * 1024), GPUBufferUsage.COPY_DST | GPUBufferUsage.MAP_READ);
-...
-commandEncoder.copyTextureToBuffer({ texture: lightDepthTexture, origin: { x: 0, y: 0 } }, { buffer: copiedBuffer, bytesPerRow: 1024 * 4 }, { width: 1024, height: 1024 });
-...
-await copiedBuffer.mapAsync(GPUMapMode.READ, 0, 1024 * 1024 * 4);
-const d = new Float32Array(copiedBuffer.getMappedRange());
-const x = new Uint8ClampedArray(1024 * 1024 * 4);
-for (let i = 0; i < 1024 * 1024; ++i) {
-    const v = d[i];
-    x[i * 4] = v * 255.0;
-    x[i * 4 + 1] = v * 255.0;
-    x[i * 4 + 2] = v * 255.0;
-    x[i * 4 + 3] = v * 255.0;
-}
-copiedBuffer.unmap();
-const imageData = new ImageData(x, 1024, 1024);
-imagedataToImage(imageData);
here we read back the shadow map into a host copy called copiedBuffer. This buffer is in float32. We then convert this buffer to the uint8 format and convert it to image data.
Show a Dumped Shadow Map
Show a Dumped Shadow Map
Finally, let's see how to use this shadow map in the last step to create shadow. let's look at the shader first.
        var fragmentPosInShadowMapSpace: vec4<f32> = lightProjectionMatrix * lightModelViewMatrix * vec4(in.inPos, 1.0);
-        fragmentPosInShadowMapSpace = fragmentPosInShadowMapSpace / fragmentPosInShadowMapSpace.w;
-        var depth: f32 = fragmentPosInShadowMapSpace.z;
the inPos is the vertex position. Here we calculate the depth as if the light is the camera, i.e. using the light's projection matrix and the light's model view matrix. This is essentially the same formula we have used to calculate the depth in the first shader.
    @group(0) @binding(9)
-    var t_depth: texture_depth_2d;
-    @group(0) @binding(10)
-    var s_depth: sampler_comparison;
-
-       var uv:vec2<f32> = 0.5*(fragmentPosInShadowMapSpace.xy + vec2(1.0,1.0));
-
-        var visibility = 0.0;
-            let oneOverShadowDepthTextureSize = 1.0 / 1024.0;
-            for (var y = -2; y <= 2; y++) {
-              for (var x = -2; x <= 2; x++) {
-                let offset = vec2<f32>(vec2(x, y)) * oneOverShadowDepthTextureSize;
-          
-                visibility += textureSampleCompare(
-                    t_depth, s_depth,
-                    vec2(uv.x, 1.0-uv.y) + offset,depth  - 0.0003
-                );
-              }
-            }
-            visibility /= 25.0;
then, we calculate the uv coordinates. The shadow map space is the same as the screen space when the light is the camera. recall that in the screen space, both x and y are in the range of [-1,1]. However, for uv coordinates, the range is [0,1]. hence, we need to do a transformation:
var uv:vec2<f32> = 0.5*(fragmentPosInShadowMapSpace.xy + vec2(1.0,1.0));
to improve visual quality, instead of simply compare the fragment's depth with the corresponding value, we look at a small neighborhood of 5x5 pixels on the shadow map to get an average value called visibility. as we know, the shadow map is hardcoded to the size 1024x1024, hence the size of a single pixel width and height should be 1.0/1024.0. we use this unit size to calculate an offsetted uv coordinates: vec2(uv.x, 1.0-uv.y) + offset. The reason we want to flip the y coordinate is because that from the top to the bottom edge of the texture map, the v coordinate changes from 0 to 1. whereas in the screen space, y axis is flipped.
one thing that is new to us here is the way we sample the texture map. we are using a comparison sampling textureSampleCompare. this function asks for one more parameter, which is a reference value depth  - 0.0003. the function will compare the texture sampled value to the reference value, and if the comparison passes, it will return 1.0, otherwise 0.0. The exact comparision is specified when we config the sampler in javascript, which we will look at later. Here in this shader, we specify comparision as "less", meaning if the shadow map has a value less than the reference value, it will return 1.0. we look this for all 25 pixels to get an average value. here we apply a small amount of offset to depth: 0.0003. this is again to avoid artifacts due to numerical errors. imagine you want to render a ball under light without any other objects in the scene. In theory, this ball should be lit. if we directly compare the true depth with the shadow map in the shader, and if there is no numerical error at all, the depth should be the same as the shadow map. But in reality, the numerical error will cause some of the fragments to have a depth less than the shadow map, and others have larger depth, resulting in artifacts of random shadow strips. To avoid this, we move the depth a bit forward, so that a surface's depth is always smaller than its own depth value on the shadow map. so it won't be occulted by itself.
finally we color the surface based on the visibility, we calculate the radiance when the two conditions are true: 1. the fragment is under the spot light's frustrum. 2. it is not in shadow.
  if (face) {
-                var wldLoc2light:vec3<f32> =   in.wldLoc-lightLoc;
-                var align:f32 = dot( normalize(wldLoc2light),lightDir);
-
-                if (align > 0.9) {
-                    var radiance:vec3<f32>  = ambientColor.rgb * ambientConstant + 
-                        diffuse(-lightDir, n, diffuseColor.rgb)* diffuseConstant +
-                        specular(-lightDir, viewDir, n, specularColor.rgb, shininess) * specularConstant;
-        
-                    return vec4<f32>(radiance * visibility ,1.0);    
-                }
-        } 
-        return vec4<f32>( 0.0,0.0,0.0,1.0);
Show Image of the Rendering Result
Show Image of the Rendering Result
Now, let's look at if removing some of the tricks we added in the code, what artifacts we will see:
First, if we remove the offsets applied on the back surface:
        if (isFront) {
-            out.depth = in.depth;
+let lightProjectionMatrixUniformBuffer = createGPUBuffer(device, lightProjectionMatrix, GPUBufferUsage.UNIFORM);
+
5_01_shadow_maps/index.html:896-899 Calculate Light Projection Matrix
Here, the vertical view angle is hardcoded as Math.acos(0.9) * 2.0, corresponding to the 0.9 visibility threshold used in the shader.
To visualize the shadow map, we use the following code:
let copiedBuffer = createGPUBuffer(device, new Float32Array(1024 * 1024), GPUBufferUsage.COPY_DST | GPUBufferUsage.MAP_READ);
+
• • •
commandEncoder.copyTextureToBuffer({ texture: lightDepthTexture, origin: { x: 0, y: 0 } }, { buffer: copiedBuffer, bytesPerRow: 1024 * 4 }, { width: 1024, height: 1024 });
+
• • •
if (!hasDumped) {
+    hasDumped = true;
+    await copiedBuffer.mapAsync(GPUMapMode.READ, 0, 1024 * 1024 * 4);
+
+    const d = new Float32Array(copiedBuffer.getMappedRange());
+    const x = new Uint8ClampedArray(1024 * 1024 * 4);
+    let maxv = -900;
+    let minv = 900;
+    for (let i = 0; i < 1024 * 1024; ++i) {
+        const v = d[i];
+
+        if (maxv < v) {
+            maxv = v;
         }
-        else {
-            out.depth = in.depth -0.001;
-        }
Show Image of the Artifacts
Show Image of the Artifacts
(explain)
Second, what if we do not sample the shadow map in a small neighborhood, but a single sample instead?
       var uv:vec2<f32> = 0.5*(fragmentPosInShadowMapSpace.xy + vec2(1.0,1.0));
-
-        var visibility = textureSampleCompare(
-                    t_depth, s_depth,
-                    vec2(uv.x, 1.0-uv.y) ,depth  - 0.0003
-                );
third, what if we remove the 0.0003 hack to avoid self occlusion?
Image Show the Artifacts
Image Show the Artifacts

+        if (minv > v) {
+            minv = v;
+        }
+        x[i * 4] = v * 255.0;
+        x[i * 4 + 1] = v * 255.0;
+        x[i * 4 + 2] = v * 255.0;
+        x[i * 4 + 3] = v * 255.0;
+    }
+    copiedBuffer.unmap();
+    const imageData = new ImageData(x, 1024, 1024);
+    imagedataToImage(imageData);
+    console.log("max min: ", maxv, minv);
+}
+
5_01_shadow_maps/index.html:962-1115 Dumping Shadow Map

This code reads the shadow map from the GPU into a buffer called copiedBuffer, which is initially in Float32 format. It then converts this data to Uint8 format for visualization. The resulting ImageData is used to create an image for further analysis.

Shadow Map From a Light's View
Shadow Map From a Light's View

In the final step, we use the shadow map to create shadows. Let's first examine the shader code responsible for this:

var fragmentPosInShadowMapSpace: vec4<f32> = lightProjectionMatrix * lightModelViewMatrix * vec4(in.inPos, 1.0);
+fragmentPosInShadowMapSpace = fragmentPosInShadowMapSpace / fragmentPosInShadowMapSpace.w;
+var depth: f32 = fragmentPosInShadowMapSpace.z;
+
5_01_shadow_maps/index.html:117-119 Calculating Fragment Position in Shadow Map

Here, inPos represents the vertex position. We calculate the depth from the light's perspective using the light's projection and model-view matrices. This approach mirrors the depth calculation method used previously in the shader.

var uv:vec2<f32> = 0.5*(fragmentPosInShadowMapSpace.xy + vec2(1.0,1.0));
+
+var visibility = 0.0;
+    let oneOverShadowDepthTextureSize = 1.0 / 1024.0;
+    for (var y = -2; y <= 2; y++) {
+      for (var x = -2; x <= 2; x++) {
+        let offset = vec2<f32>(vec2(x, y)) * oneOverShadowDepthTextureSize;
+  
+        visibility += textureSampleCompare(
+            t_depth, s_depth,
+            vec2(uv.x, 1.0-uv.y) + offset,depth  - 0.0003
+        );
+      }
+    }
+    visibility /= 25.0;
+
5_01_shadow_maps/index.html:120-134 Calculating Fragment Visibility

The uv coordinates are calculated from fragmentPosInShadowMapSpace, transforming them from [-1, 1] range to [0, 1] range.

To enhance visual quality, rather than directly comparing a fragment's depth with the corresponding value in the shadow map, we sample a 5x5 pixel neighborhood around the fragment’s position to compute an average visibility. The shadow map is fixed at 1024x1024 pixels, so each pixel's width and height is 1.0 / 1024.0. We use this unit size to adjust the UV coordinates with an offset, transforming the coordinates using: vec2(uv.x, 1.0-uv.y) + offset. This adjustment flips the y-coordinate because, in the texture map, the v-coordinate ranges from 0 to 1 from top to bottom, whereas in screen space, the y-axis is flipped.

The texture sampling uses a comparison function called textureSampleCompare. This function requires an additional reference value, depth - 0.0003, for comparison. If the depth value in the shadow map is less than this reference value, the function returns 1.0; otherwise, it returns 0.0. This comparison method is configured in the JavaScript code, which we will review later. In the shader, the comparison is set to "less," meaning a sample value less than the reference will pass the comparison.

The use of a small offset (0.0003) is crucial for preventing artifacts caused by numerical errors. For instance, if a ball is illuminated and no other objects are present, the ball should ideally be lit. However, due to numerical errors, some fragments may have depths that are either less than or greater than those in the shadow map, leading to random shadow artifacts. By adjusting the depth slightly forward, we ensure that the surface’s depth is always smaller than its own depth value in the shadow map, preventing self-occlusion.

Finally, we determine the surface color based on visibility. The radiance calculation occurs only if two conditions are met: the fragment is within the spot light's frustum, and it is not in shadow.

if (face) {
+    var wldLoc2light:vec3<f32> =   in.wldLoc-lightLoc;
+    if (align > 0.9) {
+        var radiance:vec3<f32>  = ambientColor.rgb * ambientConstant + 
+            diffuse(-lightDir, n, diffuseColor.rgb)* diffuseConstant +
+            specular(-lightDir, viewDir, n, specularColor.rgb, shininess) * specularConstant;
+
+        return vec4<f32>(radiance * visibility ,1.0);
+    }
+} 
+return vec4<f32>( 0.0,0.0,0.0,1.0);
+
5_01_shadow_maps/index.html:135-145 Spot Light Shader

The Final Rendering Result
The Final Rendering Result

Let’s explore the impact of removing some of the adjustments we've made in the code and the resulting artifacts.

Firstly, removing the offset applied to the depth for back-facing surfaces:

if (isFront) {
+    out.depth = in.depth;
+}
+else {
+    out.depth = in.depth -0.001;
+}
+
5_01_shadow_maps/index.html:181-186 Applying a Small Depth Offset to Back-Facing Surfaces

Band Artifacts Are Visible if We Don't Offset Back-Facing Surfaces
Band Artifacts Are Visible if We Don't Offset Back-Facing Surfaces

When the offset is removed, back-facing surfaces use the same depth value as front-facing surfaces. This can lead to visual artifacts because the depth test may incorrectly consider some back-facing fragments as nearer than they actually are, resulting in unexpected shadowing or light leakage. The artifact image illustrates these issues clearly.

var uv:vec2<f32> = 0.5*(fragmentPosInShadowMapSpace.xy + vec2(1.0,1.0));
+
+var visibility = 0.0;
+    let oneOverShadowDepthTextureSize = 1.0 / 1024.0;
+    for (var y = -2; y <= 2; y++) {
+      for (var x = -2; x <= 2; x++) {
+        let offset = vec2<f32>(vec2(x, y)) * oneOverShadowDepthTextureSize;
+  
+        visibility += textureSampleCompare(
+            t_depth, s_depth,
+            vec2(uv.x, 1.0-uv.y) + offset,depth  - 0.0003
+        );
+      }
+    }
+    visibility /= 25.0;
+
5_01_shadow_maps/index.html:120-134 Calculating Fragment Visibility

Secondly, if we sample the shadow map using only a single sample instead of averaging a neighborhood, the depth comparison is performed directly without smoothing:

Artifacts When Only Sampling Shadowmap Once
Artifacts When Only Sampling Shadowmap Once

Using a single sample can introduce significant aliasing and noise, especially in areas with complex shadow details. The lack of neighborhood averaging means that small variations in depth can cause inconsistent shadowing, leading to a more pixelated and less smooth shadow effect, as shown in the artifact image.

Lastly, removing the 0.0003 hack that offsets the depth to avoid self-occlusion:

Artifacts the 0.0003 Depth Access Hack
Artifacts the 0.0003 Depth Access Hack

Without this offset, the depth comparison might fail in cases where the depth values from the fragment and the shadow map are very close but not identical due to numerical precision issues. This can cause artifacts where parts of the surface incorrectly appear shadowed or illuminated, as the fragment's depth could inadvertently be considered to be behind itself in the shadow map, leading to incorrect self-shadowing effects. The artifact image highlights these issues where surfaces appear improperly shadowed or lit.

diff --git a/Advanced/spotlight.png b/Advanced/spotlight.png new file mode 100644 index 0000000..a1db376 Binary files /dev/null and b/Advanced/spotlight.png differ diff --git a/Advanced/spotlight_shadowmap.png b/Advanced/spotlight_shadowmap.png new file mode 100644 index 0000000..8de6122 Binary files /dev/null and b/Advanced/spotlight_shadowmap.png differ diff --git a/Advanced/stencil_buffer.html b/Advanced/stencil_buffer.html index 5e28495..bb5ff20 100644 --- a/Advanced/stencil_buffer.html +++ b/Advanced/stencil_buffer.html @@ -142,8 +142,8 @@
-

5.0 Stencil Buffer

The stencil buffer is closely related to the depth buffer. When stencil testing is enabled, the rendering pipeline performs a visibility test based on the contents of the stencil buffer. The exact formula for visibility testing can be confirmed through configuration. Typically, this process involves two passes: the first pass populates the stencil buffer, while the second pass handles the actual rendering. Only the portions of the scene that pass the visibility test will be rendered.

Launch Playground - 2_01_orthogonal_cameras

The stencil buffer is particularly useful for creating certain effects in games, such as mirrors or portals. For example, to render a mirror effect, you first draw the mirror's shape into the stencil buffer. Then, with stencil testing enabled, you render the scene from the perspective of the mirror. Many intriguing illusion games, such as the Non-Euclidean Worlds Engine, leverage advanced stencil buffer techniques.

As mentioned earlier, using the stencil buffer typically involves two passes. The first pass populates the stencil buffer, which may seem counterintuitive because you cannot directly write to the stencil buffer in the fragment shader. Instead, the stencil buffer is populated as a byproduct of rendering, similar to the depth buffer. The values written to the stencil buffer are preconfigured.

In this tutorial, we will create a simple portal effect akin to the Non-Euclidean Worlds Engine project. The concept is straightforward: we first render a virtual gateway, which is a simple plane, to populate the stencil buffer. Next, we render the scene with stencil visibility testing enabled. Finally, we render the frame of the gateway.

Gateway 3D Model
Gateway 3D Model

Let's first examine the shader code used to populate the stencil buffer. This shader is designed to be as simple as possible. It calculates the clip coordinates and renders the object as transparent pixels. The goal here is not to render anything visible but to generate stencil values. Similar to the depth buffer, stencil buffer writing is enabled so that whenever a fragment is produced, a stencil value is also cached into the stencil buffer.

@group(0) @binding(0)
+            
5.0 Stencil Buffer
The stencil buffer is closely related to the depth buffer. When stencil testing is enabled, the rendering pipeline performs a visibility test based on the contents of the stencil buffer. The exact formula for visibility testing can be confirmed through configuration. Typically, this process involves two passes: the first pass populates the stencil buffer, while the second pass handles the actual rendering. Only the portions of the scene that pass the visibility test will be rendered.
Launch Playground - 5_00_stencil
The stencil buffer is particularly useful for creating certain effects in games, such as mirrors or portals. For example, to render a mirror effect, you first draw the mirror's shape into the stencil buffer. Then, with stencil testing enabled, you render the scene from the perspective of the mirror. Many intriguing illusion games, such as the Non-Euclidean Worlds Engine, leverage advanced stencil buffer techniques.
As mentioned earlier, using the stencil buffer typically involves two passes. The first pass populates the stencil buffer, which may seem counterintuitive because you cannot directly write to the stencil buffer in the fragment shader. Instead, the stencil buffer is populated as a byproduct of rendering, similar to the depth buffer. The values written to the stencil buffer are preconfigured.
In this tutorial, we will create a simple portal effect akin to the Non-Euclidean Worlds Engine project. The concept is straightforward: we first render a virtual gateway, which is a simple plane, to populate the stencil buffer. Next, we render the scene with stencil visibility testing enabled. Finally, we render the frame of the gateway.
Gateway 3D Model
Gateway 3D Model
Let's first examine the shader code used to populate the stencil buffer. This shader is designed to be as simple as possible. It calculates the clip coordinates and renders the object as transparent pixels. The goal here is not to render anything visible but to generate stencil values. Similar to the depth buffer, stencil buffer writing is enabled so that whenever a fragment is produced, a stencil value is also cached into the stencil buffer.
@group(0) @binding(0)
 var<uniform> modelView: mat4x4<f32>;
 @group(0) @binding(1)
 var<uniform> projection: mat4x4<f32>;
diff --git a/Advanced/thumb_Plate.png b/Advanced/thumb_Plate.png
new file mode 100644
index 0000000..f78b3ef
Binary files /dev/null and b/Advanced/thumb_Plate.png differ
diff --git a/Advanced/thumb_artifacts_removeaccessoffset.png b/Advanced/thumb_artifacts_removeaccessoffset.png
new file mode 100644
index 0000000..3f62db3
Binary files /dev/null and b/Advanced/thumb_artifacts_removeaccessoffset.png differ
diff --git a/Advanced/thumb_artifacts_sampleonce.png b/Advanced/thumb_artifacts_sampleonce.png
new file mode 100644
index 0000000..1b1e128
Binary files /dev/null and b/Advanced/thumb_artifacts_sampleonce.png differ
diff --git a/Advanced/thumb_bandartifacts.png b/Advanced/thumb_bandartifacts.png
new file mode 100644
index 0000000..d11cea3
Binary files /dev/null and b/Advanced/thumb_bandartifacts.png differ
diff --git a/Advanced/thumb_equirectangular.png b/Advanced/thumb_equirectangular.png
new file mode 100644
index 0000000..93add6f
Binary files /dev/null and b/Advanced/thumb_equirectangular.png differ
diff --git a/Advanced/thumb_equirectangular_result.png b/Advanced/thumb_equirectangular_result.png
new file mode 100644
index 0000000..46677b5
Binary files /dev/null and b/Advanced/thumb_equirectangular_result.png differ
diff --git a/Advanced/thumb_parking_lot.jpg b/Advanced/thumb_parking_lot.jpg
new file mode 100644
index 0000000..4b9e4f0
Binary files /dev/null and b/Advanced/thumb_parking_lot.jpg differ
diff --git a/Advanced/thumb_spotlight.png b/Advanced/thumb_spotlight.png
new file mode 100644
index 0000000..6fbf093
Binary files /dev/null and b/Advanced/thumb_spotlight.png differ
diff --git a/Advanced/thumb_spotlight_shadowmap.png b/Advanced/thumb_spotlight_shadowmap.png
new file mode 100644
index 0000000..306e490
Binary files /dev/null and b/Advanced/thumb_spotlight_shadowmap.png differ
diff --git a/Advanced/toon_shading.html b/Advanced/toon_shading.html
index 579b297..a979861 100644
--- a/Advanced/toon_shading.html
+++ b/Advanced/toon_shading.html
@@ -142,7 +142,8 @@
 
     

         

-            
5.2 Toon Shading
Rendering realism is not always the goal in graphics. Artistic styles, such as painting or cartoon-like effects, can be equally compelling. In this tutorial, we will explore a simple cartoon-style rendering technique.
Specifically, we will focus on implementing two effects: first, adding a silhouette to a model, and second, adjusting the shader to create a painterly style where colors don’t change gradually.
Let's start with the silhouette. There are several methods to achieve this effect, each with its own pros and cons. One method involves detecting discontinuities in screen space. This approach requires rendering the scene first with additional metadata, such as surface normals, depth, and colors. In a second pass, these properties are analyzed to detect discontinuities, which are then highlighted as silhouettes. While effective, this method can be resource-intensive and sensitive to the size of objects in the image space.
In this tutorial, we'll use a simpler approach: enlarging the object slightly and flipping it inside out. The enlarged object is shaded in pure black to create the silhouette effect. This method avoids the need for expensive screen-space post-processing and is commonly used in games due to its efficiency.
Enlarging an object can be achieved by offsetting each vertex away from the object's center by a fixed percentage. While this approach works well for roughly spherical objects, it can produce less satisfactory results for long or complex shapes. In such cases, areas further from the center may stretch more than those closer, leading to imperfect silhouettes.
Artifacts by Enlarging Objects
Artifacts by Enlarging Objects[SOURCE]
A better approach is to inflate the object at each vertex along the vertex normal. It's important to use the vertex normal rather than the surface normal for this process. The vertex normal is computed by averaging the adjacent surface normals, which provides a smoother and more accurate result for sharp features. If you were to use the surface normal directly, you might introduce artifacts, as surfaces sharing the same vertex may not align perfectly. Using vertex normals helps to minimize these artifacts and achieve a more consistent silhouette.
Artifact of Inflating Objects Using the Surface Normal
Artifact of Inflating Objects Using the Surface Normal[SOURCE]
However, this method does come with its own drawback: the silhouette's appearance is sensitive to the viewing distance. When close to the object, the silhouette may appear overly thick, while from a distance, it might become too thin and less noticeable. This variation in silhouette thickness can affect the overall visual impact of the cartoon-style rendering.
Artifact When Being Viewed Closely
Artifact When Being Viewed Closely[SOURCE]
What we want is a uniformly wide silhouette that remains consistent regardless of the viewing angle and distance. This can be achieved by working in clip space. Our approach involves projecting the vertex normals onto the clip plane, and then, in clip space, offsetting the vertex positions based on these normals. Since both the vertex normal and vertex position are in 2D in clip space, and this step occurs after the perspective projection, the silhouette thickness remains unaffected by the viewing angle or distance.
To summarize, rendering a silhouette involves two key steps. First, render the slightly inflated object in black or the silhouette color, and then render the original object on top. There are two methods to achieve this:
In the first method, use two passes. During the first pass, render the inflated object in the silhouette color but without writing to the depth buffer. This ensures that the inflated object, being larger, does not occlude the normal object. In the second pass, render the object normally on top of the silhouette.
The second method is simpler but less intuitive. Flip the inflated object inside out and render only its back faces in the silhouette color, while simultaneously rendering the object normally with depth testing enabled. By flipping the object, the front side of the inflated object is effectively peeled away, ensuring it does not occlude the normally rendered object. This method allows for achieving the silhouette effect in a single rendering pass.
Let's dive into the implementation:
@group(0) @binding(0)
+            
5.2 Toon Shading
Rendering realism is not always the goal in graphics. Artistic styles, such as painting or cartoon-like effects, can be equally compelling. In this tutorial, we will explore a simple cartoon-style rendering technique.
Launch Playground - 5_02_toon_shading
Specifically, we will focus on implementing two effects: first, adding a silhouette to a model, and second, adjusting the shader to create a painterly style where colors don’t change gradually.
Let's start with the silhouette. There are several methods to achieve this effect, each with its own pros and cons. One method involves detecting discontinuities in screen space. This approach requires rendering the scene first with additional metadata, such as surface normals, depth, and colors. In a second pass, these properties are analyzed to detect discontinuities, which are then highlighted as silhouettes. While effective, this method can be resource-intensive and sensitive to the size of objects in the image space.
In this tutorial, we'll use a simpler approach: enlarging the object slightly and flipping it inside out. The enlarged object is shaded in pure black to create the silhouette effect. This method avoids the need for expensive screen-space post-processing and is commonly used in games due to its efficiency.
Enlarging an object can be achieved by offsetting each vertex away from the object's center by a fixed percentage. While this approach works well for roughly spherical objects, it can produce less satisfactory results for long or complex shapes. In such cases, areas further from the center may stretch more than those closer, leading to imperfect silhouettes.
Artifacts by Enlarging Objects
Artifacts by Enlarging Objects[SOURCE]
A better approach is to inflate the object at each vertex along the vertex normal. It's important to use the vertex normal rather than the surface normal for this process. The vertex normal is computed by averaging the adjacent surface normals, which provides a smoother and more accurate result for sharp features. If you were to use the surface normal directly, you might introduce artifacts, as surfaces sharing the same vertex may not align perfectly. Using vertex normals helps to minimize these artifacts and achieve a more consistent silhouette.
Artifact of Inflating Objects Using the Surface Normal
Artifact of Inflating Objects Using the Surface Normal[SOURCE]
However, this method does come with its own drawback: the silhouette's appearance is sensitive to the viewing distance. When close to the object, the silhouette may appear overly thick, while from a distance, it might become too thin and less noticeable. This variation in silhouette thickness can affect the overall visual impact of the cartoon-style rendering.
Artifact When Being Viewed Closely
Artifact When Being Viewed Closely[SOURCE]
What we want is a uniformly wide silhouette that remains consistent regardless of the viewing angle and distance. This can be achieved by working in clip space. Our approach involves projecting the vertex normals onto the clip plane, and then, in clip space, offsetting the vertex positions based on these normals. Since both the vertex normal and vertex position are in 2D in clip space, and this step occurs after the perspective projection, the silhouette thickness remains unaffected by the viewing angle or distance.
To summarize, rendering a silhouette involves two key steps. First, render the slightly inflated object in black or the silhouette color, and then render the original object on top. There are two methods to achieve this:
In the first method, use two passes. During the first pass, render the inflated object in the silhouette color but without writing to the depth buffer. This ensures that the inflated object, being larger, does not occlude the normal object. In the second pass, render the object normally on top of the silhouette.
The second method is simpler but less intuitive. Flip the inflated object inside out and render only its back faces in the silhouette color, while simultaneously rendering the object normally with depth testing enabled. By flipping the object, the front side of the inflated object is effectively peeled away, ensuring it does not occlude the normally rendered object. This method allows for achieving the silhouette effect in a single rendering pass.
Let's dive into the implementation:
@group(0) @binding(0)
 var<uniform> modelView: mat4x4<f32>;
 @group(0) @binding(1)
 var<uniform> projection: mat4x4<f32>;
diff --git a/code/5_01_shadow_maps/index.html b/code/5_01_shadow_maps/index.html
index 674c59c..6457374 100644
--- a/code/5_01_shadow_maps/index.html
+++ b/code/5_01_shadow_maps/index.html
@@ -95,7 +95,6 @@
         out.inPos = inPos;
         var lightLoc:vec4 = modelView * vec4(lightDirection, 1.0);
         out.lightLoc = lightLoc.xyz / lightLoc.w;
-
         return out;
     }
     
@@ -115,7 +114,6 @@
         var lightDir:vec3 = normalize(in.lightDir);
         var n:vec3 = normalize(in.normal);
         var viewDir: vec3 = in.viewDir;
-
         var fragmentPosInShadowMapSpace: vec4 = lightProjectionMatrix * lightModelViewMatrix * vec4(in.inPos, 1.0);
         fragmentPosInShadowMapSpace = fragmentPosInShadowMapSpace / fragmentPosInShadowMapSpace.w;
         var depth: f32 = fragmentPosInShadowMapSpace.z;
@@ -134,29 +132,15 @@
               }
             }
             visibility /= 25.0;
-
-
-        //var light2ClosestSurfaceDist = textureSample(t_depth, s_depth, vec2(uv.x, 1.0-uv.y));
         if (face) {
-            //if (depth < light2ClosestSurfaceDist+0.0001) {
-
-                var wldLoc2light:vec3 =   in.wldLoc-lightLoc;
-
-                //var lightDir:vec3 =  
-                var align:f32 = dot( normalize(wldLoc2light),lightDir);
-
-                if (align > 0.9) {
-                    var radiance:vec3  = ambientColor.rgb * ambientConstant + 
-                        diffuse(-lightDir, n, diffuseColor.rgb)* diffuseConstant +
-                        specular(-lightDir, viewDir, n, specularColor.rgb, shininess) * specularConstant;
+            var wldLoc2light:vec3 =   in.wldLoc-lightLoc;
+            if (align > 0.9) {
+                var radiance:vec3  = ambientColor.rgb * ambientConstant + 
+                    diffuse(-lightDir, n, diffuseColor.rgb)* diffuseConstant +
+                    specular(-lightDir, viewDir, n, specularColor.rgb, shininess) * specularConstant;
         
-                    return vec4(radiance * visibility ,1.0);
-                   // return vec4(0.0,0.0,light2ClosestSurfaceDist,1.0);
-                }
-
-                //return vec4(1.0,1.0,0.0,1.0);
-            //}
-          
+                return vec4(radiance * visibility ,1.0);
+            }
         } 
         return vec4( 0.0,0.0,0.0,1.0);
     }
@@ -164,7 +148,6 @@