hi
i have an array of vertices and an array of indices to these vertices,
plus i have an array of texture coordinate and an array of indices to
these tex coords.
the two arrays have different sizes and different indices but both r
used to build a single object.

i would like to render my object with glDrawElements but the indices
parameter only relates to the array of vertices so the textures doesnt
come out good.

is it possible to do what i want ?
is it possible to have a different indices array for the tex coords
array ?
is there another method i can use in order to improve performance like
glDrawElements ?  (i know i can "manually" draw each array with
glArrayElement)

thanx,
noam.

noam_b@yahoo.com wrote:

> is it possible to do what i want ?

No, because it makes no sense. A vertex is more than it's
position. It's the complete tuple of position, normal, texcoord,
colour... So each texture coordinate is bonded with its vertex. 

> is it possible to have a different indices array for the tex
> coords array ?

No, becuase it makes no sense. Maybe you think, that a vertex
shares n texture coordinates, but in fact these are n difference
vertices. So actually you have to store n vertex, texcoord
combinations.

@fungus: Could we please add this to the FAQ? This sort of
question is asked about 3 times a month.

Wolfgang Draxinger
-- 

noam_b@yahoo.com wrote:
 > is it possible to have a different indices array for the
 > tex coords array ?

Nope. There's only one index array.

 > is there another method i can use in order to improve 
performance like
 > glDrawElements ?  (i know i can "manually" draw each 
array with
 > glArrayElement)
 >

You can use glDrawElements() but you have to
match the texture coordinates to the vertices.

Think of a "vertex" as both position AND other
attributes (texture coord, normal, color).



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Wolfgang Draxinger wrote:

> No, because it makes no sense. A vertex is more than it's
> position. It's the complete tuple of position, normal, texcoord,
> colour... So each texture coordinate is bonded with its vertex. 

Wolfgang, it does indeed make sense. Otherwise it wouldn't come up
every week or so. It happens that the people in charge of OpenGL,
the ARB, decided to have only one index array applicable to all
other arrays rather than having an index array per data array.

It might be impractical to have 7+ distinct index arrays, but
please don't argue that it doesn't make sense.

--
Andy V

Andy V wrote:

> Wolfgang, it does indeed make sense. Otherwise it wouldn't come
> up every week or so. It happens that the people in charge of
> OpenGL, the ARB, decided to have only one index array
> applicable to all other arrays rather than having an index
> array per data array.

Well, maybe from an memory saver point of view, but not from an
performance point of view. Say you've got 1000 indices for the
vertex vector, 500 for the texture unit 1, and 200 for the
texture unit 2 this would make a total of 1000*500*200=100000000
possible combinations (keep that in a cache...) (*)

Using however a common index array only has the advantage, that
data belonging together also shares about the same offset,
allowing for efficient prefetch.
 
> It might be impractical to have 7+ distinct index arrays, but
> please don't argue that it doesn't make sense.

It's impractical, thus making no sense to me. I prefer practical
solution above theoretically possible ones, that however imply a
whole bunch of quirks - like the ones that araise from different
index arrays.

Wolfgang Draxinger

(*) The whole OpenGL state machine can be described by a vector
(in the gerneral, abstract mathematical sense), this is also
stated clearly in the OpenGL spec. Upon supplying a vertex the
whole state vector + the vertex position make up the vertex
vector. For several reasons most of the OpenGL state machine
vector is frozen between glBegin and glEnd calls, but there are
a few elements of the vector, that can be changed, that are
colour, normal, texcoord(s), vertex attributes - all the stuff
you can change between glBegin and glEnd. The final vertex
vector is a linear combination of the global state vector and
the local vertex state vector. Now if it would be possible to
supply different indices for the set of local vertex state
vectors a linear combination of all state vectors would have to
be created. 
-- 

