Multiple Textures and Performance issues

im not surprised try this
bind texture 0
glBegin( GL_TRIS )
loop 5000x
{
draw triangle
}
glEnd()

bind texture 1
glBegin( GL_TRIS )
loop 5000x
{
draw triangle
}
glEnd()

That was the whole point. I can''t do that easily. I''m swapping textures a total of about 300 times in a really complicated scene. Its hard to organize every single triangle according to the texture on it, and it seems rediculous that I have to do so.

you are only using 2 texutures?

Well if the limits on all your triangles are like this

0,0
1,1
0,1

and never MORE than one, try placing BOTH the textures onto one texture side by side.

So the triangle A would now use
0,0
0.5,1
0,1

and triangle B would use
0.5,0
1,1
0.5,1

---

Beer - the love catalyst
good ol'' homepage

Unfortunatly no, I''m doing about 25 textures.

heres the scene, and I''m swapping textures about 250 times total in this Screenshot. I''d hate to have to go through every single object on the screen and render each model that is common with all the others before moving on to the next model.

>> Its hard to organize every single triangle according to the texture on it, and it seems rediculous that I have to do so. <<

u dont have to BUT if u want better performance u do have to.
think of drawing a picture with 3 coloured pens which ways gonna be quicker
A/ pick up the first pen draw all what needs to be done with that pen put it down + then pick up the next + repeat
B/ pick up a pen draw a line, the line next to it is in a different colour so put down that pen + pick up the other colour pen draw the line put that pen down + pick up the original pen etc

that is an awesome way of explaining it zed (the pen thing)

Unfortunately he is very right Xanthen... you will get a massive speedup from minimizing your texture state changes.
Your screenshot does look quite nice though


btw zed, how is gotterdamung coming along? (or are you still busy with other shit?)

Edited by - Bad Monkey on January 16, 2002 2:38:13 AM

oh well, sorry it wasn''t that helpful then Xanthen, you''ll have to do as Zedzeek stated.

It is a really nice screen shot you have there.

---

Beer - the love catalyst
good ol'' homepage

As funny as it seems, it would take you less time to sort by texture per frame than to do 300 texture changes. Man thats a lot!! Sorting by texture is actually a really standard practice. Texture changes are extremely slow and should always be minimized as much as possible. If you do a radix sort on the draw order of your polys for each frame so that texture changes are minimized, I would say its a safe bet that you'll see speed improvements of at the VERY least 5 to 10 times what you're running at now (probably quite a bit more). As it is now you're doing it in the absolute least efficient way possible.

Edited by - lunarss on January 16, 2002 3:45:24 AM

heh, well, i wouldn't quite say LEAST effecient. I did go through the work of minimizing most of the texture swaps while rendering the ground. Which improved the ground rendering speed from like 20 fps up to about 60.

Most of the texture swaps come from rendering the objects on screen, as right now I just swap the texture to the object I want to render, render it and then move on to the next object.

What is the maximum sized texture I can load into a single texture space on todays cards? I was thinking the limit was 256x256 so thats the highest we have, but I would be able to get rid of a lot of texture swaps if we went to 512x512 and then only had 1 texture per object.

Additionally is there any performance difference between swapping out large textures vs small textures?
So would 300 512x512 texture swaps be slower than 300 128x128 texture swaps?

And another performance question: I have all the triangle normals precalculated in order to perform my own lighting, is there any way to pass this information to the OpenGL system so that it doesn't have to calculate all new ones?

Edited by - Xanthen on January 16, 2002 10:13:55 AM

My card (geforce 2 Pro) can do 1024x1024. I think it''s only the old voodoo cards which were restricted to 256x256. You can lose a lot of speed using big textures though, so I wouldn''t recommend it.

www.elf-stone.com

a bit off topic here, but man- that screenshot is great!
add some shadows to the character model and you''ll
be stylin''


-eldee
;another space monkey;
[ Forced Evolution Studios ]

I got a voodoo5, and it does 1024x1024

But I think the voodoo3 is only 256x256.
I''ll go with the 1024x1024, and forget everybody else with lower. I''m not interested in showing how my program can run on an atari 2600.

>>btw zed, how is gotterdamung coming along? (or are you still busy with other shit?)
<<

i just finished work the day before yesterday (hurrah) + wont be working again until the end of febuary so ill have a bit of time on my hands now for a while (ill be going down to dunedin next week or so to buy a geforce2mx so its time to get busy with gotterdammerung again)

quote:

---

Original post by Anonymous Poster
> My card (geforce 2 Pro) can do 1024x1024

The GeForce2 does 2048*2048

---

I stand corrected.



www.elf-stone.com

Well, I performed my own test and found that changing between 1024x1024 textures takes the same amount of time as it does to change 128x128 textures. So it makes sense then to have 1 single texture per model vs. multiple small textures.

Does anyone know about passing the triangle normals to opengl so it doesn''t have to?

if you can pack all your textures for each object into one, that will help. you will still have to do some sorting before render time though... this time sorting by object type... ie bind the tree texture (which may have bark and leaves and stuff), then draw all the trees, then bind the bridge texture (which may contain different kinds of stones, some with moss etc) and draw all the bridges, then bind the funky-voodoo-guy texture... etc etc

the only thing with doing it this way (putting multiple textures into one) is that you will have to play some funky games with texture coordinates to access each one... perhaps you could maintain a structure that holds offsets to each sub-texture, and when you bind the texture, translate to the sub-texture you want using the texture matrix...

hmmm... just some thoughts... need lunch now


Completely off-topic section:

>> just finished work the day before yesterday (hurrah) + wont be working again until the end of febuary so ill have a bit of time on my hands now for a while (ill be going down to dunedin next week or so to buy a geforce2mx so its time to get busy with gotterdammerung again) <<

hehe... I nearly joygasmed in my pants at the stuff i could do when i upgraded my vid card from tnt2-m64 to a gf2mx

sorry I screwed up the name... i suspected i had missed a few letters... what can I say... I''m just a dumb aussie

Actually I already do what you said Dan, coupled with trying to call that function as little as possible.

Badmonkey, Thanks for the idea, I already have a Texture handler class module which does all the loading deleting, texture binding, animating crap. With a little modification I''ll be able to put multiple textures into one big texture and then ask the texture handler for the texture offsets and add those in.

The only texture I repeat is the water texture, so repeating isn''t going to be a problem at all. I will probably be able to get the texture swaps down to 8 for the whole scene.

Congrats on the new texturing system, but you need to get a new artist

www.elf-stone.com

It didn't work.... at all.
The problem wasn't texture swapping at all. Its fill rate.
The trees are using way too much of the fill rate.

Its probably a good thing to not have the texture swapping anyway, but I still haven't solved the problem. :/



Edited by - Xanthen on January 17, 2002 7:14:35 PM