Vertex Array, what i dont understand
Author
A while back I decided to rewrite a bunch of rendering code using vertex arrays. THe results were amazingly faster than my previous implementation....until I added support for multiple textures. (By multiple textures, im saying that every triangle in the scene has one texture assigned to it, but there are several textures in the scene). I found that I had to render part of he vertex array, switch textures, resubmit the vertex array, render some more..etc. This took things to a grinding hault. It was not worth persuing because the performance hit was so massive. I never did figure out how to get around this problem.
What was I doing wrong?
VAs are generally best with lots of triangles. Binding textures and state changes are slow.
You should group the triangles by texture (or by material type of some kind) and then render by group. ie, instead of assigning a texture ID to a triangle, you should assign a triangle to a texture group and render like that.
This may or may not be helpful, but your post was somewhat vague about your implementation details.
You should group the triangles by texture (or by material type of some kind) and then render by group. ie, instead of assigning a texture ID to a triangle, you should assign a triangle to a texture group and render like that.
This may or may not be helpful, but your post was somewhat vague about your implementation details.
Author
I ended up doing that, which did help some, but when the number of textures went up to about 30 or 40, it would be running uber slow. That was way back when I had my voodoo 3, but by all standards the scene I was rendering should have been able to run at ~100fps.
I guess what I'm asking now (since you answered my question), Is what do other people use to render similar geometry?
I guess what I'm asking now (since you answered my question), Is what do other people use to render similar geometry?
Not sure how big you 30-40 textures are but if they are small enough you could try and put them all into 2 or 3 larger textures and call the texture coordinates to reduce glBindTexture() calls....
Author
Well, now I have a 9800 Radeon Pro. However, I don't want that to be a crutch for writing unoptimized code. Also, the texture size is generally 128x128.
It seems that this problem is unavoidable with vertex arrays. This leads me to believe that there must be another form of vertex submission that could overcome this deficency.
What choices am I presented with? I find it extremily hard to find information on these types of opengl topics because the information is so loosely scattered.
Thanks for the replies.
It seems that this problem is unavoidable with vertex arrays. This leads me to believe that there must be another form of vertex submission that could overcome this deficency.
What choices am I presented with? I find it extremily hard to find information on these types of opengl topics because the information is so loosely scattered.
Thanks for the replies.
No, there's no way of binding textures midway through rendering a batch of geometry. It doesn't matter which render method you use. 40 texture changes per frame shouldn't pose too much of a problem on most video cards however.
All you can do is sort by texture or, as MARS_999 said, pack multiple pseudo-textures into one large texture. Bear in mind you can fit 16 128x128 sub-textures in a single 512x512 texture.
Most meshes in games only use a single base texture anyway. All the needed image data is crammed into a single texture (look at some of the skins on polycount and see what I mean). Unless you're talking about rendering a large environment such as a building then this is probably what you should be doing.
All you can do is sort by texture or, as MARS_999 said, pack multiple pseudo-textures into one large texture. Bear in mind you can fit 16 128x128 sub-textures in a single 512x512 texture.
Most meshes in games only use a single base texture anyway. All the needed image data is crammed into a single texture (look at some of the skins on polycount and see what I mean). Unless you're talking about rendering a large environment such as a building then this is probably what you should be doing.
Quote:Original post by Mulligan
It seems that this problem is unavoidable with vertex arrays. This leads me to believe that there must be another form of vertex submission that could overcome this deficency.
Really, there isn't. Switching between textures/materials is something that needs to be dealt with during fast rendering, and there's only two things you can do about it:
1. As ben bunny said, group together primitives which use the same texture/material, reducing the number of texture bindings to an absolute minimum, or
2. As MARS_999 said, stick smaller textures together into one large texture, and use that instead.
EDIT: Damn, beaten by the mod [grin]...
If you stick several textures together as one larger texture
how can you make them wrap properly?
suppose i have a large brick wall that is a single quad...the bricks need to wrap and tile across it, but i dont want it to wrap into the neighboring sub-textures...
how can you make them wrap properly?
suppose i have a large brick wall that is a single quad...the bricks need to wrap and tile across it, but i dont want it to wrap into the neighboring sub-textures...
Quote:Original post by haphazardlynamed
If you stick several textures together as one larger texture
how can you make them wrap properly?
suppose i have a large brick wall that is a single quad...the bricks need to wrap and tile across it, but i dont want it to wrap into the neighboring sub-textures...
You can't make them wrap properly. This is one texture capability that you lose when you stick textures together. However, you wouldn't stick together textures that needed to repeat. Look at a moving character model in a game like Half-Life or Quake III. That model has perhaps hundreds (or thousands) of polygons, and you don't want each polygon having a different texture. You want to be able to bind one texture, and draw all (or the majority) of the model's polygons in one go. So you create one texture for the model, and cram all the model's detail into that one texture. This image should demonstrate what I mean (it's the texture map for Blue Sarge from Quake III, used here for educational purposes). I count around 18 textures that have been stuck together to make that 256x256 texture. For other geometry, like brick walls, which need repeating patterns, you keep using individual textures. Sticking textures together is a shortcut, and like many shortcuts, it only works for certain things, like models...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