"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message
news:drttq2-uo8.ln1@darkstargames.dnsalias.net...
> Andy V wrote:
>
> > Wolfgang, it does indeed make sense. Otherwise it wouldn't come
> > up every week or so. It happens that the people in charge of
> > OpenGL, the ARB, decided to have only one index array
> > applicable to all other arrays rather than having an index
> > array per data array.
>
> Well, maybe from an memory saver point of view, but not from an
> performance point of view. Say you've got 1000 indices for the
> vertex vector, 500 for the texture unit 1, and 200 for the
> texture unit 2 this would make a total of 1000*500*200=100000000
> possible combinations (keep that in a cache...) (*)
>
> Using however a common index array only has the advantage, that
> data belonging together also shares about the same offset,
> allowing for efficient prefetch.
>
> > It might be impractical to have 7+ distinct index arrays, but
> > please don't argue that it doesn't make sense.
>
> It's impractical, thus making no sense to me. I prefer practical
> solution above theoretically possible ones, that however imply a
> whole bunch of quirks - like the ones that araise from different
> index arrays.
>
> Wolfgang Draxinger
>
> (*) The whole OpenGL state machine can be described by a vector
> (in the gerneral, abstract mathematical sense), this is also
> stated clearly in the OpenGL spec. Upon supplying a vertex the
> whole state vector + the vertex position make up the vertex
> vector. For several reasons most of the OpenGL state machine
> vector is frozen between glBegin and glEnd calls, but there are
> a few elements of the vector, that can be changed, that are
> colour, normal, texcoord(s), vertex attributes - all the stuff
> you can change between glBegin and glEnd. The final vertex
> vector is a linear combination of the global state vector and
> the local vertex state vector. Now if it would be possible to
> supply different indices for the set of local vertex state
> vectors a linear combination of all state vectors would have to
> be created.
> -- 
>

Well, there IS a special case that is both consistent and theoretically
efficient --
FLAT shaded with one normal/color per face. Sadly, no go, much to my
disappointment.

jbw

> Andy V wrote:
> 
> 
>>Wolfgang, it does indeed make sense. Otherwise it wouldn't come
>>up every week or so. It happens that the people in charge of
>>OpenGL, the ARB, decided to have only one index array
>>applicable to all other arrays rather than having an index
>>array per data array.
> 
Wolfgang Draxinger replied:
> 
> Well, maybe from an memory saver point of view, but not from an
> performance point of view. Say you've got 1000 indices for the
> vertex vector, 500 for the texture unit 1, and 200 for the
> texture unit 2 this would make a total of 1000*500*200=100000000
> possible combinations (keep that in a cache...) (*)

There is certainly no need to keep all the possible combinations in a cache --
why would you want to? The state is certainly sepearable.

> 
> Using however a common index array only has the advantage, that
> data belonging together also shares about the same offset,
> allowing for efficient prefetch.

Of course, you would only ever need two elements in the edge flag array,
so there could be considerable savings in memory there. Big :-) here.
>  
> 
>>It might be impractical to have 7+ distinct index arrays, but
>>please don't argue that it doesn't make sense.
> 
> 
> It's impractical, thus making no sense to me. I prefer practical
> solution above theoretically possible ones, that however imply a
> whole bunch of quirks - like the ones that araise from different
> index arrays.

If the application data is set up with a separation of position and
texture coordinates, for example, you could make the argument that
forcing the application to duplicate data is impractical.
> 
> Wolfgang Draxinger
> 
> (*) The whole OpenGL state machine can be described by a vector
> (in the gerneral, abstract mathematical sense), this is also
> stated clearly in the OpenGL spec. Upon supplying a vertex the
> whole state vector + the vertex position make up the vertex
> vector. For several reasons most of the OpenGL state machine
> vector is frozen between glBegin and glEnd calls, but there are
> a few elements of the vector, that can be changed, that are
> colour, normal, texcoord(s), vertex attributes - all the stuff
> you can change between glBegin and glEnd. The final vertex
> vector is a linear combination of the global state vector and
> the local vertex state vector. Now if it would be possible to
> supply different indices for the set of local vertex state
> vectors a linear combination of all state vectors would have to
> be created. 

Since the OpenGL state that you mention is indeterminate after a
DrawArray or DrawElements if the applicable arrays are enabled, there
is no expansion of state. If the spec changed to define that state
then there would be a single state vector -- probably the last values
that would be set by the pseudocode in the spec.

--
Andy V