Talk:Valve Texture Format

From Valve Developer Community
Jump to: navigation, search


Possibly redirect this to Valve Texture File (needs to be created) instead of leaving this at VTF?

I agree, VTF seems too ambiguous. --Zevensoft
I thought it was Valve Texture Format. I don't see an acronym explanation anywhere. --Andreasen 10:07, 26 Nov 2006 (PST)
I Googled for both "Valve Texture File" and "Valve Texture Format", and checked all of my demos, and it seems that Valve hasn't officially divulged what VTF stands for. I can only say that "Valve Texture Format" outnumbers "Valve Texture File" at 2 to 1, and I guess that's as much of a clue we're going to get. It could be "Very Tricky Fridge" for all we know. --Andreasen 10:07, 28 Aug 2007 (PDT)
From vtf.h in the Source SDK:
struct VTFFileBaseHeader_t
	char fileTypeString[4]; // "VTF" Valve texture file
	int version[2]; 		// version[0].version[1]
	int headerSize;

So I guess it's Valve Texture File. --Wunderboy 10:39, 28 Aug 2007 (PDT)

Okay. I was about to move it to "Valve texture file", but that page already exists, so we'll have to wait for "Valve texture file" to be removed first. --Andreasen 11:08, 28 Aug 2007 (PDT)
I'm currently asking ts2do about why he moved VTF to Valve texture format and then back again. --Andreasen 11:16, 28 Aug 2007 (PDT)
VTF is the file extention, Once you get working with the SDK you know what it means. you might want to redirect from Valve Texture File to VTF instead. plus do you really want to move all the info here to the next page? --Gregory Walek
Abbreviated titles simply isn't Wikipedia standard. --Andreasen 11:19, 28 Aug 2007 (PDT)

Volumetric textures

With volumetric textures, does this mean we will be able to implement volumetric fog?

Apparently yes. I spoke to Brian Jacobson at Valve and he said thats what its there for although at present no volumetric texture exist. I would assume support for them will come in a future engine update. --Wunderboy 06:06, 8 Oct 2005 (PDT)

"Nice Filtered"

Anybody know where I can find an explanation of what "Nice Filtered" means? --AlphaWolf 23:29, 10 Oct 2005 (PDT)

To quote from an e-mail I recieved from Brian Jacobson @ Valve "NICE filtering is better than simple box-filtering because it preserves high-frequency information: textures mipmapped with it look less blurry than those mipmapped with box filtering. I believe there's a book from Jim Blinn (Dirty Pixels?) that talks about how it works."
I'm not sure if its a post or pre VTF creation filter, but Nem's VTFEdit also has a lot of other filter options which probably surpass NICE filtering in quality. --Wunderboy 07:11, 12 Oct 2005 (PDT)
NICE is the default mipmap resize kernel used by VTEX. It is a 7x7 matrix similar to the Sine Cardinal kernel available in VTFLib. There is no best kernel, which is one of the reasons VTFLib offers so many kernels, but it is a good general purpose kernel that gives sharp results. I've been meaning to add it to VTFLib and get off of NVidia's code. As a side note, flags denoted by Internal to VTEX? are flags I suspect of being used by VTEX and not the engine. An implementation of the NICE filter can be found inside the imageloader.cpp file in the Source SDK.--Nem 18:08, 3 Nov 2005 (PST)
While not being able to contribute to anything that has been stated, I've made a NICE filtering stub at this wiki, quoting you guys. Some images of quality compared to other kernels would be nice. --Andreasen 06:29, 11 Jan 2008 (PST)

Merging Texture with VTF

Texture is a common term in game development circles and modding circles. If I am new to modding for Source and I want to know how textures are implemented, this is the subject I would search for, not VTF. That said, there has to be a separate page for VTF files because that is a term which will be heavily searched for by people who are just starting out, and because it is a valid subject in its own right, distinct from a more general topic like textures. I think that the texture page should be left as a portal page leading to VTF and other Source-specific texture-related pages, texture tutorials, etc. Merging them will simply confuse the general concept of texturing with Valve's specific texture format. It should be possible, for example, to search for tutorials about creating textures in specific image-editing programs (GIMP, PhotoShop, etc.) and then to link these tutorials to pages explaining how to convert them from specific image formats to the VTF. Yithian 14:16, 24 Apr 2008 (PDT)

