Mesh generation indices order

Unity Engine
,
1

Does the order of indices affect performance?

2

No, that shouldn’t be the case, unless maybe some specific condition applies. Maybe mesh compression or something like that.

3

If you are talking about the order in which you list vertices, no that should not affect performance.

If you are talking about the order of vertex indices in the triangle array, this mostly determines which side of the triangle is considered front or back. Unity uses a clockwise winding order.

Of course a triangle you dont render costs less performance, but i dont think this is what you meant :smile:

3 Likes
4

who knows. I just assumed OP meant the order of vertices. but now that you said it, maybe OP meant the triangles, because that’s where the ‘indices’ are. it’s good you covered the rendering itself, I was in doubt whether to complicate things further lol

1 Like
5

When i read your reply i wasnt sure if i should still reply at all, because i felt like i missed something obvious haha. But as OPs question is pretty unclear i thought i might aswell, even if it’s just for others stumbling upon it in the future. OP needs to clarify what specifically he meant tho.

1 Like
6

It would only effect performance if you removed indices.

So currently I have similar situation. Vertice size is increased for the sake of primarily uv wrapping. And so it is possible to reduce the size of the uv list and thus the performance of the vertex list by for example doing what a cube map skybox does.

though I say this, I am still working on such a thing myself.
You will see quality reduction. Depends whether you can live with that.

7

The only way you can reduce the size is by welding the vertices together. This is especially important for colliders and “smooth” geometry where the neighboring vertices all have to share a common normal. And sure, there are benefits, because the list is smaller, it weighs less in the memory, and performs better throughout the engine because a smaller list always performs better, however there are side-effects because you have to lose information in the process. So it’s not a no-brainer that applies to everything. And finally, this has nothing to do with the actual reordering of anything, that’s pretty much still a moot point.

Edit: I forgot to mention what Bunny emphasized in the next comment: having another mesh is having a greater impact on performance than doubling its size. This is because the hardware is optimized for lists and heavy loads, but the system as a whole has to be designed in such a way that the inter-layer communication becomes a bottleneck sooner than pure data capacity. Unless we’re talking about going over some reasonable hardware limits.

8

Watch out, you may be following a red herring here. While it is true that the number of triangles / primitives in a mesh do have an impact on performance, its usually not that great. That’s why we deliberately batch as many meshes as possible into a single mesh. The mesh itself has a much much greater overhead than the number of vertices / triangles. Of course you see a difference if you have a mesh with 4 vertices or one with 4 million. However you would see a minimal difference between say 4k vertices and 8k vertices unless this gets multiplied by a huge factor and you reach the actual limit of your GPU.

Just to make this clear as the way the title is worded could be misunderstood:

  • The order of indices does matter in two ways:

  • First of all of course the indices that make up a primitive (triangle / quad) does matter as it determines the winding order of those primitives and therefore in which direction the surface points

  • Second, the order of the primitives inside the indices array determines the order in which they are drawn by the GPU. In most cases this is not relevant as most shaders to use the z buffer and in a 3d environment the view of things can change so relying on a preselected order will likely fail. Though there are applications where the order may matter. In 2d you can implement the painters algorithm just through the order of things inside the mesh when the shader does ignore the z buffer as things are simply overdrawn in the order they have been specified.

  • From a performance point of view the order of indices should not really matter. It may have an influence on the fill rate performance. So when you have a mesh that has a lot self-overlap and you’re using the z buffer, the performance may differ depending on which direction you’re viewing it. As you may know, rendering opaque objects it’s always best to render the closest stuff to the camera first so things that get rendered behind are discarded early by the z buffer. Though as I said for 3d environments it’'s not really worth to sort geometry on a per-triangle basis as this sorting would be much more expensive. It may help for distant meshes (like 3d skybox levels in the distance. They are always sorted the same way as you never get “behind” the mesh).

  • The order of vertices should not matter at all as far as I know.

So in summary:
Yes, the order of individual indices per primitive is important, otherwise they don’t render properly. The order of primitives in the indices array can affect performance, but only in rare situations which is hard up to impossible to optimise for.

1 Like
9

I meant the order of the indices not the vertices list. I generated a mesh procedurally for the first time and was skeptical about performance. I thought that maybe there was some kind of optimization in the GPU if indices were close to one another. That seems to not be the case though, I did some testing creating a 1 million vertices mesh grid with different index order and noticed no difference.

That is really important but this is more about the mesh itself and not the indices order.

Thank you all guys!

10