View source for Talk:VTF (Valve Texture Format)

== Redirection ==
Possibly redirect this to Valve Texture File (needs to be created) instead of leaving this at VTF?
:I agree, VTF seems too ambiguous. --[[User:Zevensoft|Zevensoft]]
::I thought it was Valve Texture Format. I don't see an acronym explanation anywhere. --[[User:Andreasen|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. --[[User:Andreasen|Andreasen]] 10:07, 28 Aug 2007 (PDT)

:::: From vtf.h in the Source SDK:
<pre>struct VTFFileBaseHeader_t
{
	char fileTypeString[4]; // "VTF" Valve texture file
	int version[2]; 		// version[0].version[1]
	int headerSize;
};</pre>

So I guess it's Valve Texture File. --[[User:Wunderboy|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. --[[User:Andreasen|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. --[[User:Andreasen|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? --[[User:Grash|Gregory Walek]]
::::Abbreviated titles simply isn't Wikipedia standard. --[[User:Andreasen|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. --[[User:Wunderboy|Wunderboy]] 06:06, 8 Oct 2005 (PDT)

== "Nice Filtered" ==
Anybody know where I can find an explanation of what "Nice Filtered" means? --[[User:AlphaWolf|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 [[User:Nem|Nem]]'s [[VTFEdit]] also has a lot of other filter options which probably surpass NICE filtering in quality. --[[User:Wunderboy|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.--[[User:Nem|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. --[[User:Andreasen|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. [[User:Yithian|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 ? --[[User:Beeswax|Beeswax]] 10:13, 26 Apr 2008 (PDT)

== Clean-up ==

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? [http://en.wikipedia.org/wiki/Volume_rendering Volume Rendering] implies all sorts of different methods ... can anyone elaborate ? --[[User:Beeswax|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" ? --[[User:Beeswax|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? --[[User:Beeswax|Beeswax]] 16:20, 26 Apr 2008 (PDT)

== Billboards ==

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'? --[[User:Stucuk|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. --[[user:TomEdwards|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 useful[[User:Kizzycocoa|Kizzycocoa]] 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. [[User:Solokiller|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? [[User:Kizzycocoa|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. [[User:Solokiller|Solokiller]] 12:45, 1 December 2009 (UTC)
::::....wha?
::::sorry. I don't understand (AS) [[User:Kizzycocoa|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? [[User:Kizzycocoa|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. [[User:Solokiller|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 ^^ [[User:Kizzycocoa|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.--[[User:MrTwoVideoCards|Gear]] 01:28, 2 December 2009 (UTC)
:uh, I used a single VTF.

:it definitely works too.


:also, wrong again. each slide is separate.[[User:Kizzycocoa|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. --[[User:Pandaboy|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. --[[User:Artfunkel|Artfunkel]] 17:10, 12 November 2011 (PST)
::BGR565 is perfectly acceptable for most albedos, and is a reasonable compromise for lower-resolution (sub-512) textures. Unless your texture has fine gradients (like skyboxes do), you probably won't notice a major difference between BGR888 and BGR565. DXT1 should still be used for anything HL2-quality or greater, though, of course.<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 00:11, 9 July 2023 (PDT)

==  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. — [[User:Dr._Orange|<span style="color: #ffaa00">Dr. Orange</span>]] <sup>[[User_talk:Dr._Orange|talk]] · [[Special:Contributions/Dr._Orange|contributions]]</sup> 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: https://cdn.discordapp.com/attachments/208546171155775489/595549951782551552/Spraymaker_5000.rar
:[[User:Ficool2|Ficool2]] ([[User talk: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. --[[User:xNWP|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: https://cdn.discordapp.com/attachments/541766504123858964/598056033407205387/MIPMAPTERSTEST.mp4
:Don't revert the change until you test with the tool above, thanks [[User:Ficool2|Ficool2]] ([[User talk: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? -- [[User:xNWP|xNWP]]
:DXTn textures are stored in video memory compressed, so the decompressed size isn't exactly relevant here. Also, modern video cards calculate the interpolated colors with 8-bit precision, so DXTn textures can't exactly be called 565. Total bits means total bits-per-pixel as is; I think just as a 256-color texture from a GoldSrc WAD isn't considered 24-bit, DXT1 textures shouldn't be considered 16-bit.<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 16:12, 28 June 2022 (PDT)

== Non-traditional alpha-encoded formats ==

I'm not sure that all the formats listed on the page are actually fully implemented. When I tried to make a VTF encoded as BGRA5551 or BGR888_BLUESCREEN, the alpha channel appeared fine in VTFEdit, but showed up as having a black background instead of transparent in Hammer and in {{css|4}}. Using the same VMT, but with a BGRA8888 texture, the transparency showed up properly in hammer and in-game. BGRA4444 also seems to work properly in Hammer, but I didn't test in-game, because 4bpc is ew.<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 15:02, 25 July 2022 (PDT)

== Image format observations ==

* DXTn's signature green tint seems to be unrelated to having more green bits than red and blue bits, rather being a flaw in the encoders used by VTF creation tools. Encoding a VTF as BGR565 results in no perceivable green tinting, and neither does creating a DXT1-encoded DDS file in GIMP.
* Formats with 1-bit alpha channels, such as DXT1, should not be used when an alpha channel is necessary, even if using {{code|clear|[[$alphatest]]}}. {{code|clear|$alphatest}} actually does take into account antialiased alpha channels, so diagonal alpha-tested transparency will be cleaner with DXT5. Even if the source texture has a 1-bit alpha channel (ex: a GoldSrc "{{code|clear|{}}" texture or a GIF), using DXT5 instead of DXT1 will still result in cleaner transparency on mipmapped textures.
* If an RGB texture needs to be higher-quality than DXT1, but doesn't need an alpha channel, then I recommend trying BGR565 instead of BGR888. The quality loss is usually negligible (unless there are prominent gradients), but it is significantly higher quality than DXT1 and doesn't have that format's inherent blockiness.
** By extension, low-res (ex: 128x128) normal maps that have a specular mask on the alpha channel will likely look fine when encoded as BGRA4444, and not be blocky like DXT5. I don't recommend BGRA4444 for regular textures, as it has much more prominent color banding than BGR565, but the effect of the banding is negligible for normal maps (especially compared to the effects of DXTn compression), and BGRA4444 is half the size of a regular uncompressed BGRA8888 texture.
* The Source 1 SDK source code for the VTF format mentions the [https://en.wikipedia.org/wiki/3Dc ATI1N and ATI2N] formats. No VTF encoders can create ATI1N or ATI2N VTFs, but it would be worth checking out if the engine actually supports ATI1N, as it would be benefitial for greyscale textures such as [[Specular mask|specular masks]] for non-bumpmapped materials (like lightmapped props). An ATI1N texture is the same file size as DXT1, but it is higher-quality, greyscale, and doesn't suffer from DXT green tint. (I can't think of a practical use for ATI2N textures, other than for DUDV maps, which are deprecated).<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 13:24, 19 August 2022 (PDT)
:*[https://steamcommunity.com/app/440000/eventcomments/3378284761901981621/ According to] one of the developers behind {{p2ce|4}}, the ATI1N and ATI2N texture formats are broken or disabled in all source engine branches. P2CE's custom v7.6 VTFs re-enable support for these formats, as well as BC7 (with a software decoded fallback to RGBA8888 for unsupported hardware) and BC6H; this is notable, and should probably be mentioned on the P2CE page and/or with the Alien Swarm and SDK2013 formats.<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 14:24, 20 September 2022 (PDT)

== Lossless VTF compression in P2CE ==
According to a [https://www.youtube.com/watch?v=0i4zDspWB30 feature showcase video], {{p2ce|4}} modifies the VTF format to support Deflate compression, presumably being used on top of the existing DXT compression (or lack thereof). This method should be documented, so that it may be added to existing tools and VTFLib, and potentially made accessible by other projects like Mapbase.<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 06:29, 19 September 2022 (PDT)
:Update: According to some changelogs on the P2CE Steam Community page, as well as some discussion on the P2CE discord, deflate-compressed VTFs are considered "v7.6".<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 11:20, 19 September 2022 (PDT)

== RGB888_BLUESCREEN doesn't work ==

In {{css|2}} RGB888_BLUESCREEN and i assume its counterpart BGR888_BLUESCREEN do not work. It correctly displays the blue pixels as transparent in {{vtfedit|1}}, but in hammer and in-game the blue pixels display as fully opaque black, no matter the use of $transparent or $alphatest. Do these formats work in any engine branch? I assume it's quite a few games these don't work in, if not all. Perhaps the article page should be edited to reflect this.