Perfs 3 vertices per triangle vs shared vertices
Community Forums/General Help/Perfs 3 vertices per triangle vs shared vertices
| ||
| Hello, I am wondering if it is better (for the render and for the perfs) to use a mesh with several triangles with shared vertices or to use a mesh with several triangles with 3 vertices per triangle. Why would i need 3 vertices per triangle you may ask ? Because it is easier to do UVMapping (to set the UV coords) without having to unweld individual triangle or groups of triangles. Moreover i think it should be possible to recalculate all vertices normals in order to have a progressive lighting even if each triangle has its own 3 vertices. Your thoughts about this ? It seems 3D World Studio does that, each triangle has its own 3 vertices (or 4vertices when it is a quad). I ask this because i may decide code a building modeler and UVMapping is a complicated matter. Thanks, Last edited 2013 |
| ||
| Not an expert but fewer verts = smaller data set which makes any searching or scanning pass on an object potentially significantly faster... as relates render time I don't think it would matter much since it renders tris and the tris reference their verts so shouldn't make a difference there. Just more memory and if you're searching for a vert for any reason (projection or collision testing perhaps) could take way long since your vert count could be ~3x as big. 3x more verts is 3x more memory for verts but that's still trivial memory use compared with say a single texture so wouldn't be too concerned about that. |
| ||
| as relates render time I don't think it would matter much since it renders tris and the tris reference their verts so shouldn't make a difference there. Just more memory Thanks for the explanation ima747, this is good if it does not increase the render time. About the collision calculation i don't care because i will use low tris colliders. And about the memory i don't think this will be a problem to have a few more vertices stored. Ok! Last edited 2013 |
| ||
| I have done some tests and it seems that more vertices = more render time ! I am surprised about this. I don't know exactly how 3d rendering works but i thought that each vertex of each triangle was retrieved and thus the number of vertices would not matter. But apparently it is not so. For the same shape, Render3d takes around 22ms with 100 meshes with shared vertices between some triangles and Render3d takes around 33ms with 100 meshes with 3 vertices per triangle If you are interested you can download the example here : http://rd-stuff.fr/Triangles_with_shared_vertices_vs_triangles_with_3_vertices_2013.01.27_18h48m.zip Not good for me, but i can't change it, so i guess i have to find another way to achieve what i want. |
| ||
| More vertices will slowdown T&L (transform and lighting). http://en.wikipedia.org/wiki/Transform,_clipping,_and_lighting |
| ||
| I don't know exactly how 3d rendering works but i thought that each vertex of each triangle was retrieved and thus the number of vertices would not matter. You need to store the data for the vertices somewhere. You usually do this in the GPU's memory for super-fast access. In the past, most people have been using something known as a Display List - with it, you were able to store a sequence or vertices, including their normal data and whathaveyou, and then later call the list with just one operation. Extremely effective for static geometry. However, today I would recommend using something known as Vertex Buffer Objects. They essentially allow for the same thing, except that you can manipulate vertices even when they are already stored in the GPU's memory. They are arguably one of the fastest method to render geometry. Here's a bit more info on those: http://en.wikipedia.org/wiki/Vertex_Buffer_Object http://www.songho.ca/opengl/gl_vbo.html http://nehe.gamedev.net/tutorial/vertex_buffer_objects/22002/ Hope that helps. |
| ||
| Beaker and SystemError51>> Thanks for the links, i will take a look. |
| ||
| I'd take a guess that the hardware can reuse shared verts. As in, for two triangles with two shared vertices it has to transform all three verts for the first triangle, but can then reuse the two shared verts when processing the second triangle. Ideal conditions would give you ~1 vertex T&L calculation per triangle, instead of with separate verts that you suggested, which would require 3 T&L calculations per triangle. |
| ||
| agree with zzz, re-using the calculations performed on the verts is the time saving in the render pass. I think there's proabably some pretty significant ways one could optimize the renderer for non-recycled verts, but there could be some pretty major implications in other areas (like beaker said, T&L). It's going to depend on how your renderer works in addition to the hardware in the eld. Fundamentally more is always more, and that *usually* means more work to process the more data. The exception to that rule is when you're using more data/memory as form of pre-processing in a way (simple example is precalculating rotation maps etc. where you're doing the work once then storing it so you can just access an array rather than run the calculations again and again). My previous assumption was based on a) no operations being performed in time critical points on vertexes b) vertexes being referenced from a render pass on a tri, so the verts themselves are never directly sorted or accessed accept as a reference. This is not likely to be how the hardware accelerator is going to handle things with anything particularly modern. |
   |