<blockquote>
  <p>With OpenGL I would have to reload whole vertex VBO's.</p>
</blockquote>

<p>No you wouldn't.  You can use <code>glBufferSubData</code></p>

<blockquote>
  <p>I suppose with Vulkan there could be a way to directly access VBO's to only change/add/remove the changed vertex data</p>
</blockquote>

<p>If you know the memory layout of the vertex buffer, you can find the offset of the contents you want to change, populate a transfer buffer with the new data and then uss <a href="https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCmdCopyBuffer.html" rel="noreferrer">vkCmdCopyBuffer</a> to copy the data.  The <code>VkBufferCopy</code> parameter lets you specify the size as well as the source and destination offsets.  In other words, every call to <code>vkCmdCopyBuffer</code> is basically the equivalent of N calls to <code>glBufferSubData</code></p>

<p>To clarify, updating a vertex buffer on Vulkan is almost the same as populating it.  If you're on a desktop architecture where <em>device local</em> memory is typically not mappable, then you have to create a transfer buffer that is <em>host visible</em>.  You can populate that buffer with a memcpy (or whatever), and then use <code>vkCmdCopyBuffer</code> to transfer it to the <em>device local</em> memory backed buffer.  If you're on a mobile architecture with unified memory, then <em>device local</em> memory is typically also <em>host visible</em> and so you can just map it directly and update it with your <code>memcpy</code> (or whatever)</p>

CC BY-SA 4.0
2019-05-30T04:55:06.250Z
"*If you're on a desktop architecture where device local memory is typically not mappable, then you have to create a transfer buffer that is host visible.*" Even implementations that offer split memory may allow you to use host-visible memory for vertex data. In cases where you're frequently uploading data (like a GUI), this would be a good thing to use.
Nicol Bolas
CC BY-SA 4.0
2019-05-30T04:59:11.333Z
Also, synchronization is really important when updating memory.
Nicol Bolas
CC BY-SA 4.0
2019-05-30T01:55:58.180Z
2019-05-30T04:05:46.257Z
2019-05-30T04:05:46.257Z
Jherico
<p>I would like to change/add/remove some mesh vertices in existing VBO's (while deforming and remeshing 3D objects) . With OpenGL I would have to reload whole vertex VBO's. I suppose with Vulkan there could be a way to directly access VBO's to only change/add/remove the changed vertex data. Is there some sample code out there demonstrating how this can be achieved? 
Many thanks for any help. </p>

<opengl><3d><vulkan><vertex-buffer-object>
Vulkan: efficient way to update VBO mesh vertices?
Trantor
# Vulkan: efficient way to update VBO mesh vertices?

(Asked by: username_0 on 2019-05-29)

I would like to change/add/remove some mesh vertices in existing VBO's (while deforming and remeshing 3D objects) . With OpenGL I would have to reload whole vertex VBO's. I suppose with Vulkan there could be a way to directly access VBO's to only change/add/remove the changed vertex data. Is there some sample code out there demonstrating how this can be achieved?
Many thanks for any help.

**Tags:** opengl, 3d, vulkan, vertex-buffer-object


---

## 1 answers

### Answer by username_1 on 2019-05-30. Score: 5 | Accepted answer

> With OpenGL I would have to reload whole vertex VBO's.

No you wouldn't. You can use `glBufferSubData`

> I suppose with Vulkan there could be a way to directly access VBO's to only change/add/remove the changed vertex data

If you know the memory layout of the vertex buffer, you can find the offset of the contents you want to change, populate a transfer buffer with the new data and then uss [vkCmdCopyBuffer](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCmdCopyBuffer.html) to copy the data. The `VkBufferCopy` parameter lets you specify the size as well as the source and destination offsets. In other words, every call to `vkCmdCopyBuffer` is basically the equivalent of N calls to `glBufferSubData`

To clarify, updating a vertex buffer on Vulkan is almost the same as populating it. If you're on a desktop architecture where *device local* memory is typically not mappable, then you have to create a transfer buffer that is *host visible*. You can populate that buffer with a memcpy (or whatever), and then use `vkCmdCopyBuffer` to transfer it to the *device local* memory backed buffer. If you're on a mobile architecture with unified memory, then *device local* memory is typically also *host visible* and so you can just map it directly and update it with your `memcpy` (or whatever)

> **Comments:**
> **username_2**: "*If you're on a desktop architecture where device local memory is typically not mappable, then you have to create a transfer buffer that is host visible.*" Even implementations that offer split memory may allow you to use host-visible memory for vertex data. In cases where you're frequently uploading data (like a GUI), this would be a good thing to use.  
> **username_2**: Also, synchronization is really important when updating memory.  

---

