009: impl Vertex for ModelVertex was using the vertex_attr_array! macro.
009: RenderPipelineDescriptor has a `vertex` member not `vertex_state`.
009: to_rgba() should be to_rgba8(), to_rgba is set to be deprecated.
010: BindGroupDescriptor has a `entries` member not `bindings`.
010: Remove re-declaration of mat4 model_matrix;
010: Prefer hard-coded [#.#; #] instead of `Foo::fn().into()`.
010: Clarify which shader frag/vert file changes are in.
011: Change Model::load return type to Result<Self>.
011: TextureDescriptor does not have a array_layer_count member.
012: Add .into() to calls in Uniforms::update_view_proj().
012: Dereference delta variable in State::input().
013: Add more changed lines to Model::load to avoid compiler yelling.
@ -145,10 +158,10 @@ While we're at it let's import `texture.rs` in `model.rs`.
use crate::texture;
```
We also need to make a subtle change on `from_image()` method in `texture.rs`. PNGs work fine with `as_rgba8()`, as they have an alpha channel. But, JPEGs don't have an alpha channel, and the code would panic if we try to call `as_rgba8()` on the JPEG texture image we are going to use. Instead, we can use `to_rgba()` to handle such an image.
We also need to make a subtle change on `from_image()` method in `texture.rs`. PNGs work fine with `as_rgba8()`, as they have an alpha channel. But, JPEGs don't have an alpha channel, and the code would panic if we try to call `as_rgba8()` on the JPEG texture image we are going to use. Instead, we can use `to_rgba8()` to handle such an image.
```rust
let rgba = img.to_rgba();
let rgba = img.to_rgba8();
```
`Mesh` holds a vertex buffer, an index buffer, and the number of indices in the mesh. We're using an `usize` for the material. This `usize` will be used to index the `materials` list when it comes time to draw.
@ -284,6 +297,7 @@ We could have put this methods in `impl Model`, but I felt it made more sense to
With all that we'll end up with something like this.
@ -470,7 +494,7 @@ With that we should get something like the this.
## Diffuse Lighting
Remember the normal vectors that were included with our model? We're finally going to use them. Normals represent the direction a surface is facing. By comparing the normal of a fragment with a vector pointing to a light source, we get a value of how light/dark that fragment should be. We compare the vector be using the dot product to get the cosine of the angle between them.
Remember the normal vectors that were included with our model? We're finally going to use them. Normals represent the direction a surface is facing. By comparing the normal of a fragment with a vector pointing to a light source, we get a value of how light/dark that fragment should be. We compare the vector using the dot product to get the cosine of the angle between them.
@ -495,7 +519,8 @@ For now let's just pass the normal directly as is. This is wrong, but we'll fix
@ -687,6 +709,7 @@ If we just look at the `specular_color` on it's own we get this.
Up to this point we've actually only implemented the Phong part of Blinn-Phong. The Phong reflection model works well, but it can break down under [certain circumstances](https://learnopengl.com/Advanced-Lighting/Advanced-Lighting). The Blinn part of Blinn-Phong comes from the realization that if you add the `view_dir`, and `light_dir` together, normalize the result and use the dot product of that and the `normal`, you get roughly the same results without the issues that using `reflect_dir` had.
With just lighting, our scene is already looking pretty good. Still, our models are still overly smooth. This is understandable because we are using a very simple model. If we were using a texture that was supposed to be smooth, this wouldn't be a problem, but our brick texture is supposed to be rougher. We could solve this by adding more geometry, but that would slow our scene down, and it would hard to know where to add new polygons. This is were normal mapping comes in.
With just lighting, our scene is already looking pretty good. Still, our models are still overly smooth. This is understandable because we are using a very simple model. If we were using a texture that was supposed to be smooth, this wouldn't be a problem, but our brick texture is supposed to be rougher. We could solve this by adding more geometry, but that would slow our scene down, and it be would hard to know where to add new polygons. This is were normal mapping comes in.
Remember in [the instancing tutorial](/beginner/tutorial7-instancing/#a-different-way-textures), we experimented with storing instance data in a texture? A normal map is doing just that with normal data! We'll use the normals in the normal map in our lighting calculation in addition to the vertex normal.
@ -52,7 +52,7 @@ let texture_bind_group_layout = device.create_bind_group_layout(&wgpu::BindGroup
});
```
We'll need to actually the normal map itself. We'll do this in the loop we create the materials in.
We'll need to actually load the normal map. We'll do this in the loop we create the materials in.
```rust
let diffuse_path = mat.diffuse_texture;
@ -63,7 +63,7 @@ We'll need to actually the normal map itself. We'll do this in the loop we creat
```
* Note: I duplicated and moved teh `command_buffers.push(cmds);` line. This means we can reuse the `cmds` variable for both the normal map and diffuse/color map.
* Note: I duplicated and moved the`command_buffers.push(cmds);` line. This means we can reuse the `cmds` variable for both the normal map and diffuse/color map.
Our `Material`'s `bind_group` will have to change as well.
Elijah C. Voigt
3 years ago