best/better texture image file size

After searching the forums I haven’t found quite the answer that I’m looking for.

Take for example that you render a 3D landscape (using something like Blender, 3DS Max, etc) and export the file as an OBJ so that you can use it in an program. Essentially you have a plane type object with texture on it. There are possibly 5 textures that you are using, i.e grass, rocks, sand, etc…
For sake of argument, assume this landscape is on a 100x100 plane

Is it better to create one LARGE file overlay to simulate the ‘hard’ surfaces representing the 100x100 field, say one img file of 100mb
OR have 5 different textures mapped that only represent a 1x1 section of the landscape (8-10kb ea), but it needs repeated 10,000 times (100x100)?

(HARD surfaces are everything except water, because there is a water plane intersecting the hard landscape plane with different physics between the hard and water surfaces, which would be a different thread)

Define better ?
Of course if you can get away with repeating texture, they will be easier to create/store/load.

Better = less CPU overhead, faster rendering on redraws etc…

to put simply would I rather want fewer LARGER images, or more smaller images. etc 3x30Mb vs 10,000x1kb when I have a character running across the landscape. which is going to kill my FPS assuming image quality remains the same.

  • there is a small penalty each time you switch from a texture to another.
  • there is a huge penalty when total vram used by textures can no longer fit on the card. This could be mitigated (in the past but don’t know today if still relevant) by rendering in alternating order, ie tex1, tex2, tex3,… tex10 for odd frames, and tex10, tex9, tex8,…tex1 for even frames)
  • this use case can be handled better by various streaming systems, taking advantage of the facts that far away you only need lowres textures, only the nearest geometry need to be high res, detail level is easy to predict for heightfields, and character moves quite slowly. You can search for info and hearsay on “megatexture” in ETQW which solve exactly this problem, on a modified heightfield. Megatexture in Rage is a generalisation for any geometry.

If your texture is 100 MB, then it will fit on today’s video card’s memory so there is nothing to worry about.
If you also have other textures and we include VBO/IBO and you exceed the video card’s VRAM, then the driver will swap between RAM and VRAM as it renders. That will result in a slowdown.

To reduce memory usage by textures, people use DXT1 or DXT5 compression. I use a tool from the DX SDK called DXTex.

To reduce memory usage by IBO, use ushort instead of uint.
To reduce memory usage by VBO, use short for vertices and normals instead of float.