我已經看到人們使用頂點或三角形作為一種快速的啟發式方法來估計網格內存的使用和網格渲染時間。

我一直認為頂點會更好，因為已知在頂點著色器中處理的頂點數量，而渲染的片段數量則取決於深度複雜度，與屏幕的距離，三角形的面積...。

但是，似乎三角形與頂點的使用頻率一樣高，如果您需要一個三角形來進行樸素的估計，哪個更好？

4

我已經看到人們使用頂點或三角形作為一種快速的啟發式方法來估計網格內存的使用和網格渲染時間。

我一直認為頂點會更好，因為已知在頂點著色器中處理的頂點數量，而渲染的片段數量則取決於深度複雜度，與屏幕的距離，三角形的面積...。

但是，似乎三角形與頂點的使用頻率一樣高，如果您需要一個三角形來進行樸素的估計，哪個更好？

geometrymeshperformancememory

3

Vertex count may be more accurate of a measurement of "mesh memory usage and mesh rendering time", but vertex count is not nearly as easily *measured*.

Yes, given a specific mesh with all of its attributes, it's easy to tell how many vertices are in it. But how many modelling tools can tell an artist how many vertices a given mesh will produce?

After all, the vertex count is usually based on the *topology* of the various attributes of a mesh. That topology changes when new positions are added or removed. That topology changes when texture coordinate vertices are added or removed. When smoothing groups are modified to create sharp edges. And so forth.

Furthermore, most modelling tools can't really give an accurate vertex count anyway, since they usually don't store vertices in the fashion that the rendering application will use them in. They tend to store the vertices as individual arrays with individual array indices, which is typically not how the renderer will see them. So most modelling packages cannot tell the user what the vertex count is, outside of writing a plugin to provide that information.

So if you're trying to communicate a limitation to artists, the easiest way to give them an approximation of what they have to work with is to provide a triangle count. Yes, the hard limit is the number of vertices, and the asset conditioning pipeline should certainly reject meshes/whatever that are too big for the available memory.

But triangle count is more useful as a "quick heuristic" than vertex count.

3

Since you're talking about "vertex shaders" and "fragments", I assume that your question is to be interpreted in the context of real-time rendering using the graphics pipeline on a modern GPU through some modern graphics API. Even if we narrow down the question like that, I don't think a general answer can be given to what you're asking. It depends a lot on what kind of meshes/scenes/application you're dealing with. In general, it's not even clear what "number of vertices" or "number of triangles" should mean exactly. There isn't really *the* number of vertices and *the* number of triangles. If you're rendering a non-indexed triangle strip, then there's a direct relation between the number of vertices and the number of triangles. If you're rendering an indexed triangle list, then do we count the number of vertices that were referenced, the number of vertices that were shaded, or do we count the number of indices that were used to form triangles? If you're rendering patches with tessellation, then is the number of vertices the number of control points or is it the number of vertices produced by the tessellation? What if I have a geometry shader that eats a few points, and turns them into loads of overlapping triangles? What if my geometry shading streams the odd triangle to a stream output buffer but doesn't send anything to the rasterizer at all!? The point is, there's a great many different places in a graphics pipeline where something that one might call a "vertex" or a "triangle" could pop up…

In a typical triangle mesh that is supposed to represent the boundary surface of some physical object, there will be a direct relationship between the numbers of vertices and triangles. In such cases, either the number of vertices or the number of triangles is arguably as good a measure as the other when it comes to giving an estimate of mesh complexity. But then, what "complexity" are we talking about exactly? Complexity in terms of storage can probably be estimated from either number of vertices or triangles as explained above. Complexity in terms of rendering time is a whole different story. Depending on your application, it might be that neither the number of triangles nor the number of vertices is a good predictor for performance at all. It's actually trivial to write a program that makes even the latest and greatest graphics card sweat by rendering only a single triangle using no vertex buffer. Because your bottleneck is rasterization, fragment processing, or the framebuffer, for example. In such a case, you'd probably be more interested in the number of fragments produced, or the depth complexity…