Good point. The various terms you mention make me think of the Material System article. I agree it's annoying for Source-noobs that Textures (vtf) are applied to Brushes via Materials (vmt). Perhaps it would be more approriate #REDIRECT "texture" to Material System, and include the info you mention in that article/category ? --Beeswax 10:13, 26 Apr 2008 (PDT)


I've just been doing a clean-up of this extremely useful article, but I have a couple of questions left over:

1. "Volumetric Texture" - this doesn't just mean normalmaps does it? Volume Rendering implies all sorts of different methods ... can anyone elaborate ? --Beeswax 16:20, 26 Apr 2008 (PDT)

2. To me "Image format" suggests things like pixel count, portrait or landscape rectangles, etc. Would "Pixel data format" be a better phrase than "Image format" ? --Beeswax 16:20, 26 Apr 2008 (PDT)

3. Bit depth data table : why don't the RGBA column bits always add up to the Total column bits ? What does N/A mean in this context? --Beeswax 16:20, 26 Apr 2008 (PDT)


According to the env_sprite page "Sprites always face the player, unless they are restricted to rotating on certain axes as specified in the VTF compile parameters." but i can't see any flags/options on the VTF page which would allow restriction to be set in the VTF. Is it actualy possible to create a VTF that has restrictions on axis'? --Stucuk 12:29, 18 June 2009 (UTC)

Perhaps it meant to say VMT? You can use env_sprite_oriented if that isn't the case either. --TomEdwards 14:01, 18 June 2009 (UTC)

randomly animate VTFs

is this possible? call me a noob, but idk if it is, and it would be VERY usefulKizzycocoa 23:17, 30 November 2009 (UTC)

I believe it is possible to use a Material_modify_control's StartAnimSequence input to do this. For random behavior, use a logic_timer or other logic entity. Play around with their abilities. Solokiller 08:23, 1 December 2009 (UTC)
ah, so it isn't possible to change how random the sequence it without splitting the animation into frames? Kizzycocoa 12:24, 1 December 2009 (UTC)
Animated textures are always split into frames, using separate textures for an animation, even a random one is inefficient. Solokiller 12:45, 1 December 2009 (UTC)
sorry. I don't understand (AS) Kizzycocoa 13:50, 1 December 2009 (UTC)
ok, I've been researching a bit into this.
I found the material proxies, and I think I could make this work.
is it possible to make a logic_timer and logic_case, lots of material modifys and then set it so every second or w/e, it changes the frame randomly? Kizzycocoa 13:57, 1 December 2009 (UTC)
nvm. I did it. will write a tutorial on my user. maybe introduce it into the main area, should it be accepted.
An animated texture is one VTF containing multiple frames, or textures. Solokiller 18:02, 1 December 2009 (UTC)
I know, but, say you want multiple GLaDOS screens.
to have an animated VTF means clear looping of the images
to make it so it's randomly animated would eliminate the need for the VGUI_slideshow point_entity, which you can only have one of at any given time (AKA, if you have 2, they will show the same thing)
therefore, I wanted a way to do so, but leaving point_entities I had no idea about out of it.
I think I have it completed. I am going to make a tutorial ASAP on it ^^ Kizzycocoa 18:09, 1 December 2009 (UTC)
Yeah don't make a tutorial, there are much easier ways of doing it. You used entities to handle it, rather that putting all those frames/images into a single vtf. For instance the Screen at the Glados fight in Portal uses a single vtf.--Gear 01:28, 2 December 2009 (UTC)
uh, I used a single VTF.
it definitely works too.

also, wrong again. each slide is separate.Kizzycocoa 08:14, 2 December 2009 (UTC)

