Archives/learn-wgpu
2
0
Fork 0
mirror of https://github.com/sotrh/learn-wgpu.git synced 2024-11-16 06:12:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #95 from okaneco/beg-fixes

Browse Source 
Fix typos and update Beginner tutorials 2, 3
This commit is contained in:
sotrh 2020-09-28 15:13:46 -06:00 committed by GitHub
commit 709936e647
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 30 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/beginner/tutorial2-swapchain/README.md
View File

@ -17,23 +17,23 @@ struct State {
impl State { impl State {
// Creating some of the wgpu types requires async code // Creating some of the wgpu types requires async code
async fn new(window: &Window) -> Self { async fn new(window: &Window) -> Self {
unimplemented!() todo!()
} }
fn resize(&mut self, new_size: winit::dpi::PhysicalSize<u32>) { fn resize(&mut self, new_size: winit::dpi::PhysicalSize<u32>) {
unimplemented!() todo!()
} }
fn input(&mut self, event: &WindowEvent) -> bool { fn input(&mut self, event: &WindowEvent) -> bool {
unimplemented!() todo!()
} }
fn update(&mut self) { fn update(&mut self) {
unimplemented!() todo!()
} }
fn render(&mut self) { fn render(&mut self) {
unimplemented!() todo!()
} }
} }
``` ```
@ -249,7 +249,7 @@ We don't have anything to update yet, so leave the method empty.
```rust ```rust
fn update(&mut self) { fn update(&mut self) {
// remove `unimplemented!()` // remove `todo!()`
} }
``` ```
@ -367,11 +367,11 @@ wgpu::RenderPassColorAttachmentDescriptor {
} }
``` ```
The `RenderPassColorAttachmentDescriptor` has the `attachment` field which informs `wgpu` what texture to save the colors to. In this case we specify `frame.view` that we created using `swap_chain.get_next_texture()`. This means that any colors we draw to this attachment will get drawn to the screen. The `RenderPassColorAttachmentDescriptor` has the `attachment` field which informs `wgpu` what texture to save the colors to. In this case we specify `frame.view` that we created using `swap_chain.get_current_frame()`. This means that any colors we draw to this attachment will get drawn to the screen.
This is the texture that will received the resolved output. This will be the same as `attachment` unless multisampling is enabled. We don't need to specify this, so we leave it as `None`. This is the texture that will receive the resolved output. This will be the same as `attachment` unless multisampling is enabled. We don't need to specify this, so we leave it as `None`.
The `obs` field takes an `wpgu::Operations` object. This tells wgpu what to do with the colors on the screen (specified by `frame.view`). The `load` field tells wgpu how to handle colors store from the previous frame. Currently we are clearing the screen with a bluish color. The `ops` field takes a `wpgu::Operations` object. This tells wgpu what to do with the colors on the screen (specified by `frame.view`). The `load` field tells wgpu how to handle colors stored from the previous frame. Currently we are clearing the screen with a bluish color.
<div class="note"> <div class="note">
@ -383,6 +383,6 @@ It's not uncommon to not clear the screen if the streen is going to be completel
## Challenge ## Challenge
Modify the `input()` method to capture mouse events, and update the clear color using that. *Hint: you'll probably need to use `WindowEvent::CursorMoved`* Modify the `input()` method to capture mouse events, and update the clear color using that. *Hint: you'll probably need to use `WindowEvent::CursorMoved`*.
<AutoGithubLink/> <AutoGithubLink/>

17
docs/beginner/tutorial3-pipeline/README.md
View File

@ -117,9 +117,12 @@ let fs_module = device.create_shader_module(wgpu::util::make_spirv(&fs_spirv.as_
One more thing, we need to create a `PipelineLayout`. We'll get more into this after we cover `Buffer`s. One more thing, we need to create a `PipelineLayout`. We'll get more into this after we cover `Buffer`s.
```rust ```rust
let render_pipeline_layout = device.create_pipeline_layout(&wgpu::PipelineLayoutDescriptor { let render_pipeline_layout =
bind_group_layouts: &[], device.create_pipeline_layout(&wgpu::PipelineLayoutDescriptor {
}); label: Some("Render Pipeline Layout"),
bind_group_layouts: &[],
push_constant_ranges: &[],
});
``` ```
Finally we have all we need to create the `render_pipeline`. Finally we have all we need to create the `render_pipeline`.
@ -136,6 +139,7 @@ let render_pipeline = device.create_render_pipeline(&wgpu::RenderPipelineDescrip
module: &fs_module, module: &fs_module,
entry_point: "main", entry_point: "main",
}), }),
// continued ...
``` ```
Two things to note here: Two things to note here:
@ -143,7 +147,6 @@ Two things to note here:
2. The `fragment_stage` is technically optional, so you have to wrap it in `Some()`. I've never used a vertex shader without a fragment shader, but the option is available if you need it. 2. The `fragment_stage` is technically optional, so you have to wrap it in `Some()`. I've never used a vertex shader without a fragment shader, but the option is available if you need it.
```rust ```rust
// continued ...
rasterization_state: Some( rasterization_state: Some(
wgpu::RasterizationStateDescriptor { wgpu::RasterizationStateDescriptor {
front_face: wgpu::FrontFace::Ccw, front_face: wgpu::FrontFace::Ccw,
@ -154,6 +157,7 @@ Two things to note here:
clamp_depth: false, clamp_depth: false,
} }
), ),
// continued ...
``` ```
`rasterization_state` describes how to process primitives (in our case triangles) before they are sent to the fragment shader (or the next stage in the pipeline if there is none). Primitives that don't meet the criteria are *culled* (aka not rendered). Culling helps speed up the rendering process by not rendering things that should not be visible anyway. `rasterization_state` describes how to process primitives (in our case triangles) before they are sent to the fragment shader (or the next stage in the pipeline if there is none). Primitives that don't meet the criteria are *culled* (aka not rendered). Culling helps speed up the rendering process by not rendering things that should not be visible anyway.
@ -161,7 +165,6 @@ Two things to note here:
We'll cover culling a bit more when we cover `Buffer`s. We'll cover culling a bit more when we cover `Buffer`s.
```rust ```rust
// continued ...
color_states: &[ color_states: &[
wgpu::ColorStateDescriptor { wgpu::ColorStateDescriptor {
format: sc_desc.format, format: sc_desc.format,
@ -170,11 +173,11 @@ We'll cover culling a bit more when we cover `Buffer`s.
write_mask: wgpu::ColorWrite::ALL, write_mask: wgpu::ColorWrite::ALL,
}, },
], ],
// continued ...
``` ```
A `color_state` describes how colors are stored and processed throughout the pipeline. You can have multiple color states, but we only need one as we're just drawing to the screen. We use the `swap_chain`'s format so that copying to it is easy, and we specify that the blending should just replace old pixel data with new data. We also tell `wgpu` to write to all colors: red, blue, green, and alpha. *We'll talk more about*`color_state` *when we talk about textures.* A `color_state` describes how colors are stored and processed throughout the pipeline. You can have multiple color states, but we only need one as we're just drawing to the screen. We use the `swap_chain`'s format so that copying to it is easy, and we specify that the blending should just replace old pixel data with new data. We also tell `wgpu` to write to all colors: red, blue, green, and alpha. *We'll talk more about*`color_state` *when we talk about textures.*
```rust ```rust
// continued ...
primitive_topology: wgpu::PrimitiveTopology::TriangleList, // 1. primitive_topology: wgpu::PrimitiveTopology::TriangleList, // 1.
depth_stencil_state: None, // 2. depth_stencil_state: None, // 2.
vertex_state: wgpu::VertexStateDescriptor { vertex_state: wgpu::VertexStateDescriptor {
@ -382,6 +385,6 @@ I'm glossing over the code in the build script as this guide is focused on wgpu
</div> </div>
## Challenge ## Challenge
Create a second pipeline that uses the triangle's position data to create a color that it then sends to the fragment shader to use for `f_color`. Have the app swap between these when you press the spacebar. *Hint: use*`in`*and*`out`*variables in a separate shader.* Create a second pipeline that uses the triangle's position data to create a color that it then sends to the fragment shader to use for `f_color`. Have the app swap between these when you press the spacebar. *Hint: use* `in` *and* `out` *variables in a separate shader.*
<AutoGithubLink/> <AutoGithubLink/>

2
docs/beginner/tutorial9-models/README.md
View File

@ -20,7 +20,7 @@ pub struct ModelVertex {
impl Vertex for ModelVertex { impl Vertex for ModelVertex {
fn desc<'a>() -> wgpu::VertexBufferDescriptor<'a> { fn desc<'a>() -> wgpu::VertexBufferDescriptor<'a> {
unimplemented!(); todo!();
} }
} }
``` ```

5
docs/news/README.md
View File

@ -2,7 +2,7 @@
## 0.6 ## 0.6
This took me way to long. The changes weren't difficult, but I had to do a lot of copy pasting. The main changes are using `queue.write_buffer()` and `queue.write_texture()` everywhere. I won't get into the nitty gritty, but you can checkout the [pull request](https://github.com/sotrh/learn-wgpu/pull/90) if you're interested. This took me way too long. The changes weren't difficult, but I had to do a lot of copy pasting. The main changes are using `queue.write_buffer()` and `queue.write_texture()` everywhere. I won't get into the nitty gritty, but you can checkout the [pull request](https://github.com/sotrh/learn-wgpu/pull/90) if you're interested.
## Added Pong Showcase ## Added Pong Showcase
@ -16,7 +16,7 @@ My perfectionism got in my way a bit with this one. I wasn't sure that what I wa
## 0.5! ## 0.5!
To many things changed to make note of them here. Check out [the 0.5 pull request](https://github.com/sotrh/learn-wgpu/pull/29) if you're curious about specifics. That being said, 2 things are worth mentioning directly: the y-axis now points up like with DirectX and Metal, and requesting an adapter and creating a device now use `Future`s. The tutorials have been updated as well as the code. Too many things changed to make note of them here. Check out [the 0.5 pull request](https://github.com/sotrh/learn-wgpu/pull/29) if you're curious about specifics. That being said, 2 things are worth mentioning directly: the y-axis now points up like with DirectX and Metal, and requesting an adapter and creating a device now use `Future`s. The tutorials have been updated as well as the code.
## Reworked lighting tutorial ## Reworked lighting tutorial
@ -72,4 +72,3 @@ I don't know if this is a change from 0.4, but you use `wgpu = "0.4"` line in de
## New/Recent Articles ## New/Recent Articles
<RecentArticles/> <RecentArticles/>