I was looking at some of the original Half-Life models a while ago, and one thing that I noticed, besides the surprisingly poor quality of the models and textures, was that often a model consisted of quite a few small texture files, rather than one or two larger files. On discussing this with Cheeto, he pointed out that perhaps the graphics cards or engine at that time could better handle a lot of smaller textures over a smaller number of larger files. It seemed a reasonable deduction, so I filed it away and went on with my work.

Just now I was looking at Jeds U-Boat (http://www.dayofdefeat.net/forums/showthread.php?s=&threadid=27882) WiP thread, and the talk of textuers brought me back to thinking of those early HL models.

Hardware has certainly come a long way since Half-Life's original 1998 release, and the engine has gone through numerous changes as well, some for the better. So what I'm wondering, is it possible that Half-Life still prefers smaller, bite-sized textures as opposed to the big 512's we use today? Or is it not even a relevant issue anymore?

About the preformance, there is only one way to find out.

Email Gabe :)

Or test it out, make 1 model with 2 huge 512's, then one with a bunch of small ones, and see the difference.

Maximum supported texture size as defined in Studiomdl source is 640x480 or the equivelent byte total.

Saying that, I build a custom version of it to compile up to 1024x1024 which HLMV can show but HL/DoD takes a big steaming dump on your dinner plate trying to show a model with textures that size.

He said...

- Jed

This is from the SDK documents:

"Half-Life’s target system assumed a Voodoo I accelerator card with only 1MB of texture memory. For this reason many Half-Life textures are extremely small. Even weapon view models, which are on-screen almost continuously, were limited to around 125k of texture memory – about equivalent to two 256 pixel square maps at 8 bits. Characters such as Barney (the security guard) used 256k, the equivalent of 512 x 512 bitmap.
Fortunately most contemporary accelerators have much larger budgets and accordingly higher texture resolutions. However the same basic problem of resource allocation remains. Moreover the rise of GL-based hardware acceleration has taken away a lot of freedom in your choice of texture sizes. OpenGL hardware generally wants textures to come in power-of-2 sizes, i.e. dimensions of 2, 4, 8, 16, 32, 64, 128, 256 etc. Many hardware cards have additional limitations as well. Older Voodoo-based cards will crash if given textures with an aspect ratio greater than 8:1 (e.g. A 64 x 8 texture is OK but 256 x 16 is not). Other cards want all of their textures to be squares. Unless you are absolutely certain about the hardware you’ll be running on you should use only textures which are power-of-2 squares (see table).

(insert table here :F)

As you can see from the table at left, this range of texture sizes does somewhat limit your ability to fine-tune the amount of texture memory allocated to a model.
It may help your decision process somewhat to remember that there is a conceptual trade-off between the complexity of geometry and the complexity of textures. A model with very stark polygon limitations will depend very heavily on its textures for character, visual interest and the appearance of greater detail. A model with more complex geometry may be able to use somewhat lower resolution maps if geometry can be made to provide the model with visual impact.

"