![]() ![]() So 4MB of textures is only raised to 16MB of detail textures, or 20MB total. Slight, but very important corrections, Guspaz.Īpplying 512x512 'detail' textures to 256x256 textures only gives four times the pixel-count. but then again, on some of the smaller textures, nothing stopping us from doing more than 2x each axis resolution. WolfWings said that compression will nail that down up to 4:1 though. If every texture is doubled in verticle and horizontal resolution, we'll be seeing something like 70MB texture usage on top of the existing 4MB of textures. Yes, we're really going to be taking advantage of extra texture memory. The real benefit comes from increasing the resolution. Best you can do is use the technique we're working on to simulate a 24-bit texture (Half-Life uses 8-bit indexed textures). There's not that big an advantage to applying a 256x256 detailed texture to a 256x256 texture. When we get this done, I intend to replace each and every texture on the maps, at least every texture that detailed textures can be applied to. People have successfully tested with more than 22 detailed textures. We since proved that there is no such limit, just the guy who thought he had discovered the 22 texture limit had done something wrong in the file. I think Zazi is referring to the 22 texture limit that we used to think there is. Original thread Note: Our discussion is mixed in with the one on general detailed texture use Images of examples, and screenshots of high-res textures in-game Please let me know of any bugs as soon as you find them by posting here. Many programs can open RAR files, including WinRAR. The package is compressed in the RAR format. It has to do with the what format the program converts the input image into for reading. Since the low-res texture should be TGA, I probably won't be fixing that any time soon. For the low res texture, it should support most, but it doesn't like JPEG. The program supports pretty much any input image format for the high-res texture. All the calculations are done in memory, the entire UI is just so you know what's going on. The picture boxes the program displays the textures in will tile the images. The application saves output.tga in the format used by Half-Life for detailed textures it's ready to use. The program will then calculate a detailed texture and save the file as "output.tga" in the same folder as the application. ![]() Here it is, the first alpha version of HLTex.ĭrag the low-res file into the first box, and drag the high res file into the second box. The rest is the same, except we are not using an existing half-life texture, we've generated one ourselves. The second application is similar to the first, except instead of using two source textures, we take a high-res texture, and calculate the low-res Half-Life texture from that. Hence it's completely backwards compatible. If it does, you can set r_detailedtextures 1 and gl_max_size 512 to use the high-res textures. In game, if your videocard doesn't support detailed textures, you don't enable them. We then scale the Half-Life texture up to match the size of the high-res texture, and basically reverse the method that Half-Life uses to apply detailed textures, to calculate the detailed texture, that if applied, will turn the low-res texture, into the high-res texture. In the first, we take a low-res Half-Life texture (The NS textures for example), and the high-res version of that same texture. Just pick up from where we left off in the old thread. We'll continue our discussion/work on this technique here. By calculating detailed textures I'm trying to fork off from the general Detailed Texture thread, because it's become long, and I can't update anything remotely close to the first topic. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |