Thank you for the update, I was just doing some reading over the selection I’d buffer, and noticed that there is a multiple of two which is assuming the screen draw scale is 2 this does change depending on the device and screen. Pg 252 “* 2”
I would suggest you use contentScaleFactor.native or UIScreen.main.scale. It depends on how you are accessing the screen position data.
Hope that helps, as I got caught out by this when writing my idBuffer and testing on different devices.
I can’t say what @mhorga’s original intention was, but the nice thing about fragment shaders is that when you’re not creating a physically exact reproduction, you can create the effect you want for your render.
I tried both options, and I prefer the original code as written. When timer is applied the same to x and y, I find that the ripples are too straight. But you can go with whatever you think looks best.
Perhaps another possible bug, but still in chapter 4, under the Adding Another Vertex Attribute section, the snippet for creating the color buffer is the following:
guard let colorBuffer = device.makeBuffer(
bytes: &colors,
length: MemoryLayout<simd_float3>.stride * indices.count,
options: []) else {
fatalError("Unable to create quad color buffer")
}
self.colorBuffer = colorBuffer
I believe the length is incorrect. It should be:
MemoryLayout<simd_float3>.stride * colors.count
Otherwise we’re multiplying by 6 instead of 4, which is the amount of SIMD Float3 elements in the array!
Hi, for chapter 8, for the picture that denoted as “UV coordinates”, I think the coordinates whose y value are 0.15 should swap with the ones whose y values are 0.34.
Enjoying the book. I noticed in chapter 11 on normal maps, page 296 the first section ends: “and that’s the power of normal apps” and I think you intended that final word to be maps.
Thinking back to olden times, I believe float didn’t work for this, but I can’t remember what file format I was using. So I would advise that whatever file format you’re using, you check that the output matches your expectation. If this isn’t a recent Apple change, I obviously didn’t.
When using texture maps, the roughness value is ignored in the current code. That’s another point. I was looking at some code that uses the diffuse material colour as a scalar on the diffuse texture, whereas the book’s code just ignores the material if there is a texture. Maybe the code should use the roughness value as a scalar. Up to you.