• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • 🏆 Hive's 6th HD Modeling Contest: Mechanical is now open! Design and model a mechanical creature, mechanized animal, a futuristic robotic being, or anything else your imagination can tinker with! 📅 Submissions close on June 30, 2024. Don't miss this opportunity to let your creativity shine! Enter now and show us your mechanical masterpiece! 🔗 Click here to enter!

Optimizing textures and mipmapping

Not open for further replies.
Level 23
Oct 20, 2012
Hello pipz, I'm currently trying to optimize textures of WoW tree models for my project since I've noticed that the textures are the heavy things and not the models. BLP Lab seems to optimize it but not much.

I have tried to resize the texture by converting it to TGA and resizing it in photoshop but it the result isn't really beautiful when the texture is applied to the model. Yes it reduced the kb by almost 80% but look at the result:

The other half of the trunk is streched and I have no idea how to fix that. Canopy looks fine though.
I recalled B2M mentioning mipmaps in a notepad in his resource pack. I've seen those textures and they seem to still fit the models AND have a huge reduction in the kb's.
Can you guys teach me how to do that? It would really be awesome if you do..
OR any other ways to optimize textures would be great too
Level 17
Jan 18, 2010
That looks like the map is messed up. If it worked before and now doesn't work it may also be that the texture was originally tiled but you didn't add the tags for this new one.
Go to texture window in magos find the trunk texture and check wrap width and wrap height.
Also I wouldn't recommend removing mip maps, they exist for a reason. (although I'm not sure what blp lab does to reduce the filesize, it may as well be deleting them)
If you remove mip maps it may cause a major hit on the performance because the number of rendered texels will skyrocket. They usually take up one third of a 256x256 texture filesize however.
The default optimizations from BLP Lab won't be too significant (although they do help). They do not affect quality--they simply remove extraneous information. It most likely removes extra digits/reduces precision such that the changes are negligible, thus reducing the file size. It may have a more significant difference when imported into the map, but I haven't tested that properly.

However, the real power in BLP Lab's file compression can be seen in its options for saving. Go to File -> Save As. Select BLP1 as the file format. You'll see several options for compression. I'll give you some info that may help you decide on what to do. The tests are based off of a 817 kb 512x512 BLP.

  • EDIT [06/03/2013]: The paletted information will be off. The compression seems to be minimal at first. However, when compressed in the map archive there are major compressions. Do not take all of this as set in stone! I just reported the file size differences of the blp, not the actual map.
  • Paletted: Paletted format, thus limiting the color counts. This means that some colors will be approximated. This produces a similar effect as when you convert something to a .gif format. The color count will not reduce the file size by a significant amount, but the file will compress much better in the map archive. EDIT: Note that these may compress even better in the map archive, so you may want to choose this over JPEG compression if you want a good amount of compression without sacrificing too much quality.
    [Before: 817 kb; After: 684 kb; Reduction: 16.28% ]
  • - Compress Palette: Reduces the number of palette entries to the number of colors in your image. This won't make a really significant difference in file size unless you have very few colors involved.
  • - Error Diffusion: This reduces the "artifacts" created through the palette process. This will improve the quality of the image (possibly) if you have the palette option selected. However, this will not reduce file size (it will either remain the same or increase), so you can ignore this option.
  • Compressed (JPEG): The image will be saved as JPEG format and the quality can be scaled. This can make a significant difference on the file size. (quality change will vary)
    This graph will show how quality affects the output size. The x-axis is the file compression quality (e.g.: 100 = 100%, 50 = 50%) and the y-axis is the file size (e.g.: 800 = 800 kb)
  • - Merge Headers: One header for all mipmaps in the file. (no quality change)
    [Before: 821 kb; After: 819 kb; Reduction: 0.24%]
  • - Progressive Encoding: Puts the output JPEG in progressive format. The file size will vary but it can compress better in the MPQ. (no quality change)
    [Before: 821 kb; After: 724 kb; Reduction: 11.81%]
    I tested it by importing it into a map and it didn't have a significant change (it was still an 11.81% reduction, but it didn't seem to compress more efficiently).
  • Mipmap Count: Change the number of mipmaps in the file. The wikipedia gives some good info on it:
    Mipmaps are pre-calculated, optimized collections of images... intended to increase rendering speed and reduce aliasing artifacts
    Therefore, by reducing this count you may risk the rendering speed and increase the number of aliasing artifacts. This may not be a big issue since warcraft 3's graphic demands are relatively low (unless you have very high-poly models/massive textures). It is up to you. Note that lowering the mipmap count may crash players who are running your map on a mac.
    [Before: 10 mipmaps, 821 kb; After: 1 mipmap, 572 kb; Reduction: 30.33%]

With all this in mind, BLP Lab should be able to make your texture have a pretty low file size. :) You just have to tinker with the options. Now, my results won't be the same as yours, of course. These were all just examples so you can get a perspective on what to use.

The source of the technical information is the readme for BLP Lab. It has some interesting information.
Last edited:
Not open for further replies.