vblanco20-1 / vkguide-comments

Storage for the comments of vulkan-guide
0 stars 0 forks source link

Chapter 3 Comments #6

Open utterances-bot opened 3 years ago

utterances-bot commented 3 years ago

Implementing vertex buffers - Vulkan Guide

Brand new guide to vulkan graphics programming

https://www.vkguide.dev/docs/chapter-3/triangle_mesh_code/

SeppahBaws commented 3 years ago

Don't forget to add the following to the cleanup() function, otherwise there will be memory leaks!

vmaDestroyAllocator(_allocator);
brightprogrammer commented 3 years ago

Awesome...

Snowapril commented 3 years ago

Thank you for good programming guide. but i think there is typo in the middle of "Setting up depth buffer" contents. It is posted as DEPTH_STENCILATTACHMENTOPTIONAL, not DEPTH_STENCILATTACHMENTOPTIMAL

HelixTitan commented 3 years ago

For some reason the VMA memory project is never loading into my solution. I felt like I followed the tutorial but for some reason it doesn't make a project so it can't link it. I have never used CMAKE, but everything was rendering until we added the memory. What do I need to look for to make sure the CMAKE will gen a vma project?

Diamond-D0gs commented 2 years ago

The last code block in "Setting up depth buffer" references vkinit::renderpass_begin_info despite not having written that function yet.

K1ngst0m commented 2 years ago

@HelixTitan the vma project is header only so cmake only needs include it's path (it is already done in tutorial's cmakelist), you can just follow the tutorial that add these #define VMA_IMPLEMENTATION #include<vk_mem_alloc.h> on your vk_engine.cpp or other like vma_build.cpp (you also need to add this new file to src/CMakeLists.txt) to actually instantiates the code

dhawals1939 commented 2 years ago

Why are we using Index buffers like we use in OpenGL?

dhawals1939 commented 2 years ago

Sorry for the wrong question. Why aren't we using Index Buffers like we use in OpenGL.?

CarloWood commented 2 years ago

"For now, we are going to be allocating our buffers all on CPU RAM, as it is significantly easier to implement, and at the moment we don’t need the performance."

Unfortunately that way I can't learn how it is really done. I came here searching for "vulkan vertex buffer" in the hope to find examples of how to set things up for a real vulkan engine; where the performance does matter. It is unfortunate that there seem to be only tutorial out there that teach you the wrong or cheap way :/.

bipul-mohanto commented 2 years ago

Besides the wavefront obj format, what else formats the tinyobjloader can load? I tried .fbx file format, but it wasn't working.

SeppahBaws commented 2 years ago

Besides the wavefront obj format, what else formats the tinyobjloader can load? I tried .fbx file format, but it wasn't working.

Just wavefront obj. If you want to load other formats, I recommend assimp. It can load over 40 different file formats, but it is more work to implement: https://github.com/assimp/assimp

bipul-mohanto commented 2 years ago

Besides the wavefront obj format, what else formats the tinyobjloader can load? I tried .fbx file format, but it wasn't working.

Just wavefront obj. If you want to load other formats, I recommend assimp. It can load over 40 different file formats, but it is more work to implement: https://github.com/assimp/assimp

Yes, I was also googling a bit, seems like ASSIMP is the better option. However, for simplification, tinyobjloader is currently working fine for me. Thanks for your answer. One additional question @SeppahBaws, tinyobjloader cannot read the texture file, right? I saw people are using additional image reader libraries, e.g., stb_image library.

lolitsanub commented 2 years ago

@HelixTitan

You don't need cmake... just include vk_mem_alloc and

define VMA_IMPLEMENTATION

It will automatically add and #include Vma's .cpp files

SeppahBaws commented 2 years ago

Besides the wavefront obj format, what else formats the tinyobjloader can load? I tried .fbx file format, but it wasn't working.

Just wavefront obj. If you want to load other formats, I recommend assimp. It can load over 40 different file formats, but it is more work to implement: https://github.com/assimp/assimp

Yes, I was also googling a bit, seems like ASSIMP is the better option. However, for simplification, tinyobjloader is currently working fine for me. Thanks for your answer. One additional question @SeppahBaws, tinyobjloader cannot read the texture file, right? I saw people are using additional image reader libraries, e.g., stb_image library.

That's correct, tinyobjloader simply just loads in the mesh data from .obj files. You have to load the textures with another library - or roll your own if you're up for the challenge. 😉 (sorry for the late reply, only just now saw that you edited your comment)

jonathan-hopkins commented 2 years ago

In the "Setting up depth buffer section" I think there's a small optimization issue. depth_attachment.storeOp = VK_ATTACHMENT_STORE_OP_STORE; should be depth_attachment.storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE; as we aren't going to need the depth image after this render pass.

zhulinspace commented 1 year ago

I am confused about the "depth_dependency" and "dependency".

VkSubpassDependency dependency = {};
dependency.srcSubpass = VK_SUBPASS_EXTERNAL;
dependency.dstSubpass = 0;
dependency.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.srcAccessMask = 0;
dependency.dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;

VkSubpassDependency depth_dependency = {};
depth_dependency.srcSubpass = VK_SUBPASS_EXTERNAL;
depth_dependency.dstSubpass = 0;
depth_dependency.srcStageMask = VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT | VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT;
depth_dependency.srcAccessMask = 0;
depth_dependency.dstStageMask = VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT | VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT;
depth_dependency.dstAccessMask = VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;

My understanding is that renderpass includes rendering commands that render to framebuffer,and subpasses are some of the steps.The subpass dependency should synchronize subpass execution order.But in this example, you only have one subpass, so how to understand the 'depth_dependency' ? in my understanding ,you seems synchronize subpass from different renderpass,or synchronize renderpass execution order?

rje commented 1 year ago

If you are working on mac with moltenvk, you may run into an issue where you don't see anything after implementing the initial vertex buffers. I found that after every call to vmaUnmapMemory, I needed to add a call to vmaFlushAllocation. Doing this made things work as expected

zhulinspace commented 1 year ago

@rje I work on mac ,but i did not met the problem you said

Trider12 commented 1 year ago

You say

We keep the subpass dependency for the color attachment we were already using

But you've never mentioned it before in the tutorial. In fact, I didn't see the whole dependencies topic explained.

ARobbins67 commented 1 year ago

We are going to place those files alongside the rest of engine files. You can look at the Github code as example. Make sure to add it to the CMake and re-run it so that the project updates.

I'm not sure what this means. I added the vk_mesh.h and vk_mesh.cpp to visual studio in the normal way, but when I try to add #include <vk_mesh.h> in vk_mesh.cpp it says it cannot open the source file, even though they are in the same directory. Any help would be greatly appreciated.

hekatx commented 1 year ago

In case anyone has the same concerns as @CarloWood ; docs for VMA are all you need to know to setup allocations on the GPU, check this page specifically

joviol commented 1 year ago

I have been trying to apply the mtl (material file) which is read from tinyobjloader. It works fine, howerver, if a mesh has more then one material (set0, 1 ...) I can't seem to see the other materials besides the first one. Any tips?