> With hardware T&L, the cost of sending a vertex that is already
> transformed and the cost of sending an untransformed vertex is the same.
Sorry, I wasn’t very clear with this.
What I meant to say was that if you send a vertex to the GPU when there is a modelview transform, and then send another vertex when the modelview transform is set to the identity matrix, the GPU will process them at almost exactly the same speed.
Hm. That is questionable. I think OGL will send only vertexec that
was not transformed before and (GPU holds the result, if possible).
If there is a need to reuse a vertex - OGL will send a index instead
of (useless) vertex data (again - only if GPU supports VertexArray).
The problem with this is that then OpenGL needs to know which vertices the GPU has in cache. With current hardware, you can’t do this. Even if you could, you would have a lot of communication between the GPU and the system memory, which once again slows things down.
> In an implementation without hardware T&L, your method might help. You
> would save yourself some transformation calculations, but on the other
> hand, you would need to check the cache of stored information every
> time you specified a vertex or normal, so that could slow you down.
Why should this slow it down? I don’t understand your line of
reasoning here. So i present how I think it could(should) be …
As first we have a array for (cube) data
V1x,V1y,V1z,N1x,N1y,N1z,V2x,V2y,V2z … - (F)irst array
where V1x means - first Vertex x cordinate (and so on). Now we call
glDrawElements that will use this array. OGL creates a list (at CPU
ram as (S)econd array) for flags for evry element in (F) array.
If OGL needs to calculate a new indexed vertex, it will look
at array (S) to be sure there is a need to calculate it.
If it was not calculated before - it will be done now (if possible
What I was saying is that since you would have a cache, each time you specified a vertex or a normal, you would have to go through the cache. If you have a small cache, it would be faster than calculating each vertex. If you have a large cache, the time to find out if the index is already calculated might be longer than the time to simply calculate the vertex anyway.
If you have a small cache, though, you will not be able to reuse the vertices very much, and the benefits of your method would be lost, because you would always need to be respecifying vertices and normals instead of getting them from the cache.
Let say; i have 1 vertex with 2 surfeces connected to it (same Normal)
and different texCoords - i must define (and calculate) 2 vertexec.
I see what you are saying now.
It’s basically the same thing as re-using vertices and normals, except with texture coordinates, so most of what I’ve said so far applies.
The way I see it, your new type of vertex arrays can save memory, but I think it would be very hard to reduce vertex processing with them. The cases where it would work best would be where there are a lot of vertices that share positions, but have different normals and texture coordinates. This mainly occurs in models that have a lot of flat planes and sharp edges. Because of the nature of these types of models, they generally do not use a lot of polygons to draw, so the benefit of your idea is not that high. If you are drawing smooth models with sharp edges in certain places, the amount of vertices that benefit from your scheme is low compared to the number that don’t (which have shared vertex, normal, and texture coordinates) because they can use normal vertex arrays, which are easily accelerated with the GPU.
I’ve posted a message in the advanced message board asking for matt’s opinion on this.
I am working on a project that uses a lot of static data.
As I use Texturing and LIGHTS - in my case VertexArrays are
out of the question. So I was forced to use Display lists.
And that is not good enough for me - then my project is
geomety limited. I was trying to fix that, and have
run out of options. But something else comes in mind …
By the way, for the application you mentioned in your first post, how many vertices are you drawing? Is your performance unacceptable? It may be that we can figure out a way to speed up your program using existing OpenGL functionality.
j
[This message has been edited by j (edited 11-30-2000).]