Original Post
I am rendering a terrain using tiles for textures. I need exactly 256 textures to achieve what I am doing. At the moment I am storing these all in a single texture and just accessing sub-sets using the UV map. All is fine and works well. The thing is, the texture has to be 2048x2048 in size (giving me 16x16 textures, each 128x128 in size). I have a texture-detail LOD toggle that allows me to load the texture as 1024x1024 and it works fine, but does look really bad and low-res.
So now, at the moment, I can render my terrain with a handful of draw-primitive calls (batches of VB''s) and only a single settexture call, because all tiles are drawn with subsets of the exact same texture.
The other method would be to batch my primitives by texture and render them with several draw-primitives and possibly lots of settexture calls (up to 256 settexture calls assuming really wild terrain texturing).
My current method is very fast and works flawlessly on the GeForce3 and GeForce4 cards I''ve tried it on. Obviously, on older cards it won''t work at all because of max texture size limitations.
But, I read somewhere that even on cards that can handle 2048x2048 textures it''s still better to keep textures smaller. Does this apply here to my case, or is it better to keep the settexture calls minimal as I am doing?
I guess the question is: Is the settexture call actually slow enough to warrant using only a single texture, or does the massive texture this implies slow it down to the point where it''s better to use multiple textures?
Learning to fly is easy, but as a tortoise, the landings are really rough.
