I did the ''bucket sort'' as was sugusted on the other thread. zoomed all the way out I get 35fps useing it (thats a 10 fps boost). Thats still not as good as I would like. I have not yet setup vertex arrays, Im still only going to be able to draw 2 polys at a time useing them, Am I going to see much of a boost from that? What other methods can be used to optimize a tile based 3d terrain engine?

Try Octree''s or quadtree''s. They should be able to minimize drawing. And Vertex Array are probably the best optimisation you can do.

Honestly, I think your technique is flawed. How do you intend to "blend" poly borders (since you don''t know what texture you may have per poly)? Or is this not meant to be "realistic" but more graphic?

Anyway, you mentioned a max textures of 10 before in your old post. You COULD put all these textures in one big one then just bind it and offset your texture coordinates for each poly to reference the correct portion. This way, you could also use a vertex array and everything. The only problem would be texture size.

The terrain is based on tiles, any texture can be used for a tile, and the engine creates the transition tilesets at runtime. A map can have a maximum of 10 different texture types, If you calculate the texture transitions thats around 10,000 unique textures. Obviousally there will never be that many, but the system to manage textures has to account for te possability of that many.

The bucket sort lets me draw the polys depending on the texture, so it lets me minimize the calls to glBindtexture().

Eber,

Glad the bucket sort helped a bit.

Have you counted how many texture context switches your are doing? With 10000 possible textures you might still be doing a fair few.

To move up your might want to try some sort of level of detail algorithm.

How about some sort of geomipmapping, where you skip tiles to draw as the player gets higher over the terrain (ie resample your terrain map).

Keef

-----------------------
glDisable(WORK);
glEnable(GL_CODING);

Thats a good idea, only draw every other poly and make them twice a big. With my textureing system it will be noticeable.

Ill put in a counter so I can see how many times textures are being bound per frame.

Many of your texture combintations could be rotations of each other.


If your terrain data does not change during the game you might want to try compiling your linked lists (from the bucket sort )into display lists. Display lists are usully faster than vertex arrays but of course you don''t have the ability to modify them

Of course this means you''ll be drawing the whole terrain all the time

Keef

-----------------------
glDisable(WORK);
glEnable(GL_CODING);

The terrain needs to be deformable.

And some of the textures are rotated, but to use one for all I would have to specify different texture coords, And to do that with vertex arrays I would have to have different texture coords for every vertex, and to do that I would have to have duplicated vertices, adding more overhead.

at about 10000 polys the bucket sort is binding about 256 different textures, and my old method was doing about 5000. This is with 4 textured, and purely random terrain. So the real numbers might be better.