I have messed around with vertex arrays before and now it is time I implement CVAs in my mini engine to get some kind of performance out of it. 700K tris/s isn’t much and I know I am geometry limited at times.
One thing I thought I liked about Vertex arrays is that you could share vertices- store the 8 vertices of a cube instead of 36 for each triangle or 24 if using tri-stips/ quads per a face. This could lead to a large performance increase! However Just because some polygons vertices are in the same place as anothers doesn’t mean that they will have the same texture coordinates and so you basicly end up having to store each coordinate of each polygon inside the vertex array instead of just each unique vertex. Using glArrayElement you can specify seperate tex-coords but it is slow anyway. To use glDrawElements you would not be sharing any vertices so it is hard to see where much of a performance gain can come from.
Ex. a simple landscape engine with a 257* 257 heightmap giving 2562562 triangles * 3 vertices ~= 400K verts to transform compared to 66K if vertices were all shared. You would have to use the first case since each vertex would/could have a different texture coordinate or colour.
Am I being stupid or am I correct in thinking that you can’t practicly share vertices.
I’m not sure I follow you correctly - why would two adjacent triangles always have different texture coordinates on the vertices they share?
Look at a character model for example - most times you have one texture used by the whole model - so shared vertices will most of the time use the same texcoords as well. Usually (depending on how your models are built), only if you are using 2 different textures in 2 adjacent triangles is when you need separate sets of texture coordinates (at least if the models are constructed in a clever way), and hence 2 separate primitives.
Imagine for example a corridor with little spotlights in the ceiling. Ideally, you would construct this ceiling as a single triangle strip (2 verts of every triangle are shared) and have a texture with one spotlight for 2 triangles forming a quadriliteral tile over the whole corridor ceiling.
Most landscapes have textures projected onto them using planar projection, and a single texture will wrap across multiple tris/quads. In that case - which is the most common one - you do not need to specify new coordinates.
I see your point in those examples, e.g. if a rectangle was somehow split into 2 small rectangles then where the two meet those vertices would have the same texture coordinates. However in the terrain example, if you had 2 aligned quads sections and you textured each quad seperately based on the area of the quad (to avoid a stretched texture on a steep slope) then each quad could/would have seperate texture coordinates.
|
|
U = -----> , V = \|/
1.784..., 0
__ /|
0,0 1,0 0,0_ / |
|---------|/ |
| \ | |
| \ | __ / 1.784..., 1
| \ | _ /
|________\|/
0,1 1,1 0,1
This is the way that I have my levels textured and so those shared vertices have different texture coordinates. Also note that the next quad to the right would start at 0,0 / 0,1 and so would have different tex-coords again.
This could be solved by doing this:
But that is difficult for a general quake type level. Additionly even if 2 adjacent polygons have the same texture they could have different scales and or rotations although some would line up OK. This would be difficult to program to take into acount some shared and some unshared vertices but should be possible.
Basicly I render using an octree into arrays for each texture and of each primitive type, these can be sorted by z distance from front to back these are then rendered to the screen. However this method is still not fast enough so I was looking at vertex arrays to speed up the geometry rate. Any other advice?
Tim
[This message has been edited by Tim Stirling (edited 09-03-2001).]
hope i understood
any vertices that need different texture coordinates will need to be duplicated ( i believe this is what quake does ieif u make a cube with 8 vertices, it will actually create 24 vertices.
of course this aint ideal but what else can u do?
