Why .vtf?

It seems illogical for valve to create there own image format for the Source engine.

While one can see the obvious advantage of creating an image format unreadable by common image editing programmes, they must have surely anticipated that someone would eventually work out how to convert them to .jpg, deeming there format useless, and somewhat an inconvenience.

Take STALKER for instance; they use the common .dds format (perhaps not that common, but much more common than .vtf) for there textures but again, it’s understandable due to the fact that they use a unique file containing all the game content, including the textures.

So, why did valve feel the need to use a double precaution of both a unique image format and a file containing the textures?

I guess because VTF can store everything they need?

I dunno, read about it and find out:

Valve provide tools with the SDK to convert both to and from vtf. Presumably it was easier for them to write an image format compatible with their engine, rather than the other way around.

They probably did it for the reason stated above, and because it’s very good quality to size wise.

Even though the textures are usually 512x512

I meant the file size to texture quality ratio is good.

.jpg is very lossy, it’s the last format you would ever want to use for textures. From what I understand, TGA would be your best bet for lossless textures, but then you have massive file sizes. VTF (similar to what the DDS format does) simply compresses your textures in an efficient way, while avoiding the lossy methods of compression that are used in jpg.

Essentially just good File size to image quality ratio, plus they probably needed to toss in a few other things like mipmaps and a variables for each texture (not what a vmt does, just maybe declaring VTF version or something like that).

Valve also gave people an SDK and dll’s for use with the vtf file format, which is why people like Nem can write tools like VTFCmd or VTFEdit, it’s not like they were actively trying to prevent people from copying the textures out to another format.

Look at it from Valve’s perspective: If they can create an texture file that worked and integrated perfectly with their engines and games then why not? They provide you with tools for converting to and from .jpg, so why does it matter if it work’s perfectly for Valve’s needs.

I think it’s much more optimized, whenever I run large GoldSRC maps I seem to get render lag. When I’m running large OB Source based maps I get little to no lag at all.


Vtf > bmp

Hmm… I never considered optimisation.

What’s this tool to convert .jpg’s to .vtf’s with the Source SDK?


It’s better to use .tga though.

I know about VTFEdit, but people said there was one integrated into the Source SDK…?

Or did I misunderstand?

I think there is but VTFEdit is just generally the better way to go.

Plus VTFEdit has VTFLib, the thing that converts images to textures in mass, and it’s just overall easy to use.

The bonus of the .vmt is that instead of having to make hundreds of textures that all use a similar base texture, you can just make one base texture, then all the normals/ detail maps you need, then overlay the details onto the base texture in the .vmt. Which is much more efficient and space saving than hundreds of .vtf/ .dds when you think about it.

There is, there’s an .exe in the sdk binaries folder called vtex that converts .tga to .vtf and vtf2tga.exe, no prizes for guessing what that does. I have to say, I dislike vtfedit, it makes and absolute hash of mipmaps on a regular basis, and manually editing them is serious hassle, the vmt creation feature is also a joke (although there is always VIDE for vmt creation). I’d much rather just run a load of textures through vtex with a batch file and then mass edit together a bunch of vmts using VIDE, rather than use vtfedit only to get in game and find it’s vomited all over my mipmaps. Sure it might require a bit more knowledge to use, but I find it more reliable.