texture performance question

hard to tell without knowing what exactly youre doing. the code you posted should be done once and only once for each texture at start up, so its not helping to tell whats taking so much time every frame. how many textures, how many texture changes, how large are the models on screen, how many triangles, how are you rendering them (immediate mode, va, vbo)...

I presume some of, if not all of those models are the same?
If so I hope your not individually loading each one.
A model, just like any other content only needs to be loaded once, and then re-used. If thats not the problem, it could well be your just rendering too much - 40 models is a fair bit, and we dont know what else you may be rendering.
Might be worth your time to lookup ''Imposters'' .

Actually I am have just one md2model in memory, but I draw it with a bunch of different skins.. the code for loading the textures is done only once for each texture... right now all I have is a bunch of animated md2 models, each asscotaed with a texId (ie just an integer) and when I render a model (admitiidly I do this in immediate mode, i.e. using glBegin(GL_TRIANGLES) and GL_TRANGLE_FAN) as of now it is 40 models, with about 4 or 5 differnt textures, admittedly getting clycled.. would there a massive speed increase if the modesl were drawn so that consecutive models drawn all use the same texture?
How can I tell if the texture is getting reloaded to the video card evey time I change it?? If I loaded 100 textures, then the card probbaly cannot hold them all.... I''ve seen something called GL_CLAMP, or soething like that in glTexParatmeri calls in other peoples code, does this ring any bells for anybody?
What are "Imposters"?

KRouge wrote,

''would there a massive speed increase if the models were drawn so that consecutive models drawn all use the same texture?''

Hard to say if there would be a massive speed increase, but i''d be most surprised if you didn''t get a considerable boost to performance by doing this.

The general approach to rendering is to minimise state changes as much as possible, this includes batching of models by shader/material/texture.

So definately re-order your rendering to batch by texture.

As regards GL_Clamp this refers to controlling whether the texture is repeated or not at values outside the 0.0 to 1.0 range. When clamped the UV values that are outside the range will be rendered without the texture, using the base colour of the material (I think)

Imposters are a means of rendering many elements with less overhead than models. Each imposter is the object rendered from the viewpoint of the camera into a texture. The actual model is then replaced in the scene with a billboard using this texture. Imposters are updated periodically when they the old view angle and the new view angle exceeds some error margin.

Definitely stop using glBegin(), it is slowing you down.

>>would there a massive speed increase if the modesl were drawn
>>so that consecutive models drawn all use the same texture?
yes, it would give you - at least - a small speed gain, but don''t expect too much - beeing on GF2 let me assume that you have a minimum of at least 32MB, and i''m pretty sure that your 5 textures are *not* using this RAM completely ?! (yes, obviously it may be: but i''m sure that you are working with textures small than 1024²!)
try to sort your models by the texture ID - because: you can''t examine how much videomemory you have available for textures, and it may occur that the driver is swapping out the textures into systemram (worst case!) - and then drawing 40 models, unsorted, by having each model enabled/loaded it''s own texture, might screw up your performance - do the math for yourself, for worstcase: 40 models * 40 frames -> 1600 texture switches in worst case, 1600 texture switches in worst cases may cause "1600 * [texturesize]" MB unnecessary traffic on your bus, each texture about 4 MB (assuming 1024²), makes a total busload of 1600 * 4 = 6400MB each frame...
BUT: i''m sure your textures are "resident" on videoram, so this won''t be the bottleneck, i assume.
Try to switch your code from immediate mode (glBegin/glEnd) to - at least - vertexarray (gl...Pointer()), this would give you a great improve.

If you have done that, post your results; they should be widely better than now



DJSnow
---
this post is manually created and therefore legally valid without a signature

even if your textures are resident sorting by texture will help, 1600 texture switches at worse case is a VERY expensive overhead and should be avoided

For testing purposes, make all your models use the same texture and then see what your FPS goes to. This will give you an idea if the problem is with the textures or somewhere else.

- onebeer

40 texture switches per frame isn''t unusual, I wouldn''t worry too much about that. But the immediate mode is indeed a problem. If these are 1000-poly models you have about 40k polys, which means 3.2Mtris/sec at 80fps. You aren''t going to get much faster than this in IM. I''ve seen similar triangle rates on a radeon9700 when rendering 20k-80k triangles in immediate mode.

You could try putting the whole thing in a display list. Display lists are roughly as fast as VBO so it''ll give you an idea of what kind of a speedup you can expect (with a minimal amount of new code).

Well,

I did not do the display lists, but I did use vertexArrays and texCoordArray 8using DrawElements, and the frame rate basicly doubled. I really have not tried the avoid texture switching yet .... now I have (another) question: when one uses DrawElements, the arrayindexes have to match, so essentially each vertex has exactly one TexCood associated to it.. in the md2 file format, a particular vertex may change its texcoord depending on what triangle it is dealing with, i.e.

glBegin(GL_TRIANGLE_FAN)
for(i...) {
glTexCoord(texCoords[UseThisTexCoor])
glVertex(Vertices[UseThisVertexIndex[i]])
}
glEnd()

I ran the code and the Texcoords do change for a given vertex index, my solution was not so nice: basicly I inflate the number of vertices until each index has a unique texCoord associated to it, that way DrawElelemnts is happy, but this increases the number of vetexes by about a factor of 3....ie form 300 to about 900 .... I do not interpolate the duplicate vertices, I just copy them from the "real" vetives that get interpolated... at any rate I do not like this solution.. is there a glDrawElements() like command where the indexing can be different for each of VetexArray, TexCoordArray, etc? what about VBO''s? can one specify the indexing table speratly for each array? (I have not read about them as the version of the RedBook I am using only goes upto OpenGL 1.1) the ability to do this seprate indexing would be nice, as the md2 models already have a (quantized) normals anyways....

I''d like to do DisplayLists, but the vertexes are interpolated between frames and I though when one does DisplayLists, the vertexes had to be completely fixed (but by changeing the ModelView matrix one can "move"/"rotated" the objects atleast)
it looks to me that if I wanted to do a time based interpolation,
then DisplayLists are out of the question....


thanks in advance.

The only way to do it is to duplicate the vertices as each vertex can only be indexed once and that index is used for all attributes.
(well, technicaly speaking, each vertex CAN have two or more different sets of texture coords, however this is under multi-texturing, one set of data per active Texture unit, and wont help you here)
This isnt an OpenGL limitation, its a hardware one.

i was afraind of that.... just kind of seems, well inefficent.. it would be nice to be able to look at the code of the openGL drivers and see where it really needs that index tables are common.... as duplicating vertices just seems silly to me...

As i said, its not an openGL thing, its a hardware thing, atm at least gpus are limited to one index array per vertex stream.

Keep in mind that when you develope a game you are more likely to be fill rate limited than vertex rate limited, so really the extra vertices are much of a muchness