关于按次调用数据使用UBO（统一缓冲区对象）的正确方法是什么？ （OpenGL / C ++）

Question

因此，我刚刚开始将代码库过渡到使用统一的缓冲区对象。到目前为止，我已经使UBO可以处理在多个着色器程序（如相机）之间共享的事情。

现在我还读到，对于每次抽奖数据（例如模型矩阵，材料，骨骼等），使用UBO是个好主意。

那表示我在挖掘有关“最佳/正确”方法的信息方面遇到困难。

我正在考虑的一些布局（尽管可能不在正确的路径上，如果是这种情况，请纠正我）

A： 将全局数据（相机等）放在一个具有自己块的ubo中。 将每个独立的drawcall数据集都有自己的块。

所以基本上

一个ubo /阻止：

layout (std140) uniform camera_ubo {
    mat4 camera stuff... etc
};

一个ubo /阻止：

layout (std140) uniform mesh_ubo {
    mat4 bones[MAX_BONES];
    etc...
};

然后我在每次绘制调用之前使用glBufferSubData来更新值。

B：将所有内容推送到一个ubo块中，并在每次抽奖实际需要更新的部分上再次使用glBufferSubData。

C：完全不同，因为上述选项很糟糕。 （如果是这样怎么办？）

PS：如果答案完全取决于glMapBuffer，那不是我“应该”在我所针对的平台上使用的一种东西，因为它需要被模拟以产生性能优势。

编辑：我已经实现了“ A”示例，效果很好，但是后来让我开始思考，如果我可以说一个“材质” ubo，并且该材质具有颜色，粗糙度等属性。将需要更新gpu方面的“材料”以反映在cpu方面使用的材料，每次更改时，现在显然您可以批处理这些材料，但是我在想，每种材料都应该是ubo，所以每个垫子只需要一次传递给GPU（然后您很快就会用完UBO），或者我应该使用某种材料UBO来包含一系列材料结构，因为如果我正确理解的话，每个UBO可以容纳的数据量为相当可观。这个想法可以应用于上述的“ mesh_ubo”，例如：

struct mesh {
    layout (std140) uniform mesh_ubo {
    mat4 bones[MAX_BONES];
    etc...
};

layout (std140) uniform meshs_ubo {
    mesh meshes[MAX_MESHES];
};

无论如何，同样的问题仍然存在，我仍在寻找将所有这些东西打包的“正确方法”。因为目前我看到很多事情看起来像它们在带有少量数据的非常简单的用例中都能很好地工作，但是一旦我按比例扩大一切，它们可能就会崩溃。