ch05 seems a mountain to climb. For me that not only a newbie in Metal but also a newbie in Swift takes more time to chew.
I notice that the Mesh contain 2 part : mdlMesh and mtkMesh
meshes = zip (mdlMeshes, mtkMeshes).map {
Mesh(mdlMesh: $0.0, mtkMesh: $0.1)
}
but In the Render part, only mtkMesh is used
for submesh in mesh.submeshes {
let mtkSubmesh = submesh.mtkSubmesh
renderEncoder.drawIndexedPrimitives(type: .triangle,
indexCount: mtkSubmesh.indexCount,
indexType: mtkSubmesh.indexType,
indexBuffer: mtkSubmesh.indexBuffer.buffer,
indexBufferOffset: mtkSubmesh.indexBuffer.offset)
}
Why we add those mdlMesh in the class that complicate the code?
Yes, I would agree that Chapter 5 is the hardest chapter in parts 1 and 2. We’ve tried to keep the “Swiftiness” level to a minimum, but sometimes Swift solutions are just too neat to ignore.
In case you’re confused about zip
, it will take two arrays and combine them into one array of tuples. So [X,X,X,X] and [Y,Y,Y,Y] becomes [(X,Y),(X,Y),(X,Y),(X,Y)].
When you use .map
, the tuple is $0 and each element (X or Y) is $0.0 and $0.1
mdlMesh
contains data about materials that you’ll use later.
class Submesh {
var mtkSubmesh: MTKSubmesh
init(mdlSubmesh: MDLSubmesh, mtkSubmesh: MTKSubmesh) {
self.mtkSubmesh = mtkSubmesh
}
}
You’ll work on this class in the following two chapters for surface textures and materials.
Model I/O is a convenience API for loading up Metal data, and you won’t use any MDL
API in actual rendering. Loading objs etc, used to be a real hassle, and Model I/O abstracts it all away. When initially loading, you need to get all the mdl
data into a format that your app will understand. Chapters 6 and 7 are textures and materials, and each submesh (group) could have different materials which you will extract from mdlMesh
.
ok, thank you I will keep reading.