问题标签 [vertex-attributes]

我尝试在 VAO 中使用 2 VBO，但最终导致崩溃（远远超出我的应用程序）。

这个想法是制作第一个 VBO（和可选的 IBO）来构建几何图形。

这很好，直到我想到为模型矩阵添加第二个 VBO 作为顶点属性而不是统一。

因此，当我声明我的网格时，我会执行以下操作（简化代码）：

在那之前，一切都很好，我所要做的就是调用 glBindVertexArray() 和 glDrawXXX() 命令，我在屏幕上有完美的东西。

因此，我决定从着色器中删除 modelMatrix 统一以使用 mat4 属性，我可以选择一个 UBO，但我想通过提供多个矩阵将这个想法扩展到实例化渲染。

因此，我在 VBO 中使用一个模型矩阵进行了测试，就在渲染之前，我执行以下操作（VBO 的构建方式与之前相同，我只是为单位矩阵放置了 16 个浮点数）：

结果是一个漂亮的崩溃，我没有任何线索，因为崩溃发生在我无法调试输出的驱动程序中。

我的想法完全是垃圾吗？还是我错过了什么？

我的目标是使用 R 中的 ndtv 和 networkDynamic 包进行动态网络可视化。我使用边缘拼写和顶点拼写构造 networkDynamic 对象，如第 7.3 节所述。数据帧还包含时间边缘和顶点属性 (TEA)。

我希望所有边和顶点始终保持活动状态，但会根据它们的 TEA 而有所不同。我想要“权重”来确定边缘的宽度，“大小”来确定节点的大小。

但是，当我渲染动画时，很明显两者都没有正确映射到它们的对象上。

出于某种原因，只有从“节点 1”指向的边具有不同的宽度，甚至这些边也没有按预期显示。节点大小也是错误的，并且始终保持不变。

显然我做错了什么。我尝试以几种不同的方式构建数据集，包括作为代表每个波的网络对象列表，但我一直遇到同样的问题。任何帮助将不胜感激。

编辑

在使用 network.list 选项构造 dynamicNetwork 对象时我遇到了同样的问题，并且在新梳数据上运行相同的代码时它仍然存在，如评论中所建议的那样。上面链接的文档提到数据集包含它似乎不包含的边缘属性“权重”，因此我使用 newcom.rank 数据集中的“rank”属性。

当比较 newcomb.rank 网络列表中第一个网络中的“rank”属性与时间 1 的“rank.active”属性时，我们发现它们不对应。此外，“rank.active”属性远大于活动边的数量。

此外，“rank.active”在 t = 2 时看起来与 t = 1 时相同。

最后，当基于“rank.active”属性渲染具有边缘宽度的动画时，边缘宽度不是动态的，而是始终保持静态。

我正在学习 opengl.com上的 OpenGL 教程，并决定测试我是否完全掌握了顶点属性的概念。我尝试调整代码只是为了看看它是否像我认为的那样在幕后工作。

这是我修改后的vertices数组的样子：

每个顶点现在是 5 个浮点数，而我想要的位置属性是每个顶点的最后两个浮点数（分别为 x 和 y，z 默认为 0.0）。

所以这是我修改后的顶点属性规范：

目前，我如何读取第一个函数（从左到右）是 - “第0个顶点属性由2 个未标准化的浮点数组成。每个顶点由5个浮点数组成，第 0 个属性位于左侧的3 个索引处每个顶点。”

我修改后的顶点着色器如下所示：

我目前的理解是location = 0指定我们正在查看第 0 个属性，这是我的位置属性。我使用vec2该属性是因为该属性只有 2 个浮点数。

我希望程序渲染的是一个倒置的等腰三角形，但最终渲染的只是背景。那么，我对顶点属性如何在幕后工作的理解中究竟缺少什么？

upsertVertexDataFrame() 中 pyTigerGraph.py 的回溯行 1269 (else {target: json_up[-1][source])

(.0) 中相同的第 1269 行

KeyError：（'音量'，'+'）

我还没有在 upsertVertices 中尝试过这种格式。那是下一个。

这似乎是一个问题，一直以来对于一个或另一个 IHV 都有回答，但最近我一直试图就顶点布局和跨所有 IHV 和架构的现代渲染器的最佳实践达成共识。在有人说基准之前，我不能轻易做到这一点，因为我无法访问过去 5 年中每个 IHV 和每个架构的卡。因此，我正在寻找一些可以在所有平台上正常运行的最佳实践。

首先，显而易见的：

• 将位置与其他属性分开有利于：
  • 阴影和深度预通
  • 每个三角形剔除
  • 基于平铺的延迟渲染器（例如 Apple M1）
• Interleaved 在 CPU 上比较合乎逻辑，可以有一个Vertex类。
• 由于能够利用 SIMD，非交错可以使一些 CPU 计算更快。

现在到不太明显的地方。

许多人引用 NVIDIA 的话说，你应该总是交错，而且你应该对齐到 32 或 64 字节。我还没有找到它的来源，而是找到了一份关于NVIDIA顶点着色器性能的文档，但它已经很老了（2013 年），而且是关于 Tegra GPU 的，它是移动的，而不是桌面的。特别是它说：

将顶点数据存储为交错的属性流（“结构数组”布局），这样属性的“过度获取”往往会预取可能对后续属性和顶点有用的数据。将属性存储为不同的、非交错的（“数组结构”）流可能会导致内存系统中的“页面抖动”，从而导致性能大幅下降。

快进 3 年到GDC 2016，EA 提供了一个演示文稿，其中提到了为什么应该去交错顶点缓冲区的几个原因。但是，此建议似乎与 AMD 架构有关，尤其是 GCN。虽然他们提出了一个跨平台的案例来分离位置，但他们建议对所有内容进行去交错，并声明它将允许 GPU：

尽快驱逐缓存行

并且它是 GCN (AMD) 架构的最佳选择。

这似乎与我在其他地方听到的使用交错以充分利用高速缓存行的说法相冲突。但同样，这与 AMD 无关。

有许多不同的 IHV，英特尔、英伟达、AMD 以及现在的 Apple 和 M1 GPU，而且每个都有许多不同的架构，这让我完全不确定今天应该做什么（没有预算来测试几十个GPU 的数量），以便在所有架构中最好地优化性能，而不会导致

性能大幅下降

在一些架构上。特别是，去交错在 AMD 上仍然是最好的吗？它不再是 NVIDIA 的问题，还是桌面 NVIDIA GPU 从来没有问题？其他 IHV 呢？

注意：我对移动设备不感兴趣，只对过去 5 年左右的所有桌面 GPU 感兴趣。