问题标签 [vertex]

I'm trying to get a clear idea of when I should be using indexed arrays of OpenGL vertices, drawn with gl[Multi]DrawElements and the like, versus when I should simply use contiguous arrays of vertices, drawn with gl[Multi]DrawArrays.

(Update: The consensus in the replies I got is that one should always be using indexed vertices.)

I have gone back and forth on this issue several times, so I'm going to outline my current understanding, in the hopes someone can either tell me I'm now finally more or less correct, or else point out where my remaining misunderstandings are. Specifically, I have three conclusions, in bold. Please correct them if they are wrong.

One simple case is if my geometry consists of meshes to form curved surfaces. In this case, the vertices in the middle of the mesh will have identical attributes (position, normal, color, texture coord, etc) for every triangle which uses the vertex.

This leads me to conclude that:

1. For geometry with few seams, indexed arrays are a big win.

Follow rule 1 always, except:

For geometry that is very 'blocky', in which every edge represents a seam, the benefit of indexed arrays is less obvious. To take a simple cube as an example, although each vertex is used in three different faces, we can't share vertices between them, because for a single vertex, the surface normals (and possible other things, like color and texture co-ord) will differ on each face. Hence we need to explicitly introduce redundant vertex positions into our array, so that the same position can be used several times with different normals, etc. This means that indexed arrays are of less use.

e.g. When rendering a single face of a cube:

(this can be considered in isolation, because the seams between this face and all adjacent faces mean than none of these vertices can be shared between faces)

if rendering using GL_TRIANGLE_FAN (or _STRIP), then each face of the cube can be rendered thus:

Adding indices does not allow us to simplify this.

From this I conclude that:

2. When rendering geometry which is all seams or mostly seams, when using GL_TRIANGLE_STRIP or _FAN, then I should never use indexed arrays, and should instead always use gl[Multi]DrawArrays.

(Update: Replies indicate that this conclusion is wrong. Even though indices don't allow us to reduce the size of the arrays here, they should still be used because of other performance benefits, as discussed in the comments)

The only exception to rule 2 is:

When using GL_TRIANGLES (instead of strips or fans), then half of the vertices can still be re-used twice, with identical normals and colors, etc, because each cube face is rendered as two separate triangles. Again, for the same single cube face:

Without indices, using GL_TRIANGLES, the arrays would be something like:

Since a vertex and a normal are often 3 floats each, and a color is often 3 bytes, that gives, for each cube face, about:

(I understand the number of bytes might change if different types are used, the exact figures are just for illustration.)

With indices, we can simplify this a little, giving:

See how in the latter case, vertices 0 and 2 are used twice, but only represented once in each of the verts, normals and colors arrays. This sounds like a small win for using indices, even in the extreme case of every single geometry edge being a seam.

This leads me to conclude that:

3. When using GL_TRIANGLES, one should always use indexed arrays, even for geometry which is all seams.

Please correct my conclusions in bold if they are wrong.

我正在准备考试，其中一个样题如下：

顶点覆盖：图中的顶点覆盖是一组顶点，使得每条边在这个集合中至少有它的两个端点中的一个。

最小顶点覆盖：图中的最小顶点覆盖是在所有可能的顶点覆盖中具有最少数量的顶点的顶点覆盖。

最小顶点覆盖图中的最小顶点覆盖是不包含另一个顶点覆盖的顶点覆盖（从集合中删除任何顶点将创建一组不是顶点覆盖的顶点）

问题：最小顶点覆盖并不总是最小顶点覆盖。用一个简单的例子来证明这一点。

任何人都可以解决这个问题吗？我看不出两者之间的区别。更重要的是，我很难想象它。

我真的希望他在考试中不要问这种奇怪的问题！

如何获得 Box2d 中顶点的位置？

我目前正在尝试通过组合两个三角形来制作一个简单的正方形，就像在 Riemer 的教程中一样（链接到教程），但是由于从 3.x 到 4.0 已经发生了很多变化，我觉得这很困难。我也想知道如何纹理这个“正方形”，所以如果有人可以通过给出一些例子来帮助我，我将不胜感激:)

谢谢！

• 基本的

Well, I'm working with the igraph package, and I'd like to pick the edges by the name that I've assigned to their vertex, in a tiny example..

Now My edge list hast this form

