glTexCoord2f and glMultiTexCoord2fARB

[JanHH]

in my program, the following things happen:

glActiveTextureARB(GL_TEXTURE0_ARB);
...
glEnable(GL_TEXTURE_2D);
...
glTexCoorf2f(...);

and everything looks fine. I guess that when enabling only texture unit 0, glMultiTexCoord2fARB and glTexCoorf2f work just the same!? or why does my program look fine?

Jan

[Sourpotato]

If everythings look fine. so what's your problem here,enn?

[JanHH]

sounds right somehow.. i will go on working on it and post againg if it does not look fine anymore

Jan

[gator]

Of course glTexCoord2f works when the texture unit is set to zero.
Why shouldn't it? Everybody uses unit 0, regardless if you are doing
multi-texturing or not.

But I would only use glMultiTexCoord2fARB if you doing multi-texturing
on more than 1 texture unit as that's what it's there for.

[JanHH]

i thought it could be a problem because there are parts in the scene of which some have multitexturing and others COULD have but in fact do not, and they are treated the same internally. so the parts who COULD have more than one texture but do not have use glMultiTexCoord2fARB while other parts of the scene, who definitley have only one texture, use glTexCoord2f. But it seems to work fine (as it looks fine).

Jan

[zeckensack]

I see immediate mode more as a utility for prototyping and testing. Somewhat more finished code will probably use vertex arrays, and then the difference between unit 0 and higher units will vanish.

[JanHH]

what kind of difference do you mean? btw everything is inside of display lists..

Jan

[zeckensack]

Originally posted by JanHH:
what kind of difference do you mean?

Nothing big ... let's rehash this.
In immediate mode you have two basic ways to specify unit 0 texcoords.
1)glTexCoord*(...)
2)glMultiTexCoord*ARB(GL_TEXTURE0_ARB,...)

One could argue that the second option adds additional function call overhead and should be avoided, but that's borderline irrational. If you want performance, you shouldn't be using true immediate mode (as in "not a display list") in the first place. Hmmm. I see you have that one covered.

However, there's no such alternative with vertex arrays. glTexCoordPointer always follows the selection made by glClientActiveTexture.

So the difference is that a choice goes away.

btw everything is inside of display lists..

Jan

Interesting. Geometry inside a display list behaves just like a vertex array in fast graphics memory, I'd say. I don't think it'll make any difference whatsoever in that case.

[JanHH]

before i started posting here i thougt that display lists are the best solution in terms of performance (if the geometry data is not too big), but when i wrote about that here, people seemed shocked *g*, one said "never use display lists" or "use them very rarely" but i never got explained WHY this should be the cause.

Theoretically DL should be the fastest possible solution because every data is already inside of the graphics card memory, and also in a precompiled way. So does anyone know what is wrong with this and WHY vertex arrays are faster/better??

[V-man]

Originally posted by JanHH:
Theoretically DL should be the fastest possible solution because every data is already inside of the graphics card memory

There is no guarantee that this is true. The driver may use vertex array like calls to speed things up.

Don't worry about performance if you started to learn GL.