VTF header

The 'VTF header' section gives details of the v7.2 VTF header. The version history suggests that as of 2007 we are on v7.4 Should the VTF header section not be updated to reflect this?

Why are all VTF compressions so HUGE?

VTF files seem pretty stupid to me - I mean - the way they are built. I got a 1024x1024 .PNG file that has NO loss in color at all. When converted to VTF as DXT1, which gives the smallest VTF size afaik, it - first of all - becomes really grainy, PLUS it increases in filesize (png was 470KB, VTF DXT1 was over 600KB). I mean, if a PNG file can keep color information that well, why can't a VTF file do it and still keep it's file size down? I tried BGR565 which is the smallest VTF compression I know that also keeps color information intact for sensitive images - and it became almost 3MB, which is about 8 times larger than a PNG image, which actually has better image quality. --Pandaboy 08:46, 12 November 2011 (PST)

PNG is a specialist compression format for images with large blocks of solid colour (which I assume your image has). It's very rare to have textures like that in games, so it's not surprising that there isn't native GPU support for it. DXT is designed for high-frequency images, while BGR888 (don't use 565, it's low quality) is completely uncompressed. --Artfunkel 17:10, 12 November 2011 (PST)

U/V LOD control

When can this be useful? I really don't see the point of this - All it does is to ignore the higher quality images while still having them in the file. Then users could simply just resize the image before making a VTF and getting a much smaller file size.

It would make a lot more sense if it was the opposite way around - Don't load lower quality mipmaps with lower texture quality settings. This could be useful for textures which can't afford to be smaller when close-up.

Image Flags: Vertex Texture

What is the exact use of this flag? The description says: "Usable as a vertex texture". But thats everything I've found so far. Does this mean the texture will respect any changes made to the brush with the vertex manipulation tool? Or in other words: proper UV manipulation in Hammer possible?

Multiple of 4

How exactly did you create a texture with dimensions that are non-power of 2, multiple of 4? I tried to create a texture with a multiple of 4, non-power of 2 dimension (48*48), but both VTEX and VTFEdit throws an error when I tried to do this. Could you please describe the process of making a multiple of 4 texure, otherwise it just looks like misinformation. — Dr. Orange talk · contributions 15:53, 4 July 2019 (UTC)

No thirdparty tool supports multiple of 4s, despite the VTF format supporting it.
VTFEdit can import multiple of 4 VTFs but not export them.
This is the only tool that I know of that accepts multiple of 4s for VTF generation:
Ficool2 (talk) 16:42, 4 July 2019 (UTC)
I am currently attempting to fix up the VTF plugins for GIMP to allow multiple of 4 exporting

Agreed with Dr. Orange, this is flagrantly untrue. VTF's must have dimensions of powers of two since each subsequent mip is half the size of the previous. With your example of 48x48 for example, that will reduce to 3x3 at some point which can't then be halved. I'm going to go ahead and revert the change. If Ficool2 wants to discuss, feel free to. But please do not change the wiki until we can all agree. --xNWP

VTFs do not need dimensions that are powers of two. Mipmaps half the size of the previous, and round it *up* if it results in a decimal. This works fine in-game, you can try it out yourself with the tool I linked above.
Video demonstration of mipmaps on a 400x400 VTF:
Don't revert the change until you test with the tool above, thanks Ficool2 (talk) 13:08, 11 July 2019 (UTC)

DXT Lack of RGB bits

All the DXT formats specify N/A for R, G, and B bits, any particular reason for this? They should all be 565 if I'm reading the chart properly. Also the total bits are 8/4? I think this is because it does in fact take 4-bits for DXT1 for each pixel. But should we be storing the size on disk in total bits or the size after decompression (so that we know the color depth of an image in this format)? I reckon the same reasoning went into the N/A for RGB, but again this isn't necessarily helpful information. Perhaps we should add a column for bits after decompression, or just assume total bits means after compression. Thoughts? -- xNWP