Update Vulkan code to use RAII and modern Vulkan-Hpp bindings

Refactor code to replace raw Vulkan handles with RAII wrappers from Vulkan-Hpp for better resource management and safety. Key changes include RAII usage for buffers, images, and device memory, along with modernized function calls and parameter handling. Code readability and alignment with updated Vulkan practices were also improved.

Author: gpx1000

attachments/29_mipmapping.cpp

@@ -527,9 +527,6 @@ class HelloTriangleApplication {
         vk::ImageMemoryBarrier barrier (vk::AccessFlagBits::eTransferWrite, vk::AccessFlagBits::eTransferRead
                                , vk::ImageLayout::eTransferDstOptimal, vk::ImageLayout::eTransferSrcOptimal
                                , vk::QueueFamilyIgnored, vk::QueueFamilyIgnored, image);
-        barrier.image = image;
-        barrier.srcQueueFamilyIndex = vk::QueueFamilyIgnored;
-        barrier.dstQueueFamilyIndex = vk::QueueFamilyIgnored;
         barrier.subresourceRange.aspectMask = vk::ImageAspectFlagBits::eColor;
         barrier.subresourceRange.baseArrayLayer = 0;
         barrier.subresourceRange.layerCount = 1;

en/08_Loading_models.adoc

@@ -5,47 +5,20 @@
 == Introduction
 
 Your program is now ready to render textured 3D meshes, but the current geometry in the `vertices` and `indices` arrays is not very interesting yet.
-In this chapter we're going to extend the program to load the vertices and indices from an actual model file to make the graphics card actually do some work.
+In this chapter, we're going to extend the program to load the vertices and indices from an actual model file to make the graphics card actually do some work.
 
 Many graphics API tutorials have the reader write their own OBJ loader in a chapter like this.
 The problem with this is that any remotely interesting 3D application will soon require features that are not supported by this file format, like skeletal animation.
 We _will_ load mesh data from an OBJ model in this chapter, but we'll focus more on integrating the mesh data with the program itself rather than the details of loading it from a file.
 
-== Library
-
-We will use the https://github.com/syoyo/tinyobjloader[tinyobjloader] library to load vertices and faces from an OBJ file.
-It's fast and it's easy to integrate because it's a single file library like stb_image.
-Go to the repository linked above and download the `tiny_obj_loader.h` file to a folder in your library directory.
-
-*Visual Studio*
-
-Add the directory with `tiny_obj_loader.h` in it to the `Additional Include Directories` paths.
-
-image::/images/include_dirs_tinyobjloader.png[]
-
-*Makefile*
-
-Add the directory with `tiny_obj_loader.h` to the include directories for GCC:
-
-[,text]
-----
-VULKAN_SDK_PATH = /home/user/VulkanSDK/x.x.x.x/x86_64
-STB_INCLUDE_PATH = /home/user/libraries/stb
-TINYOBJ_INCLUDE_PATH = /home/user/libraries/tinyobjloader
-
-...
-
-CFLAGS = -std=c++17 -I$(VULKAN_SDK_PATH)/include -I$(STB_INCLUDE_PATH) -I$(TINYOBJ_INCLUDE_PATH)
-----
-
 == Sample mesh
 
-In this chapter we won't be enabling lighting yet, so it helps to use a sample model that has lighting baked into the texture.
+In this chapter, we won't be enabling lighting yet, so it helps to use a sample model that has lighting baked into the texture.
 An easy way to find such models is to look for 3D scans on https://sketchfab.com/[Sketchfab].
 Many of the models on that site are available in OBJ format with a permissive license.
 
-For this tutorial I've decided to go with the https://sketchfab.com/3d-models/viking-room-a49f1b8e4f5c4ecf9e1fe7d81915ad38[Viking room] model by https://sketchfab.com/nigelgoh[nigelgoh] (https://web.archive.org/web/20200428202538/https://sketchfab.com/3d-models/viking-room-a49f1b8e4f5c4ecf9e1fe7d81915ad38[CC BY 4.0]).
-I tweaked the size and orientation of the model to use it as a drop in replacement for the current geometry:
+For this tutorial, I've decided to go with the https://sketchfab.com/3d-models/viking-room-a49f1b8e4f5c4ecf9e1fe7d81915ad38[Viking room] model by https://sketchfab.com/nigelgoh[nigelgoh] (https://web.archive.org/web/20200428202538/https://sketchfab.com/3d-models/viking-room-a49f1b8e4f5c4ecf9e1fe7d81915ad38[CC BY 4.0]).
+I tweaked the size and orientation of the model to use it as a drop-in replacement for the current geometry:
 
 * xref:attachment$viking_room.obj[viking_room.obj]
 * xref:attachment$viking_room.png[viking_room.png]
@@ -58,9 +31,9 @@ Put two new configuration variables in your program to define the model and text
 
 [,c++]
 ----
-const uint32_t WIDTH = 800;
-const uint32_t HEIGHT = 600;
-
+constexpr uint32_t WIDTH = 800;
+constexpr uint32_t HEIGHT = 600;
+constexpr uint64_t FenceTimeout = 100000000;
 const std::string MODEL_PATH = "models/viking_room.obj";
 const std::string TEXTURE_PATH = "textures/viking_room.png";
 ----
@@ -81,16 +54,16 @@ Replace them with non-const containers as class members:
 ----
 std::vector<Vertex> vertices;
 std::vector<uint32_t> indices;
-VkBuffer vertexBuffer;
-VkDeviceMemory vertexBufferMemory;
+std::unique_ptr<vk::raii::Buffer> vertexBuffer;
+std::unique_ptr<vk::raii::DeviceMemory> vertexBufferMemory;
 ----
 
 You should change the type of the indices from `uint16_t` to `uint32_t`, because there are going to be a lot more vertices than 65535.
 Remember to also change the `vkCmdBindIndexBuffer` parameter:
 
 [,c++]
 ----
-vkCmdBindIndexBuffer(commandBuffer, indexBuffer, 0, VK_INDEX_TYPE_UINT32);
+commandBuffers[currentFrame]->bindIndexBuffer( **indexBuffer, 0, vk::IndexType::eUint32 );
 ----
 
 The tinyobjloader library is included in the same way as STB libraries.
@@ -231,7 +204,7 @@ ____
 
 == Vertex deduplication
 
-Unfortunately we're not really taking advantage of the index buffer yet.
+Unfortunately, we're not really taking advantage of the index buffer yet.
 The `vertices` vector contains a lot of duplicated vertex data, because many vertices are included in multiple triangles.
 We should keep only the unique vertices and use the index buffer to reuse them whenever they come up.
 A straightforward way to implement this is to use a `map` or `unordered_map` to keep track of the unique vertices and respective indices:
@@ -301,14 +274,14 @@ The hash functions for the GLM types need to be included using the following hea
 ----
 
 The hash functions are defined in the `gtx` folder, which means that it is technically still an experimental extension to GLM.
-Therefore you need to define `GLM_ENABLE_EXPERIMENTAL` to use it.
+Therefore, you need to define `GLM_ENABLE_EXPERIMENTAL` to use it.
 It means that the API could change with a new version of GLM in the future, but in practice the API is very stable.
 
 You should now be able to successfully compile and run your program.
 If you check the size of `vertices`, then you'll see that it has shrunk down from 1,500,000 to 265,645!
 That means that each vertex is reused in an average number of ~6 triangles.
 This definitely saves us a lot of GPU memory.
 
-In the xref:09_Generating_Mipmaps.adoc[next chapter] we'll learn about a technique to improve texture rendering.
+In the xref:09_Generating_Mipmaps.adoc[next chapter,] we'll learn about a technique to improve texture rendering.
 
 link:/attachments/28_model_loading.cpp[C{pp} code] / link:/attachments/27_shader_depth.vert[Vertex shader] / link:/attachments/27_shader_depth.frag[Fragment shader]