internal model format
Author
So I''m working on getting models in some of my demos and everything. I''m now starting to get into animating models, and I''ve run into a question that experience would help answer.
Some (maybe most) models have vertex indexing for their triangles. When drawing them statically it''s good to make a seperate continuous list of verts and use VertexArray or something. This uses more memory, but is faster. Simple give and take... easy.
Now if you apply the same theory to animated models, it''s a little harder to decide what to do. Is it better to have indexed vertices.. and take less time to calculate the animation, but more time to send the data through openGL. OR after transforming the vertices, make a new continuous list of vertices and use VertexArrays or something to send the data?
I just wanted to know the opinion of some more experienced programmers.
Thanks
It is unlikely that the index data will need to be changed over the animation. Neither will the texture coordinates.
The only things which will change are the vertices and lighting if you are using lighting for your animated models.
So u can use the same index array. And also, using vertex arrays which use shared vertices(most 3d file formats support shared vertices) reduces memory and increases speed at the same time because simialar vertices are not repeated.
Each duplicate vertex costs 12 bytes if they are floats. Each index only costs an integer(forgot how much an integer is).
The only things which will change are the vertices and lighting if you are using lighting for your animated models.
So u can use the same index array. And also, using vertex arrays which use shared vertices(most 3d file formats support shared vertices) reduces memory and increases speed at the same time because simialar vertices are not repeated.
Each duplicate vertex costs 12 bytes if they are floats. Each index only costs an integer(forgot how much an integer is).
Author
Correct, the index data and the texture coords will not change.
I think I misled you on the question. I was wondering if it is better to have indexed vertices, or create a new list of vertices (which will have duplicates) that I can use a VertexArray on.
For example. For a cube, you can use 8 vertices in an array. Each quad on the cube uses an index into the vertex array. You cannot use (at least as far and I know) a VertexArray on this because the data is indexed. To use a vertex array, you will have to make a new array of vertices. Our new list will have ( 6 faces * 4 verts per face) 24 vertices instead of 8. The advantage of this is you can do a Vertex Array on the new list.
Now if we want to animate the cube.. we would have to update this new array every frame in order to use the VA.
Is this way any better for ~1k poly models? Is it too much of a hassle to update this new list every frame when doing animation?
I think I''m just VertexArray happy.. and don''t want to use glvertex3f.
I think I misled you on the question. I was wondering if it is better to have indexed vertices, or create a new list of vertices (which will have duplicates) that I can use a VertexArray on.
For example. For a cube, you can use 8 vertices in an array. Each quad on the cube uses an index into the vertex array. You cannot use (at least as far and I know) a VertexArray on this because the data is indexed. To use a vertex array, you will have to make a new array of vertices. Our new list will have ( 6 faces * 4 verts per face) 24 vertices instead of 8. The advantage of this is you can do a Vertex Array on the new list.
Now if we want to animate the cube.. we would have to update this new array every frame in order to use the VA.
Is this way any better for ~1k poly models? Is it too much of a hassle to update this new list every frame when doing animation?
I think I''m just VertexArray happy.. and don''t want to use glvertex3f.
quote:Original post by mrrolf810p
Is it better to have indexed vertices.. and take less time to calculate the animation, but more time to send the data through openGL.
Hmm. Use indexed vertices. Rationale: if you apply an operation to the vertices in a model, if shared vertices are stored seperately for each face, it will very likely be that inaccuracies in the calculations will mean the vertices don''t match up any more. That would be bad.
I''m unsure how indexed vertices take longer. I use glDrawElements to use non-sequential vertices from a vertex array, which is plenty fast enough for me, and certainly faster than using glDrawArrays, since I send fewer vertices.
CoV
@mrrolf810p / Mayrel:
but there is another question to me, if i consider this way of using vertex arrays - and yes, that's the reason which keeps me from using "indexed vertex arrays":
the problem is then, that you have to store each u/v coord for each vertex anyway, because the "indexed vertex" tells GL to draw the three vertices/uv coords for a triangle, by using GL_TRIANGLE, at vertexarray-index 0,3,9; for example - but the problem is, that there is no chance to do "real" u/v coord sharing, this means that the vertices with the index 0,3 and 9 have to own the u/v coords themselves. but perhaps there are cases where 0,3,9 have the same u/v coords, so i have no chance to consider this with indexed vertex arrays. for example: if you are exporting from tools like 3dsmax, there is a special u/v coord array, which holds the u/v coords for the vertices, which are indexed by the faces - a face don't only hold a,b,c for drawing the vertices, it also holds the information where to grap u/v(/w) from the array, so there is really no 1-to-1 relation between a vertex and it's u/v coord and it'S normal, everything get's associated by the face-array, which holds all relevant information.
so, i don't see a real advantage of index vertex arrays in comparison with "standard" vertex arrays.
one point may be (!!!) the post-TnL-cache on todays GPU'S, which could increase the performance slightly; but i'm not sure about this; possibly, one of the GL-gurus (Yann L perhaps?) around here can tell us more about this.
DJSnow
-----
this post is manually created and therefore legally valid without a signature
[edited by - DJSnow on August 6, 2003 7:54:03 PM]
but there is another question to me, if i consider this way of using vertex arrays - and yes, that's the reason which keeps me from using "indexed vertex arrays":
the problem is then, that you have to store each u/v coord for each vertex anyway, because the "indexed vertex" tells GL to draw the three vertices/uv coords for a triangle, by using GL_TRIANGLE, at vertexarray-index 0,3,9; for example - but the problem is, that there is no chance to do "real" u/v coord sharing, this means that the vertices with the index 0,3 and 9 have to own the u/v coords themselves. but perhaps there are cases where 0,3,9 have the same u/v coords, so i have no chance to consider this with indexed vertex arrays. for example: if you are exporting from tools like 3dsmax, there is a special u/v coord array, which holds the u/v coords for the vertices, which are indexed by the faces - a face don't only hold a,b,c for drawing the vertices, it also holds the information where to grap u/v(/w) from the array, so there is really no 1-to-1 relation between a vertex and it's u/v coord and it'S normal, everything get's associated by the face-array, which holds all relevant information.
so, i don't see a real advantage of index vertex arrays in comparison with "standard" vertex arrays.
one point may be (!!!) the post-TnL-cache on todays GPU'S, which could increase the performance slightly; but i'm not sure about this; possibly, one of the GL-gurus (Yann L perhaps?) around here can tell us more about this.
DJSnow
-----
this post is manually created and therefore legally valid without a signature
[edited by - DJSnow on August 6, 2003 7:54:03 PM]
quote:Original post by MayrelIs this a real concern? The coordinates for a duplicate vertex are exactly the same as the original vertex''s coordinates so their transformed values would also be the same. I don''t see how there might be gaps between a pair of edges with identical coordinates, unless for some reason the fragment coordinates along a duplicate edge are calculated differently for each polygon.
Hmm. Use indexed vertices. Rationale: if you apply an operation to the vertices in a model, if shared vertices are stored seperately for each face, it will very likely be that inaccuracies in the calculations will mean the vertices don''t match up any more. That would be bad.
quote:Original post by mrrolf810pI don't understand this. Why makes you think indexed vertices are any different from vertex arrays? Indexed primitives are drawn by dereferencing the contents of vertex arrays, so I don't see why you'd need to recreate the list of vertices. If you're using vertex arrays then you should keep the original indexed vertices, otherwise there's no reason to use vertex arrays other than to avoid function call overhead.
I think I misled you on the question. I was wondering if it is better to have indexed vertices, or create a new list of vertices (which will have duplicates) that I can use a VertexArray on.
quote:Is it better to have indexed vertices.. and take less time to calculate the animation, but more time to send the data through openGL. OR after transforming the vertices, make a new continuous list of vertices and use VertexArrays or something to send the data?What makes you think sending duplicate vertices is faster than using indexed vertices? That cannot be true in the general case because an indexed mesh generally requires less memory than its equivalent non-indexed mesh. Less memory means it takes less time to send the data to OpenGL, so using indexed vertices is generally faster.
[edited by - chronos on August 6, 2003 9:08:07 PM]
Author
Here is how I saw to draw ''indexed vertices'' :
I knew that doing it this way is slow. So I made a new list of vertices. I had (numTriangles * 3) vertices in the new list. The new list had much duplicate data, but I thought the speed of using glDrawArrays() would overcome the increased memory useage. This got complicated when I had to animate the model.. so my original question was if doing the new List was worth it when animating.
But now glDrawElements(...,const GLvoid *indices) has been brought to my attention, I see that this is probably the best technique to use. I was just ignorant of this function when I first asked the question.
Thanks for the help.
glBegin()for(i=0;i<numTriangles;i++){glVertex3fv(vertList[triangle[i].vert[0]].xyzData)glVertex3fv(vertList[triangle[i].vert[1]].xyzData)glVertex3fv(vertList[triangle[i].vert[2]].xyzData)}glEnd();I knew that doing it this way is slow. So I made a new list of vertices. I had (numTriangles * 3) vertices in the new list. The new list had much duplicate data, but I thought the speed of using glDrawArrays() would overcome the increased memory useage. This got complicated when I had to animate the model.. so my original question was if doing the new List was worth it when animating.
But now glDrawElements(...,const GLvoid *indices) has been brought to my attention, I see that this is probably the best technique to use. I was just ignorant of this function when I first asked the question.
Thanks for the help.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
