"Wolfgang Draxinger" <wdraxinger@[EMAIL PROTECTED]
> wrote in message
news:o94dg5-kpc.ln1@[EMAIL PROTECTED]
wrote:
> Is there a technical reason? (i.e, h/w limations)
>
> Am I missing something?
It's due to mathematical reason. A vertex is not merely a
position. A vertex is a n-dimensional vector consisting of
position, colour, normal, texture coordinate, etc. all in one
entity.
So even if vertices differ in say only one element of the normal,
they're still completely different vectors.
Now cosider the data you want to render as a ordered set of such
vectors. In such a set you give each distinguishable vector a
own index (the index you refer to in glDrawElements). Now if
you'd put two identical vectors into the set, they'd be
indistinguishable, and thus get the same index, because they're
the same vector. But change only one element of the vector and
you got them distinguishable.
In fact you're dealing with different vectors, even if may have
you thought, they would share something.
Now OpenGL operates on those compound vectors, which implicates,
that in such a situation like your's you're dealing not with a
structure like your's
> v[] = { 0,0,0,
> 1,1,0,
> 0,1,0 }
>
> n[] = { 1,0,0
> 1,0,0,
> 1,0,0 }
But instead with something like
typedef struct vertex {
GLfloat p[4];
GLfloat n[3];
} vertex;
vertex V[] = {
{ {0,0,0}, {1,0,0} },
{ {0,0,0}, {0,1,0} },
{ {0,0,0}, {0,0,1} },
{ {1,1,0}, {1,0,0} },
{ {1,1,0}, {0,1,0} },
/* the permutations you want/need ... */
};
Where each element of V has it's own index.
Now you might wonder, what about immediate mode (glBegin/glEnd).
Well, you got there a scrap vector into which values are put
with glColour, glNormal, etc. and then upon call of glVertex the
position if filled into and _then_ the whole long vector is sent
for processing. Unfortunately this scheme let people assume,
that there might be shared something. It would be clearer, if
the call of glVertex clears that scrap vector, so that you'd
have to reset everything for each vertex. But this would
contradict the idea of a statemachine, which OpenGL is, and
would be even more inefficient like immediate mode is already.
Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@[EMAIL PROTECTED]
ICQ: 134682867
Yes, but, if you really want to draw face-normal data, it turns out that
(in
my tests) using display lists to do so on pro-grade cards (optimized for
DL's) can be faster than having to create & shove down excess normals,
even
with VBO's. Float3 Normals are big! when you are talking about a large
structure (reservoir model, for instance).
-jbw
|
