koobas.hobune.stream
GPU performance with tris and verts
I am experimenting with various ways of implementing 2D tiles with dynamic paint/erase at runtime. To simplify performance at runtime I am considering leaving vertex data untouched, it would always represent the maximum number of tiles that the grid can contain:
rows * columns * 4
When a tile is painted triangles are formed easily by calculating triangle indices.
When a tile is erased (given row and column) the triangle is somehow found and removed.
From previous shader discussions I have learnt that the number of vertices in a mesh is a massive contributing factor in terms of performance.
Will unused vertices incur additional overhead (with exception of data transfer)?
Not really, since degenerate triangles are skipped over when rendering. However, performance-wise you'd be much better off leaving the triangles alone and uploading changed vertices. Number of vertices in a mesh isn't that big of a deal in most cases, relatively speaking; other things such as the kind of shaders used and number of objects (draw calls) can be larger factors.
Thanks! "However, performance-wise you'd be much better off leaving the triangles alone and uploading changed vertices" Would you $$anonymous$$d expanding upon that?
Uploading triangles is several times slower than uploading vertices, so if you can leave triangles alone and upload vertices ins$$anonymous$$d of the other way around, it will be faster.
@Eric5h5: I'm wondering why? Aren't both just data arrays? Does the GPU perform some postprocessing after the data is uploaded? Or is it cache related?
@Bunny83 I have been experimenting and to me it seems that changing vertices is more expensive in my scenario. When vertices are changed you also need to change uvs, normals (all per-vertex data).
In my situation if I pre-fill a mesh with all grid vertices and normals, then all I need to do is change uvs, triangles and submeshes. I haven't experimented with the sub-mesh aspect of this yet...
Perhaps that will be the killer performance-wise. If that is the case I can just have an entirely separate mesh for each material as there is no obvious benefit to combining multiple materials into a single mesh.
