The explanation for projection is inconsistent

[saccharineboi]

In Implementing Cameras, the following is written:

The primary objective of perspective projection is to transform this trapezoidal frustum into a cuboid

Followed by:

This resulting cuboid exists in what we call Normalized Device Coordinates (NDC).

Then followed by:

Even though:

I think here you confused NDC and the clip coordinates (note the inconsistency in the last two images). The projection matrix doesn't output the vertex positions in NDC, instead it outputs them in homogeneous clip coordinates, which then through perspective-divide (i.e. divide by w) become coordinates in the NDC space. So it should be: LOCAL -> WORLD -> VIEW -> CLIP -> NDC -> VIEWPORT.

[shi-yan]

You are right. Thank you very much for pointing this out! I will fix the text.

[saccharineboi]

Hi @shi-yan I hope you are doing well, there is another problem in the next chapter, although this issue is more incomplete than inconsistent:

For MSAA to work, one also needs to add the property multisample (which is an object containing the property count: 4) to GPURenderPipelineDescriptor. Here's a sample code from my own project:

    const pipelineDesc: GPURenderPipelineDescriptor = {
        layout: pipelineLayout,
        vertex: {
            module: basicShaderModule,
            entryPoint: "vs_main",
            buffers: [vertexBufferLayoutDesc]
        },
        fragment: {
            module: basicShaderModule,
            entryPoint: "fs_main",
            targets: [colorState]
        },
        primitive: {
            topology: "triangle-list",
            frontFace: "ccw",
            cullMode: "back"
        },
        depthStencil: {
            depthWriteEnabled: true,
            depthCompare: "greater-equal",
            format: "depth32float",
        },
        // This is required for multisampling to work
        multisample: {
            count: 4
        }
    };

Also, in the chapter you write:

The concept behind MSAA is straightforward: we first render the result with four samples for each pixel.

Reading the above gives the impression that the fragment shader is executed for each sample—which isn't the case. I think it would be better here to clarify to the reader that the fragment shader is executed only once for each pixel, but the output is stored in a bigger buffer that saves the color of each sample, which is then resolved (downscaled).

If you don't have time, I can send the PRs to fix these issues, and a copyright release form in case you may be interested in turning the website to a book.