Opengl 缓冲区-索引或直接、交错或分离

在选择顶点缓冲区类型时，有哪些常见的准则？什么时候我们应该为顶点数据使用隔行缓冲区，什么时候使用单独的缓冲区？何时应该使用索引数组，何时直接使用顶点数据

我在寻找一些常见的魁地林-我在一些情况下，一个或相反的更适合，但不是所有的情况都很容易解决。在追求性能时，选择顶点缓冲区格式时应该考虑什么

---

也欢迎链接到该主题的web资源。

首先，您可以在OpenGL wiki上找到一些。其次，如果对概要文件有疑问，这方面有一些经验法则，但经验可能会因数据集、硬件、驱动程序等而异

索引与直接渲染 默认情况下，我几乎总是对顶点缓冲区使用索引方法。主要原因是所谓的。它是在图形管线的顶点处理阶段之后保存的缓存。从本质上讲，这意味着如果多次使用某个顶点，则很有可能命中该缓存并能够跳过顶点计算。有一个条件甚至可以命中这个缓存，那就是你需要使用索引缓冲区，没有它们它就不能工作，因为索引是这个缓存键的一部分

此外，您可能会节省存储空间，索引可以是您想要的大小（1字节，2字节），并且您可以重用完整的顶点规范。假设一个顶点和所有属性总共有大约30字节的数据，并且您在2个多边形上共享该顶点。使用索引渲染（2字节索引），这将花费您

2*索引大小+属性大小=34字节
。对于非索引渲染，这将花费您60字节。通常，顶点将共享两次以上

基于索引的渲染总是更好吗？不，可能有更糟的情况。对于非常简单的应用程序，设置基于索引的数据模型可能不值得花费代码开销。此外，如果您的属性没有在多边形上共享（例如，每个多边形的法线而不是每个顶点），则可能根本没有顶点共享，而IBO不会带来任何好处，只会增加开销

除此之外，虽然它启用了转换后缓存，但它确实使通用内存缓存的性能更差。因为访问属性相对随机，所以可能会有更多的缓存未命中，并且内存预取（如果在GPU上进行的话）无法正常工作。因此，如果您有足够的内存，并且顶点着色器非常简单，那么非索引版本的性能可能会优于索引版本

每个属性的交错vs非交错vs缓冲区
这个故事有点微妙，我认为它可以归结为权衡你的一些属性

交错可能会更好，因为所有属性将紧密地放在一起，并且可能位于几个内存缓存线（甚至可能是单个缓存线）中。显然，这意味着更好的性能。然而，与基于索引的渲染相结合，您的内存访问是非常随机的，并且其好处可能比您预期的要小
知道哪些属性是静态的，哪些是动态的。如果你有5个属性，其中2个是完全静态的，1个改变每15分钟，2个10秒，考虑把它们放在2个或3个单独的缓冲器中。您不希望每次更改这两个最频繁的属性时都重新上载所有5个属性
考虑属性应按4字节对齐。因此，您可能希望不时地进一步进行交错。假设您有一个vec3 1字节属性和一些标量1字节属性，很简单，这将需要8个字节。如果将它们放在一个vec4中，您可能会获得很多好处，这会将使用量减少到4字节
使用缓冲区大小时，缓冲区过大或过多的小缓冲区可能会影响性能。但这可能非常依赖于硬件、驱动程序和OpenGL实现
索引与直接
让我们看看通过索引可以得到什么。每个重复的顶点，即具有“平滑”打断的顶点，成本更低。每一个单一的“边”顶点都会花费你更多。对于基于真实世界且相对密集的数据，一个顶点将属于多个三角形，因此索引将加快速度。对于程序生成的任意数据，直接模式通常更好

索引缓冲区还增加了代码的复杂性

交错与分离
这里的主要区别实际上是基于一个问题：“我是否只想更新一个组件？”。如果答案是肯定的，那么就不应该交错，因为任何更新都会非常昂贵。如果答案是否定的，则使用交错缓冲区可以改善引用的局部性，并且通常在大多数硬件上速度更快。
下行投票者会分享他的理由吗？+1不知道下行投票者，这个问题对我来说很有趣，期待答案。也就是说，我通常使用单独的索引缓冲区。他们感觉最直观，一些GL检查工具（如gDebugger）在简单缓冲区（非交错）上工作得最好。通过程序生成的任意数据，你指的是像粒子系统这样的东西吗？因为对于程序性地形，如果没有索引，将浪费大量空间。。。还是我错了？@Kornel哦，那要看情况了。例如，在我的Minecraft克隆中，我需要对显示的结构（立方体的“外壳”）进行更新。因此，每当用户删除或添加多维数据集时，我都在重建块VBO。索引的好处不多（纹理从一个立方体变为另一个立方体，你不能轻易地重用顶点），动态构建索引的过程需要更长的时间，因此只需创建一个大数据块并将其推送就更简单了，从而减轻了CPU的负担（无论如何，GPU渲染普通数据的速度都非常快）@KornelKisielewicz，但用于常规平铺高度图