What i want now is to find a way of, instead of using this

doing something more like E(g)[G2%--%G1] (calling the vertex by the name i've assigned), or an equivalent way of knowing some edges attributes by the name of the vertex involved.

我有这个基本的 3d 应用程序并尝试编写自己的卡通着色器，但即使我删除了卡通部分，当我给它一个红色时，它仍然只是保持纯深蓝色。

着色器代码：

自定义顶点格式：

我要绘制的三角形的初始化：

识别从特定视点可见的顶点的最有效方法是什么？

我有一个由几个 3D 模型组成的场景。我想为每个顶点附加一个标识符（ModelID，VertexID），然后从各种视点生成 2D 图像，并为每个图像生成一个可见顶点标识符列表（本质上这是用于图像处理应用程序）。

最初我想在顶点法线和相机视图向量之间执行点积，以确定顶点是否面向相机，但是如果模型被另一个对象遮挡，则此测试将不起作用。

提前致谢

我正在 processing.org 中使用 OpenGL 做我的第一步。我想画两个交叉的三角形，但不知道如何旋转三角形来交叉它们。

三角形应该像这些旧的 3D 树木模型一样交叉。它们应该在以后使用时作为一个对象旋转和移动，我认为它可以与 pop 和 push 两个顶点一起使用，我只是无法弄清楚将这两个三角形组合在一起的旋转。

我正在为 AS3.0 编写一个 3D 引擎……我遇到了一个烦人的问题。AS3.0 目前只支持仿射位图转换（3D 太难管理，这就是我编写引擎的原因）——这意味着我无法实现大顶点的真实透视。

我可以做一个循环并根据其 Z 位置渲染位图的每个像素......但这比大多数计算机可以做的要多 1000 倍，因为透视是非线性的......

所以 - 解决方案是 - 将顶点自动拆分（因此程序员/建模者不必这样做）成更小的三角形。

不幸的是，这……波涛汹涌……？仿射变换不够精确，或者可能不够精确，但它们不适合其他三角形......要演示的图像：

（死图）

正如您在红色部分看到的那样，它们非常不稳定，在前中列最明显。

那么 - 我做错了什么？这在 Sandy、away3D、Alternativa 中是如何完成的？

编辑1：我用于转换为三角形的代码如下所示：

编辑2：这是变压器的一个小演示：

点击这里（死链接）

（箭头控制蓝点，1-3 更改选定的句柄 - 尝试使用小键盘和顶部数字键）

因此，在解决了我与 BGL 的循环依赖问题后，我遇到了另一个障碍。

我目前正在使用邻接列表来建模我的图。节点和边的捆绑属性用于在图中存储一些信息。所以我有这样的事情：

当我想在我的代码中的其他地方存储特定节点和边缘的快捷方式（例如，对于有多个车道的街道）时，就会出现问题。我的第一种方法是将 edge_descriptors 和 vertex_descriptors 保存在我需要的地方。但我想知道这样的描述符会有多大（以字节计）。也许有更好的解决方案，例如只存储一小部分信息以获得相同的结果。

有谁知道用于这种类型的向量的内存量：

我已经考虑过只存储指向 edge_descriptors 的指针，但我不知道这是否以及如何工作。

///////////////////////////////////////// ///////////////////////////////////////// ///////////////////////////////////////// ///////////////

编辑：既然我的第一个问题已经得到彻底回答，我仍然想知道一件事。我想为我的图形类构建某种接口。该接口应将图形类详细信息与必须不知道图形详细信息的其他类分开。因此，其他类最好将节点和边识别为数字。所以我想出了两个想法：

1. 我使用 hash_mapstd::tr1::unordered_map<int, edge_descriptor>能够将数字转换为描述符，然后再将其用作我的图形对象的索引。这可能是一步到位 - 如果有足够的节点和边要计算，那么哈希值的计算可能会花费太多时间。这就是为什么我有了第二个想法。
2. 图本身应在内部将这些数字转换为边和节点。我知道内部属性和属性映射可以用来实现我的想法。然后，您只需键入以下内容即可访问节点：
   boost::property_map<My_Graph, my_prop>::type index = get(my_prop(), G);

但是有没有办法将这些属性映射与我的捆绑属性结合起来？

或者你还有其他我没有想到的想法吗？