One of the biggest problems modders and their fans run into is the issue of memory management. When you’re a game developer creating content for consoles or mobile devices, you have a specific memory budget that you have to maintain. This requires hard choices during development, and one of the first places to cut is on texture resolution. Every artist wants to make their work look as good as possible, so telling someone to smash their gorgeous 2048×2048 texture down to 512 (or lower) can be met with resistance.

In modding games like KSP, which don’t (yet) have a stable 64-bit build for handling a large number of graphically-heavy additions, you end up killing performance or outright crashing the game (usually the case, with KSP). KSP crashes hard when you hit a magic wall of memory utilization. (Usually around 3,500,000 of private memory for the app.)

There’s a few factors in play. Initially, developers were using TGAs, as they are generally the basis for most game art. They give you good quality, transparency channels, and are readable by any decent app under the sun. Unfortunately, they also gobble memory like there’s no tomorrow. If you don’t have a technical director overseeing a project, you suddenly get a mod full of super-high-res beautiful textures (or a huge mod with lots of smaller high-quality textures) but you can only use so many of those before crashing.

Another thing modders need to watch out for (who don’t have experience with game-specific art) non-square textures can take up as much texture memory as a square texture the size of the longest side of the image, because of the way game engines and graphics cards may process textures. This is not a 100% rule, see these threads (polycount.com) for more info and tips.

Truth be told, cutting resolution isn’t usually a huge sacrifice. Texture compression (such as DXT) and good resampling can give you excellent quality without significant sacrifice in visual fidelity.

Unfortunately, even with good discipline by mod teams in creating tight, well-optimized textures, the KSP mod community has a huge number of excellent mods, and the math just ends up getting you to the same place. (Crashville)

KSP modders have come up with a few fixes for this problem.

Load batches of different mods, depending on what part of the game you’re playing.

Active Texture Management: A great mod by rbray89, which will read the game’s (and other mods’) textures, and compress them and store them in a texture cache for better memory utilization. The utility is also configurable for quality or increased compression values.

DDS loader: TGAs, PNGs, etc., are not a format native to graphics card processing. They need to be interpreted for drawing on your screen. DDS format is one that is more of a native format for your GPU to process, and allows improved loading time because of the lack of processing. To take advantage of this, Sarbian released DDS loader, which allows KSP to make use of the optimized format. For Windows, KSP to DDS will allow you to batch convert the base game’s textures, as well as mods’ into DDS for the plugin to use. For Python fans, here’s another version, img2dds



As an example, here’s the results I got in my testing: