Jump to content

Nem

Members
  • Posts

    3
  • Joined

  • Last visited

Everything posted by Nem

  1. Hi everyone. I'm not *really* new here, I was a member years ago, before mapcore went down and had all those problems. Glad to see it's alive and kicking. Nem
  2. By default, the plug-in does NOT use compression. Perhaps this isn't the best default behaviour, but the reason it does this is because you could, theoretically, save a VTF and then open it back up and edit it directly without any loss of quality. If you want to use compression, all you need do is select the appropriate DXT format or use the template feature. And BTW, DXT is a lossy compression algorithm, so the quality would not have been the same, it just might have looked it. (The whole point of DXT compression is that larger resolution textures look better than lower resolution textures even if the larger ones have some noise due to the compression. This, of course, does not apply to all textures, which is why the VTF format allows for so many image data formats.) Anyways, I'm not trying to start a flame war here or detract from hessi's work. The point of my post was to shed some light on how Source textures work. You can't effectively make use of any tool unless you know the underlying process. I neglected to say this in my first post, but nice work hessi. I played the beta release and I have to say it's one of the best looking Source maps I've seen. Great use of custom textures and custom models. Oh, and yes, I am "the" Nemesis. Nem
  3. Yeah seems a bit high D: How exactly did you compile your textures? Cause if you use Photoshop and save them as a .vtf rather than using the vtex.exe to convert them to .vtf you're nearly trippling the size of the one .vtf This is completely false. As long as you are using the same format (e.g. DXT1 or DXT5 compression) you will achieve exactly the same file size, to the byte, using vtex and the VTF plug-in. DXT compression encodes fixed size pixel blocks into fixed size data blocks, so there is no way either method can differ in size (it is not like JPG compression). One area the two tools may differ in is quality, but this is completely subjective. I'm not going to make any claims as to which tool is better; vtex relies on a 3rd party library for it's DXT compression as does VTFLib. I can tell you that the library VTFLib uses (nxDXTlib by NVidia) does use a high quality floating point algorithm which is very comparable to vtex's algorithm. Indeed if you compress something complex such as an RGB gradient in both vtex and VTF plug-in and look at the top mip level, you will be hard pressed to pick the better one as they both create extremely comparable results (one may be slightly better in one area and slightly worse in another). I should also point out that vtex uses a "NICE" filter (which is simply a kind of subsampling kernel used to generate mipmaps for the texture). This kernel is very comparable to VTFLib's Sin Cardinal kernel (when no sharpening kernel is used). However, where the two tools differ is in the fact that VTFLib offers a whole slew of subsampling kernels and sharpening kernels you can use. There is no best kernel for any texture, it all depends on the type of texture you are compressing. I highly recommend to anyone who is designing textures that they try out the different subsampling and resizing kernels to determine which kernels work the best for their texture. I should also point out that sharpening mipmaps is generally a good idea because of the way mipmaps are blended in game as the engine interpolates between the various mipmap levels. Sharpening them generally creates crisper transitions. I also should point out that the "NICE" kernel vtex uses also, by nature, sharpens as it subsamples. I don't usually defend myself like this, the accusation was just false. Nem
×
×
  • Create New...